Reporting system and potentially Python

[John Ralls]

On Jul 8, 2011, at 8:15 PM, Yawar Amin wrote:

> Folks,
> 
> On 2011-07-08, at 01:15, Yawar Amin wrote:
> 
>> […]
>> I like the idea of XML -> HTML + CSS + JavaScript plots. How about moving to a completely declarative XML report, where we use XML tags to ask for things like account names and balances, and using the Scheme (or […]
> 
> I got to thinking that Scheme itself can be used as a declarative,* domain-specific language for defining GnuCash reports. We could have a declarative API that sits on top of the currently-existing report API, and abstracts away the complexities of writing out an HTML page and building a report options dialog box. Sort of like LaTeX hides the raw TeX complexities of laying out a page. Here’s my income statement converted over from XML into (declarative) Scheme:
> 
> (report "income-statement"
> (defs
>  (def-date "start-date" "General/Start date" "2011-01-01")
>  (def-date "end-date" "General/End date" "2011-07-31")
> 
>  (def-label "title" "General/Report title" "Income Statement")
>  (def-label "subtitle" "General/Report subtitle"
>   '((string (date "start-date"))
>   "to"
>   (string (date "end-date"))))
> 
>  (def-account-group "income" "Accounts/Income accounts"
>   '(3288757aa761c7bba993766bfb433466
>     e49c976843a1dba40570ed6295e89a33))
>  (def-account-group "expenses" "Accounts/Expense accounts"
>   '(df72fb29f46e90e12c2ba10d582a6148
>     e518845492b7b9cfa614cc405a8cf715))
>  (def-account "net-profit-loss" ""
>   "Net Profit (Loss)"
>   (subtract
>    (balance (account-group "income"))
>    (balance (account-group "expenses")))))
> 
> (title (label "title"))
> (subtitle (label "subtitle"))
> 
> (filter-date (date "start-date") (date "end-date”)
>  (group-date 'month
>   (tabular
>    (account-group "income")
>    (account-group "expenses")
>    (account "net-profit-loss")))))
> 
> And here’s the report structure in plain language:
> 
> report
> definitions (can double as options for the report options dialog box)
>  definition of date (start date)
>  definition of date (end date)
>  definition of label (report title)
>  definition of label (report subtitle)
>  definition of account group (income)
>  definition of account group (expenses)
>  definition of a calculated account (net profit or loss = income - expenses)
> report title
> report subtitle
> filter by date (only include transactions within date range)
>  group by date (monthly–this should show balances in the table as one column per month)
>   tabular display (we could also provide a graphical display–i.e. column chart)
>    account group (income)
>    account group (expenses)
>    account (net profit or loss)
> 
> What I’m trying to express here is that a tabular layout should know how to display accounts and groups of accounts: put the account name on the left and the balance on the right. And that the report engine should know how to re-use the definitions of account groups, labels, and dates to build up the options dialog box. We can help it along a little, e.g. in the call to (def-date "start-date" "General/Start date" "2011-01-01") you see that the second argument is a string that provides the tab the widget should be placed in (“General”) and widget’s label for the dialog box (“Start date”), separated by a slash. Oh, and since it’s a def-date, the option widget should be a date picker. This functionality can all be behind the scenes, leaving the report developer to just declare what his/her report should contain.
> 
> Note that in the call to (def-account "net-profit-loss" "" Net Profit (Loss)" …) the second argument is an empty string, meaning don’t place this as a widget in the options dialog box.
> 
> If we stick with Scheme, we can take advantage of all the low-level functions that already exist for data extraction and report layout. But we can also move to a declarative model where we can have convention (re-use the report definitions as options) over configuration (build an options dialog box).
> 
> Also, is it still true that we have to restart GnuCash every time we change a Scheme report, to see the changes? In any case, we need to make it dead easy for users to import and run and custom reports.
> 
> Best,
> 
> Yawar
> 
> * I find that I’m saying ‘declarative’ a lot nowadays–I think it has to do with the fact that I’m learning Haskell :-)
> 

Fun. Two questions: Can that be easily converted into a string parser so that normal users aren't put off by the extra parentheses, and is there anything about that that works in Scheme but not in C?

Regards,
John Ralls