redefining keywords I'm not doing a good job

[jar@cs.cornell.edu (Jonathan Rees)]

[It appears that some people didn't see my earlier message on the
subject of redefining keywords.  Perhaps rrrs-authors@ai.mit.edu is a
black hole?]

From: jar@cs.cornell.edu (Jonathan Rees)
Date: Thu, 12 Nov 92 19:06:59 -0500
To: jaffer@martigny.ai.mit.edu
Cc: rrrs-authors@ai.mit.edu
In-Reply-To: "Aubrey Jaffer"'s message of Fri, 6 Nov 92 14:59:26 -0500 <9211061958.AA25920@life.ai.mit.edu>
Subject: macro definitions (was: draft minutes of June 1992 meeting)

I don't think I saw anyone answer this, so here's my 2 cents.

   Date: Fri, 6 Nov 92 14:59:26 -0500
   From: "Aubrey Jaffer" <jaffer@martigny.ai.mit.edu>

   In the first column of the Macro Appendix is the claim "With this
   extension, there are no reserved identifiers."  This seems ridiculous!
   What about LET-SYNTAX, LETREC-SYNTAX, SYNTAX-RULES, DEFINE-SYNTAX, and
   BEGIN?

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.  So there is no problem with a program in which

 (define-syntax define ...)

occurs before any occurrence of the name DEFINE, or

 (define define-syntax ...)

occurs before any occurrence of the name DEFINE-SYNTAX.

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.

Case (1) happens all the time (e.g. (define car 'studebaker)), and its
meaning is not affected by the addition of macro definitions to the
language.  Whatever was the case before still is.

Case (2) is the one you asked about with your foo/bar example, but
also includes e.g. the program fragment
	(define foo (cons 1 2))
	(define-syntax cons ...)
Case (3) includes (define define ...); case (4) includes
(define-syntax define-syntax ...).

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.


(*) To simplify the exposition I say "occurrence of the name" to mean
any lexical occurrence that's outside the region of a LAMBDA,
LET-SYNTAX, or LETREC-SYNTAX binding; i.e. a reference that has to be
to a top-level binding of the name.

Jonathan