Hello all,

First of all, I should admit that I have only begun reading about sweet
expressions in the last hour or so.  I don't yet understand the rules.

I began to try to learn about them by jumping directly to the
"Specification" section of SRFI-110.  I'm sorry to say that I find that
section extraordinarily unclear.  Below, I've made notes about the parts
that I found confusing.

No doubt, I could find answers to all of these questions by reading the
rest of the document more carefully, and/or by reading the website of
the Readable Lisp S-expressions Project.  However, I don't think I
should have to.  The specification should stand on its own to a
reasonable extent, IMO anyway.

[In the list below, "first list", "second list", and "third list" refer
to the three numbered lists of rules in the "Basic specification"
section.]

* "term" is used before it is defined.

* The concepts of "parent" and "child" are not defined.

* The use of the term "parameter" is confusing.  This is a datum reader
  after all, which deals with "lists", not "parameters".  I'd prefer for
  it to describe more clearly what data structure is created.

* Item 1 (first list): What is an "indented line"?  Does that mean any
  line with non-empty indentation, or does it mean "indented more than
  some other line"?  If the latter, which other line?

* Item 3 (first list): Does "multiple terms" mean "multiple terms on
  the same line"?  If so, isn't this redundant with item 2 (but IMO
  more clearly stated)?

* Item 4 (first list): What is an "empty line"?  Is whitespace allowed?
  What about exclamation points?  What about comments?

* Item 6 (first list): What does "prefixed" mean?

* Are '!', '$', '\\', '$$$', '<*' and '*>' recognized as special tokens
  only if they are surrounded by whitespace?  (All of these characters
  except for backslash are considered extended alphabetic characters in
  standard scheme.)

* Later in the design rationale, it is mentioned in passing that '!'
  is only recognized as indentation at the beginning of a line.  Does
  that mean before any whitespace?  If so, that fact should be
  mentioned in the specification (which currently suggests that '!'
  could mixed freely with spaces or tabs).

* Item 1 (second list): What are lines with "initial indent"?  What
  happens if a line is not consistently indented?  What is meant by
  "preceding line"?  Does that mean "preceding non-empty line"?  (if
  so, what does "empty line" mean?)

* Item 3 (second list): What does "completely ignored" mean?  How does
  this relate to the "preceding line" of item 1 (second list)?

* Is '!' considered whitespace?

* Item 5 (second list): What does it mean for an expression to "start
  indented"?

* Item 6 (second list): Do datum comments ignore intervening '!'
  characters as well?

* In the rules that say neoteric expression are read (not sweet
  expressions), how are '!', '$', '\\' and '$$$' handled?

* Item 7 (second list): What does it mean exactly that block comments
  are "removed"?

* Item 1 (third list): Regarding GROUP, what does it mean "it
  represents no symbol at all, located at that indentation"?

* Item 2 (third list): What does "restart list processing" mean?  What
  is "the right-hand-side"?  What are "its sub-blocks"?  What happens
  if there's more than one '$' on a line?

* Item 3 (third list): Does "indentation" mean "non-empty
  indentation"?  (and does that definition apply generally?)  In the
  "entire sweet-expression that follows" what is considered the
  indentation of the first line of that expression?

* Item 4 (third list): What are "un-indented sweet expressions"?

* Why is there a distinction made between "advanced sweet-expression
  features" and the rest of the spec?

* In the paragraph immediately following the third list:

   * "MUST only be accepted ... is active"
      => "MUST NOT be accepted ... is not active"

   * When are sweet expressions accepted but "indentation processing"
     is not active?  (in collecting lists?)

   * What does it mean that a "character sequence" begins with
     "exactly the marker's first character"?  In "{$}", why is the '$'
     not considered a "character sequence"?

* IMO, it should probably be specified whether "#!no-sweet" disables
  curly-infix.

* In the examples, why are the s-expressions not indented according to
  the nearly-universally accepted conventions?

* The use of '$', '$$$', '<*', and '*>' as special tokens should be
  mentioned in the "Backwards compatibility" section.  These are all
  considered extended alphabetic characters by standard scheme.

* If an implementation implements sweet expressions by default, then
  they will have to be careful about writing symbols that contain '$',
  '<*' or '*>'.

* In the design rationale, there's a section entitled "Blank lines".
  Are these the same as the "empty lines" referenced in the
  specification?  If so, I suggest using just one term, and defining
  it clearly in the spec.

* When you speak of "traditional abbreviations", you might want to
  make a suggestion about how to handle additional non-standard
  abbreviations.  In particular, the abbreviations #', #`, #, and #,@
  are widely used by the syntax-case macro system.

    Regards,
      Mark