Re: deep nesting and Trailing parens

["Oliver Steele" <address@hidden>]

You omitted indentation-based grouping (Python; Haskell and Miranda's
"'layout rule").  Maybe one reason for its appeal is that the closing
delimiter is null.

----- Original Message -----
From: "Howard Stearns" <stearns@curl.com>
To: <ll1-discuss@ai.mit.edu>
Sent: Thursday, December 27, 2001 4:23 PM
Subject: deep nesting and Trailing parens


> Summary: There are lots of ways to minimize the cognitive costs of deep
> nesting and multiple trailing delimiters, and they don't all necessarily
> mean you have to give up the ability to define macros.
>
> ---
> Using parens to enclose every semantic grouping does cause expressions
> to be deeply nested and this is hard for programmers to sift through --
> particularly newbies.  There are several things that can be done to
> alleviate this:
>
> * Common Lisp uses plist pairings for defining name/value pairs of
> keyword arguments.  The destructuring mechanism for macros
> (destructuring-bind) builds-in the ability to deal with this.
>
> * 'let' does NOT have to surround the scope of the variables introduced
> with delimiters.  In C, Java, and Curl, the scope of lexical variables
> runs to the end of the enclosing code sequence.   This alone cuts down a
> huge amount of nesting, indentation, and closing delimiters.
>
> * Noise words can be used to separate expressions rather than nesting.
> For example, various kinds of parameters are separated in Common Lisp
> lambda-lists using lambda-list-keywords (&key, &optional, etc.) Here's a
> 'try' expression in Curl that shows how noise words are used rather than
> parentheses or other delimiters for the three code sequences:
>
>  {try
>     {do-something-1}
>     {do-something-2}
>   catch e:MyException do
>     {first-part-of-handler}
>     {second-part-of-handler}
>   finally
>     {first-cleanup-operation}
>     {second-cleanup-operation}
>  }
>
> * As mentioned by others, a variety of delimiters can be used for
> different purposes, which MAY help newbies with the
> bunched-trailing-delimiters problems.  This shouldn't affect macro
> definition.
>
> * For the special problem of bunched up trailing delimiters, the C/Java
> world prefers hanging delimiters.  I don't like it, but this thread was
> about what newbies have trouble with, and it seems newbies deal with
> hanging delimiters better than bunched delimiters.  Macro authors don't
> care either way.
>
> -----
> It remains to be demonstrated (as far as I know) that macro-definition
> can be made easy enough in the face of things like using noise keywords
> instead of balanced delimiters:
>
>   Can destructuring syntax be defined so that subexpressions can easily
> be identified within the body of a macro definition?
>
>   Can template syntax be defined so that such source fragments can
> easily be brought together?
>
> I haven't tried, for example, Bachrach and Playford's stuff, and I admit
> it doesn't seem immediately obvious that it's easy enough to write
> macros in the face of the above techniques.  But it does seem to me like
> we're within striking distance.
> (http://www.ai.mit.edu/~jrb/jse/jse.pdf)