Re: portability

[Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>]

I don't think this issue is as cut and dried as all that.  Jonathan
is right on the one hand; it is ``absurd'' to write portable programs
if any identifier might be taken away by a particular implementation.
However, it is not clear to me what the most practical solution is
at this point for systems that have additional special forms or user-
defined macros.  It is certainly not practical to stay away from all
special forms but those appearing in the report.  Nor is it practical
to invalidate a macro when a binding is found; as Jonathan points
out, forward references become a problem.  Perhaps it is practical to
complain when a binding is found; this does not allow portable code
but it does provide some level of sanity.  And I'm not sure it is
practical to have a "vanilla" mode; although the issue is worthy of
consideration, what happens when someone wants a basically portable
piece of code to use a system-specific special form?

If I had to take a stand one way or another, I would probably favor
a more liberal definition of keyword---rather than saying that all
of the keywords are enumerated in the report, I would allow for the
inclusion of additional keywords by any particular implementation,
with the requirement that any implementation must provide a warning
when a keyword is used as a variable.  Writing portable code would
be an iterative process, but it would be relatively painless.

But I don't really want to take a stand at this point.  I would
rather leave this topic, along with the whole topic of macros, out of
the report.  That way we could experiment with various ways of doing
things and at some point agree on the most practical way of dealing
with the situation.

(I was going to suggest that we require keywords to begin with an
upper-case letter so that portable code could be written by employing
only lower-case variable names, but I remembered that Scheme is case-
insensitive.  Sigh...)

Kent