Hi Alan,

Alan Manuel Gloria <xxxxxx@gmail.com> writes:
> 2.  A #|...|# comment is "removed" and replaced with GROUP if it's the
> first thing after indentation whitespace, or just "removed" otherwise.

This clarification (and the associated example equivalence shown below)
is very helpful to my understanding.

>  Basically, it means that:
>
> foo
>   #| comment
> |# bar #|
> comment
> |# nitz
>
> is the same as:
>
> foo
>   \\ bar nitz

Something along these lines should be integrated into the text, I think.

To simply write "Block comments (#|...|#) are removed" immediately
raises the question "what if it's the first thing after indent", and I
didn't find an answer in either the tutorial or the basic specification.

>> * I have doubts whether the addition of '!' as an indentation character
>>   is worth the added complexity in the spec (which is far more complex
>>   than I'd prefer, and I'm sure I'm not alone in feeling that way).
>>   Python seems to do fine without such a character.  So do Makefiles.
>>   If it's truly needed, then it presents authors with a dilemma about
>>   whether or not to put them in all the code that they write.
>
> ! is surprisingly useful.  Here's an example which is readable, but
> difficult to modify if you need to add an else clause:
>
> define (foo x)
>   define something $ cond
>                        (pred1? x) $ begin
>                                       something that is
>                                       very long
>                                       spanning several lines
>                                       and might
>                                         end up
>                                           with severe
>                                             changes in indentation
>                                       like this
>                                       and so on
>                                         so forth
>                                         whatsover ...
>                        (pred2? x) $ begin
>                                       another long clause
>                                       involving several
>                                         more lines
>                                       and which
>                                         also ends
>                                           in
>                                             (severe)
>                                           changes
>                                             in indentation
>                                               at the end
>   quux something

Hmm.  I see what you mean, but I'd expect python to have the same
problem, and yet they seem to do fine without this.

For that matter, a similar example using traditional S-expressions could
demonstrate the difficulty in adding a new clause and getting things
lined up properly.  Of course, as you say:

> In s-expressions, it's safe to lose a space or two when you insert a
> clause at the end of the cond - the parens (should) guide the parser
> to the correct insertion.

and that's true in theory, but in practice we almost never see
incorrectly indented S-expr code, and that's because almost everyone who
writes Lisp gets a lot of help from modern editors.

And that leads to my next question: has anyone written a nice emacs mode
to help edit sweet expressions?  I think that such a mode will be
crucial for adoption.  I doubt that many Lisp hackers will be interested
in trying to get things lined up by hand.  We've had better tools for
decades, and have grown accustomed to those conveniences.  Almost none
of us want to go back to the stone age, no matter how nice it looks.

    Regards,
      Mark