[R6RS] new syntax srfi draft, reference implementation

[Michael Sperber]

Thanks for the new draft, Kent!  It looks much improved in many
respects.  Some remaining questions and complaints:

- The Abstract talks about "sharing and cycles."  How can these arise
  in syntax in such a way that R6RS will be able to deal with it?
  (I'm guessing I'm missing something obvious.)

- The terms "bend" and "break" really should be explained in vicinity
  of the rationale.  One sentence each would be enough.  (I know
  "bend" is explained later.  Earlier would be better.)

- I'm not sure that the SRFI is the right place, but we need to spell
  out the connection between syntax and lists somewhere.  R5RS drops
  the ball on this.

- I'm unhappy about the classification of definitions within a library
  definition as "internal."

- The description of the expansion process is much improved.  Still,
  the item "syntactic abstraction" is only true if the abstraction
  doesn't expand into a definition.

- The document says somewhere that it doesn't talk about what the
  environment of the rhs of define-syntax is.  It should.

- It's unfortunate that many examples presuppose internal definitions
  (i.e. in sub-library local environments)---most could easily changed to
  be library bodies by dropping a surrounding (let () ...) or
  something similarly trivial.

- "defered" -> "deferred" (?)

- The section on hygiene is much expanded, but still doesn't do a good
  job of defining hygiene for simple-minded readers like me.  I would
  really prefer some maths here, specifically models for terms like
  "mark" and "wrap" and "substitution" would help greatly.

- "subtitutions" -> "substitutions"

- In Section 3.4, first paragraph: What exactly is a "keyword
  reference"?

- I couldn't understand section 3.5 at all---the issue section 5.9 is
  *much* clearer.  (I.e., what does "consists partly of list [...] 
  values" mean?)

- Kleene * and + are in tt, which is a bit disconcerting visually.

- In Section 3.6, should (... template) be (ellipsis template)?  Also,
  in "The output produced by syntax", I'm guessing "syntax" should be
  in tt.  Also, "ellipses" -> "ellipses" in the second item.

- The description of free-identifier=? is much improved.  When reading
  the sentence "Two like-named identifiers are considered to resolve
  to the same binding if both are unbound.", I was wondering if the
  "if" is an "iff".  Probably not, but them I'm looking for more
  sentences explaining other situations where "two like-named
  identifiers are considered to resolve to the same binding."

- Wrt. `include', I'm wondering if the I/O system should have
  `read-syntax' which is like `read', except it contains annotated
  syntax?

- `with-syntax' is used before it's explained.

- Wrt. `syntax-rules', do we require the "robust" implementation that
  does more error checking?

- Wrt. internal define---could a link to 

  http://srfi.schemers.org/srfi-83/mail-archive/msg00081.html

  or a more explicit discussion of the issues be included? 

- You mentioned that the semantics of internal and
  top-level definitions might be aligned even more, specifically in
  the sense that internal definitions might be interleaved with
  expressions.  Is that still an issue?

- "must be receive" -> "must receive"

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla