[R6RS] new syntax srfi draft, reference implementation
sperber at informatik.uni-tuebingen.de
Mon May 15 15:00:26 EDT 2006
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
- 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 [...]
- 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
- `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
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
More information about the R6RS