On Sat, 09 Jul 2011 18:05:48 -0400, Yawar Amin wrote:
> Hi John,
>
> On 2011-07-08, at 23:33, John Ralls wrote:
>
>>> […]
>>
>> Fun. Two questions: Can that be easily converted into a string parser
>> so that normal users aren't put off by the extra parentheses,
>
> I guess we could replace all the parens with more HTML-reminiscent
> characters like << and >>, so you’d get stuff like (btw I’m using dots
> to represent spaces everywhere as my MUA is eating up the first blank
> space on every line):
>
> <<report ...
> ..<<defs
> ....<<def-date ...>>
> ....<<def-date ...>>
> ..>>
>>>
>>>
> then do a search-and-replace to turn that back into Scheme. We might
> overcome a lot of phobia if we hide the fact that we’re really making
> them write Scheme :-)
There's also the use of [ ] in the old much-forgotten Lisp 1.5
metalanguage -- using foo[a, b, c] instead of (foo a b c). Perhaps foo[a
b c] would suffice. And C uses context-prefixed curly brackets, as in do
{ ... } and else{ ... }.
>
> Another thing we could recommend is lining up the parens below the
> function names on multi-line function calls. I mean:
>
> (report ...
> ..(defs
> ....(def-date ...)
> ....(def-date ...)
> ..)
> )
>
> In the beginning I found it a lot more digestible when I didn’t have to
> deal with the mess of ‘)))))))’.
I still find your layout more digestible, after years or using Scheme-
related languages. I prefer it in C with its curly brackets, too.
Now the parentheses in List are a syntactic price that's paid to make the
metaprogramming aspects more modular. There's no question of what can
fit within what, as there would be with independent pieces of context-
free grammar. I consider uniform means of reducing the parentheses
problem a boon.
In my own Lisp dialect I used an additional convention: '/' in a list
signals the start of a sublist as its last element; thus ( a / b ) is
equivalent to ( a ( bb )), and ( a / b / c ) equivalent to ( a ( b ( c
))). This eliminated most of the closer-clusters. It ended up having a
role similar to the that of ';' in other programming languages.
Unfortunately, '/' and ';' now have other, incompatible meanings in
Scheme.
But most Scheme programmers object to any suggestion that brackets are a
problem for Real Programmers, as if methods of dealing with parentheses
attack their virility or something like that
I just think programs should be written in a manner that makes them as
clear as possible. Programming is hard enough without unnecessary
obfuscation.
>
>> and is there anything about that that works in Scheme but not in C?
>
> I really, really don’t want to deal with memory management….
>
> Anyway, I kind of mercilessly hacked the ‘Hello, World’ report that
> comes with GC, in
> share/gnucash/guile-modules/gnucash/report/hello-world.scm, and wrote a
> few functions which do what I was talking about. So now I’m able to say:
>
> (d:report
> "income-statement" ; name
> 0 ; defs
> ; Have to keep this title while experimenting in the sample report that
> ; comes with GnuCash
> "Hello, World" ; title
> "2011-01-01 to 2011-07-31" ; subtitle (d:filter-none ; body
Is there a missing line break in this line?
> (d:p "Some text.”)
> (d:p "A little more text.")))
>
> … and that generates the report that you’d expect. The ‘d:’
> (‘declarative’) prefix is just to make sure I don’t clash with anything.
> Code is up on https://github.com/yawaramin/gc-decl-reports (I'm not
> pushing anything which causes a crash for me, so it should be reasonably
> safe. But caveat emptor).
>
> Regards,
>
> Yawar
>
> _______________________________________________ gnucash-devel mailing
> list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
