Beni Cherniavsky-Paskin:

> misc proofreading:

Awesome!  Thanks for doing that.

> "Unfortunately, SRFI-49 had some awkward usage issues, and by itself it
> lacks support for infix notation (e.g., {a + b}) and prefix formats (e.g.,
> f(x)). Sweet-expressions build on and refine SRFI-49 by addressing these
> issues. "
>   Won't hurt to link here (again) to SRFI-105?

Done.

> # Tutorial
> ## Clarifications
> "2. Lines with only a ;-comment (preceded by 0 or more indent characters)
> are completely ignored - even their indentation (if any) is irrelevant."
>   I'd explicitly add they are not considered empty and don't end an
> expression.

Done (I just said that they "do not end an expression" since that's the main thing).

> ## Advanced features
> "Sweet-expressions also add a few additional abbreviations, sometimes
> called sweet-expression “advanced features”, that make sweet-expressions
> even more pleasant to use"
>   At least GROUP is essential, not just "more pleasant".  Though the
> existing formulation may be better than any precise alternatives.

Well... technically you can also use parens with traditional formatting.
And I can't offhand think of a better way to say it.

> - SUBLIST - add comment drawing attention to c d e f $ g == c d e f g != c d e f (g)

Done.

> - mention in tutorial how to escape special markers (e.g. {\\})

Done.

> # Spec
> ## Other requirements
> "Implementations that provide R7RS semantics ... SHOULD appropriate
> variants of these"
>   s/SHOULD/SHOULD include/.

Done.

--- David A. Wheeler