[R6RS] new syntax srfi draft, reference implementation

[William D Clinger]

I'm going to speak for myself here, although I believe some
of Mike's concerns are similar to mine.  All quotes are from
Kent's response to Mike's rant.  Two-level quotes are Kent
quoting Mike.

> I've since addressed this "bogus keyword reference" issue, incidentally,
> in the current draft of the SRFI and reference implementation.  The
> algorithm now raises an exception in cases like the second of each pair of
> examples above where a keyword referenced during the expansion of one
> definition is redefined by the same or a subsequent definition in the same
> body.  This is basically an expand-time version of the letrec*
> restruction.

I think that solves the main problem that was bugging me.
I'd like to see it described in terms of identifiers and their
scope, instead of being described in terms of the algorithm.
I think the desired restriction is something like:

    The scope of an identifier defined by an internal definition
    (which may be an internal define-syntax) consists of the
    entire body at whose head the internal definitions appear
    after macro-expansion of the body.

    An error is signalled if the first pass of macro-expansion
    of the body (to determine the internal definitions) would
    be different when expanded in a syntactic environment that
    excludes all of those identifiers than when expanded in a
    syntactic environment that binds all of those identifiers
    to the meanings they are given following macro expansion.

One potential problem with this language is that the syntax
SRFI uses the word "identifier" in a rather strange way.
This shows up in section 3.2, where the word "identifier"
is italicized to show that it is being given a technical
meaning that is probably at variance with the informal
meaning most readers will have given to its previous
occurrences within the syntax SRFI.  I think the best
way to deal with this is to invent some other term for
the wrapped syntax objects, and to use the word identifier
only when it means what it usually means in the context of
a programming language.
    
> > My impression of the historical process is that, in
> > Scheme, internal `define' was added before macros---it wasn't a
> > problem then, just a bit of syntactic sugar.  Then macros were added,
> > and, because nothing was done about internal `define', the screw was
> > turned a bit more.  Now, the next bit for R6RS.
> 
> Your impression is wrong.  Many Scheme systems (including perhaps all of
> those represented by the revised-report authors) had macro expanders at
> the time internal define was adopted as an optional feature, and by the
> time it was required by the IEEE standard, we were actively working on
> syntax-rules and various low-level hygienic macro expanders---including
> syntax-case.

Mike's impression is correct.  The MIT folks (Sussman and
friends) had become disenchanted with macros and had removed
them from their implementation.  They then added internal
definitions to a language that did not have macros.  At the
Brandeis meeting, internal definitions were accepted as an
optional feature, grudgingly by some (notably the Indiana
folks, which did not include Kent at that time), and only
because they were so prominent in SICP, which already existed
in draft form and had gone or was about to go to the printer.

Neither the R2RS nor the R3RS nor the IEEE/ANSI standard
mentioned macros.  The fact that Kent and many others were
actively doing research on macros during this time doesn't
mean they were part of the language.  They didn't become
part of the language until the R4RS.  Hygienic macros were
indeed added to a language that had internal definitions
but no macros, as Mike wrote.

Will