Re: Reader option to permit brackets as parentheses

[Greg Badros <gjb@cs.washington.edu>]

Michael Vanier <mvanier@bbb.caltech.edu> writes:

> I'm a bit puzzled as to how this works.  Are the []'s semantically
> identical to ()'s?  In some old lisps the ] was used as a "super-paren"
> that would close all open parens in the current form.  IIRC they faded from
> popularity when paren-matching editors came around.  Can you give an
> example where the [] syntax dramatically improves readability?

Yes, semantically identical to ();  a ] needs to close a [, etc., so
some grouping errors are caught earlier as syntax errors.  The most
profound benefit in my brief experience exploring this with cse341 is,
e.g.,

(let ([a 1]
      [b 2])
   (list a b))

It seems a lot easier for students to grasp that there is a binding of
values going on inside the first expression of the let special form.

> My gut reaction is that the only benefit is that you could see the grouping
> a bit better.  OTOH, if you want to go that route, why stop there?  You
> could have {}'s as well, and maybe user-defined paren-equivalents such as

MzScheme does let you do it with {}, too (not sure about other ones.

> #{ #} etc. etc..  Taken to its logical extreme, you have SGML.  I tend to
> think scheme is better off without them, but of course it would be fine as
> a dialect handled by a separate parser a la CTAX.  For that matter, it
> would be interesting to have a dialect that used indentation as an
> alternative for parens like python does.

To me the more interesting issue is whether people benefit from being
able to write code like this, or just for reading.  If it's just for
reading, it'd be easy enough to just extend a pretty-printer or a style
language (like a2ps's as I mentioned before) for nicer printing of
Scheme code (and using other dimensions, e.g., color, seems promising
too for helping matching in static code printouts). 

Greg