macro definitions (was: draft minutes of June 1992 meeting)

["Aubrey Jaffer" <jaffer@martigny.ai.mit.edu>]

   From: jar@cs.cornell.edu (Jonathan Rees)
   Date: Thu, 12 Nov 92 19:06:59 -0500

   For any given name, if the first occurrence(*) of that name in a
   program is a definition for that name, then there's no ambiguity,
   regardless of the name's original (built-in) binding or new binding:
   all occurrences of the name refer to the binding specified by the
   definition.
   ....
   The situation starts to get confusing only when a reference precedes a
   definition.  There are four cases, depending on what kind of binding
   (if any) got replaced, and what kind of binding it's being replaced
   by:

     (1) No preceding syntax binding, definition is a DEFINE
     (2) No preceding syntax binding, definition is a DEFINE-SYNTAX
     (3) Name had a syntax binding, definition is a DEFINE
     (4) Name had a syntax binding, definition is a DEFINE-SYNTAX

   By "preceding" bindings I include built-in ones, e.g. those for
   DEFINE, CAR, etc.

   I believe that the intent of those of us responsible for the "no
   reserved identifiers" position is that in cases (2) through (4), the
   program is in error.  In a system that must examine partial programs,
   the error may not be detectable until the definition is seen.  At that
   point the conscientious Scheme implementation will detect and report
   the problem, and take some reasonable recovery action; but to give
   latitude to our already-beleagured implementors, detailed action
   shouldn't be specified by the report.  (Good error reporting requires
   the implementation to keep track, for each name, whether there have
   been any references to that name.)  In fact some implementations might
   not detect the problem at all, or might not detect it until the code
   containing the offending forward reference is executed.

Thank you for this clear explanation.  In this case, I think some
further work needs to be done to the Syntactic Closures macro
implementation (Chris Hanson et al) in order to make it comply with
this behavior.
  (define begin 8)
gives an error in Syntactic Closures because this form is passed to
the underlying Scheme implemation.

Does any R4RS macro implementation satisfy this
no-reserved-identifiers statement?  If not, I suggest it is a
precarious situation when there exist no actual implementations
satisfying a specification.