[R6RS] new syntax srfi draft, reference implementation

[dyb at cs.indiana.edu]

Thanks for your detailed comments, Mike.

> - 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.)

Through constructed programs that are passed to eval and constructed
syntax objects returned by transformers.  The issue can also arise in
other ways, such as through the #n= and #n# syntax, in particular
implementations (and possibly in future reports).

> - 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've rewritten the abstract and rationale to avoid the use of these terms. 
The terms still appear under the description of datum->syntax, where they
are explained.

> - 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.

Since the connection is so straightforward, I'm afraid that any attempt to
spell it out will seem silly, but I've put a note at the top of the source
file to try to deal with this at some point.

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

They certainly aren't top-level, and it's handy to have a common term for
both.  I could replace "internal definitions" with "internal or
library-level definitions" everywhere it occurs, but that seems rather
clumsy.  Do you have a better idea?

> - 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.

I don't understand what you mean, and I don't see any problems with the
syntactic abstraction item.  Please elaborate.

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

It can't until we nail down the library SRFI.  Nailing down the library
SRFI is next on my list.

> - 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.

I don't think it's unfortunate at all.  The examples are easier to
understand without bringing library semantics into the picture, especially
since the library semantics has not yet been nailed down.

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

Fixed, thanks.

> - 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.

I intend to add an algebra, and there's a note at the top of the source
file to this effect, but I haven't gotten to it yet.  In the meantime, I
have put in a reference to Section 2.4 of Oscar Waddell's dissertation. 
upon which the algebra will be based.

> - "subtitutions" -> "substitutions"

Fixed, thanks.

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

A reference to a keyword, i.e., an identifier reference that resolves to 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 [...] 
>   values" mean?)

I've rewritten the sentence in an attempt to make it more clear.

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

I don't see any that are in tt.  Please let me know where you spotted them.

> - 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.

Fixed, thanks.  (I assume you meant "ellipses" -> "ellipsis".)

> - 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."

This is just trying to clarify what happens if neither identifier resolves
to a binding.  I've attempted to make the meaning more clear by replacing
the offending sentence with the following parenthetical remark.

  (If neither of two like-named identifiers resolves to a binding, i.e.,
  both are unbound, they 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?

That would be fine with me.

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

There's a brief explanation and a forward reference to the full
description just before the first use.

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

I would say not, unless we're also going to require similarly more robust
versions of let and other derived forms.

> - 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? 

I'd be happy to include a more explicit discussion of the issues if you
want to take a stab at it, but the referenced message appears to be more
about local modules than internal definitions, and it also contains a
misleading description of the expansion algorithm.  This could confuse
people if referenced from the SRFI.

> - 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?

We can allow interleaving for internal definitions if we want, but I think
the change might be controversial and that we would be better off leaving
this for R7RS.  Allowing interleaving in the future won't cause any
backward compatibility problems, so there's no need to put it in right
now.

In any case, we haven't decided that R6RS will have top-level definitions
and, if so, whether such interleaving will be allowed, and the top-level
semantics of existing implementations varies from one to another.  So it's
a bit funny to talk about doing anything specific to align the semantics
of internal and top-level definitions.

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

Fixed, thanks.

I've committed a new version of the srfi src, html, and pdf files with the
changes mentioned.

Kent