On Wed, Nov 16, 2011 at 9:46 AM, Donald Allen <donaldcal...@gmail.com>wrote:
>
>
> On Wed, Nov 16, 2011 at 9:27 AM, Hendrik Boom <hend...@topoi.pooq.com>wrote:
>
>> 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 don't agree at all, and I do have some credentials in this area, having
> known and worked with Jerry Sussman for many years, as well as his Scheme
> cohorts. I don't think any of them would want to return to the
> MacLisp/Interlisp days, writing that stuff in Teco on a KSR-33. The Scheme
> indenters, such as you find in Emacs or Edwin, are invaluable. Try writing
> Scheme or Lisp in any of the vi variants, even vim, and you quickly find
> out what it's like to be without a competent indenter.
>
> I believe the resistance to Scheme has more to do with the simple syntax,
> and with the prefix notation, than with the use of parentheses vs. curly
> braces. People see
>
> (cond ((> x 5) (fun a b))) ;; I won't even attempt to properly indent this
> in gmail
>
> vs.
>
> if x > 5:
>
I'm not sure how I fat-fingered this, but the message got sent prematurely,
destroying my credibility:-)
Anyway, you get my point -- writing that conditional in Python or C looks
more natural to people and so they prefer it to Scheme/Lisp on those narrow
terms, forgetting what working in Scheme buys you (personally, I'm more
productive in Scheme than any other language, and I've written code over a
long career in most of them; Python is also a strong contender in the
productivity dept., but there's a lot more to learn and keep in mind than
with Scheme; it's a much more complex language, even though the code looks
simple).
/Don
>
>
>
>
>>
>> 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
>>
>
>
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
