portability

[Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>]

OK, my message seems to have confused a lot of people.  I'll try to be
clearer.  For the purposes of this message I'll only consider
system-supplied special form types, not user-supplied ones, although the
problems are I think the same.

Jim Miller said originally that he didn't see any way to write portable
programs which used variables, because implementations were free to
preempt arbitrary variable names for use as syntactic keywords.  I just
wanted to reply that on the contrary, the report is clear on what the
set of allowable variable names is.  The BNF describes a <variable> as
being any <identifier> which isn't a <syntactic keyword>, and the
<syntactic keywords> are enumerated.  E.g.  according to my reading of
the report, the sequence

	(define block (lambda (x) (extend x 3)))
	(define extend (lambda (a b) (list b a)))
	(block 1)

has a perfectly well-defined meaning: BLOCK and EXTEND are variable
names (unconditionally!); these names become bound to values; the value
of BLOCK is applied to the number 1; etc.  I didn't see anything in the
report which allowed any implementation to assign any other meaning to
this program fragment.  Any implementation which did something different
with this code fragment (e.g., T, which has BLOCK-expressions, and
independent namespaces for variables and keywords) would not be
implementing the language described in the report.

I don't think this is a departure from the previous report, although of
course my edits have made the *description* follow my world view more
closely.

The way so-called "syntactic extensions" usually (not always) work,
however, is that they pre-empt certain identifiers for use as variable
names.  E.g. an implementation might make BLOCK or EXTEND unavailable.
Or, worse, the variables remain available, but expressions whose cars
are these names are no longer treated as procedure calls.  Then the
above program wouldn't have the expected meaning.  I say that such
modifications to the language aren't syntactic extensions, since they
incompatibly change the meanings of programs, rather than just defining
what would otherwise be an error situation.

If the implementation is clever enough that program fragments like these
still work, i.e. the extensions are only seen when the variable is
undefined (a situation which would otherwise be an error), then that's
fine, but I don't think that's how most scheme implementations out there
actually implement their additional special form types.  (Correct me if
I'm wrong.  Consider forward references.)

Implementations can support macros (they can also support Algol 60 mode,
or any other incompatible change, if they want -- it's not as if it's a
sin to program in something other than reportified-scheme), so long as
there's some way to run programs written in the language described in
the report.  Several existing implementations are already structured to
make it easy to support multiple such modes or incompatible dialects; so
what's the big deal?

In short: why should the report say anything at all about this issue?
To warn implementors not to do the wrong thing?

Do we want to change the report to explicitly ALLOW the preemption of
arbitrary variable names?  I think Jim's question originated from a
belief that implementations were free to do this and still claim to be
adhering to the report.  I think that's absurd.  How should the report's
examples, much less portable programs in general, be written in that
case?

Jonathan