Email list hosting service & mailing list manager

Comment on SRFI-110 and Comparison to Genyris xyzzy Bill Birch (22 May 2013 15:03 UTC)
Re: Comment on SRFI-110 and Comparison to Genyris xyzzy David A. Wheeler (23 May 2013 13:39 UTC)
sweet-expressions are not homoiconic John David Stone (23 May 2013 16:08 UTC)
Re: sweet-expressions are not homoiconic John Cowan (23 May 2013 16:19 UTC)
Re: sweet-expressions are not homoiconic John David Stone (23 May 2013 16:32 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (24 May 2013 03:55 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (24 May 2013 03:12 UTC)
Re: sweet-expressions are not homoiconic John David Stone (24 May 2013 15:34 UTC)
Re: sweet-expressions are not homoiconic John Cowan (24 May 2013 20:02 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (24 May 2013 20:09 UTC)
Re: sweet-expressions are not homoiconic John David Stone (24 May 2013 21:35 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (24 May 2013 22:40 UTC)
Re: sweet-expressions are not homoiconic John David Stone (24 May 2013 23:13 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (25 May 2013 03:43 UTC)
Re: sweet-expressions are not homoiconic John Cowan (25 May 2013 03:20 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (25 May 2013 04:17 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (25 May 2013 04:27 UTC)
Re: sweet-expressions are not homoiconic John Cowan (25 May 2013 04:55 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (25 May 2013 18:14 UTC)
Re: sweet-expressions are not homoiconic John David Stone (26 May 2013 23:26 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 00:29 UTC)
Re: sweet-expressions are not homoiconic John David Stone (27 May 2013 15:51 UTC)
Re: sweet-expressions are not homoiconic Alan Manuel Gloria (28 May 2013 04:28 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (28 May 2013 18:34 UTC)
Re: sweet-expressions are not homoiconic Beni Cherniavsky-Paskin (26 May 2013 20:40 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (26 May 2013 22:43 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 00:00 UTC)
Re: sweet-expressions are not homoiconic Alexey Radul (27 May 2013 03:32 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 04:44 UTC)
Re: sweet-expressions are not homoiconic Alexey Radul (27 May 2013 05:50 UTC)
Re: sweet-expressions are not homoiconic Alan Manuel Gloria (27 May 2013 06:34 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 15:14 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 13:55 UTC)
Re: sweet-expressions are not homoiconic Alexey Radul (27 May 2013 16:27 UTC)
Re: sweet-expressions are not homoiconic John Cowan (27 May 2013 15:55 UTC)
RE: sweet-expressions are not homoiconic Jos Koot (27 May 2013 04:57 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 13:37 UTC)
Re: sweet-expressions are not homoiconic John Cowan (27 May 2013 15:50 UTC)

RE: sweet-expressions are not homoiconic Jos Koot 27 May 2013 04:51 UTC


> -----Original Message-----
> From: David A. Wheeler [mailto:xxxxxx@dwheeler.com]
> Sent: lunes, 27 de mayo de 2013 2:00
> To: stone
> Cc: srfi-110
> Subject: Re: sweet-expressions are not homoiconic
>
snip
>
> Lisps already have a perfectly serviceable visible pair of symbols
> for grouping, namely, parentheses.  The problem is with their overuse.
> Since EVERYTHING is grouped with parentheses, it can be hard
> for humans
> to tell when you're ending one thing versus another.  E.G.,
> when there are
> 6 closing parentheses, it's hard to tell that it should be 7.
> People can visually match 2, or maybe 3 pairs, but not 10 or 12.

I am in favor of SRFI-110, for it might be very useful for people who don't
like parentheses. For myself I probably stick to parentheses. I have no
problems with lots of parentheses.

Although I think that indentation oriented notation can be useful for many
people, I do not well undestand David's remark about difficulties with 10 or
12 closing parentheses. Where with conventional parentheses you have to type
the correct number of parentheses, say 10, in a sweet expression you have to
reduce the indentation by 10 steps, which to me seems as hard, especially
when the start of the subexpression to be closed is too far above to be
visible on the screen.

For Scheme editing I use DrRacket. It has a customizable re-indent function.
It highlights subexpressions when placing the curser right before an opening
or right after a closing parenthesis. It is easy to jump forward and
backward over subexpressions. When typing a closing parenthesis, the editor
for a moment shows which opening parenthesis you are closing, even when lots
of lines above.

I think the same type of editing tools would be useful for sweet
expressions, but I would not know what part of

f(x)

to highlight or select when the cursor is at the start of the line. Should
it only be f? Or should it be the whole line? I have the same type of
uncertainty with:

f
! x

Thanks, Jos

>
> Lisp is called "lots of irritating superflous parentheses"
> for a *reason*.
> Most software developers today will *immediately* reject any
> language with such poor readability.  Even Lisp's creator,
> John McCarthy, did not intend for s-expressions to be used
> directly (!).
> While some people don't like Python's indentation-based syntax, Python
> is WAY more popular than Scheme or Common Lisp.  In short,
> Lisp's syntax greatly inhibits its use where it might be used
> otherwise.
>
snip
>