'() vs #F AND assignment to t-l vars.

[Jim Miller <jmiller@macadamia>]

I find it hard to distinguish these two forums at this point.  My
apologies if I offend anyone by double receipt or a feeling that the
addressing is inappropriate.

(a) Is '() EQ? to #F

It is my understanding that in both R(4-epsilon)RS and IEEE, any
conforming -program- must consider them to be distinct because there
exist conforming implementations that distintinguish them.  As far as
I am concerned this is sufficient; I prefer not to coerce implementors
where it can be avoided.  On the other hand, it can't be denied that
both the IEEE and R4RS will be simpler to read if we require
implementations (not just programs) to distinguish #F from '().  For
this reason I disagree with Jinx and feel that we should break
historical precedent and require the distinction.

On a procedural note: it has been the uniform policy of "the authors"
to allow any single individual to veto a motion (that is the meaning
of consensus).  The IEEE WG does not operate on consensus, but has a
strong precedent of making no binding technical decisions without a
formal meeting (i.e. not via the net) and has a standing policy that
no change incompatible with R4RS be made without such a meeting.

Under the circumstances, then, it seems to me that this matter is
closed.  There is a strong objection to the request that the authors
suggest a change, and the working group has no planned meeting.
I see only three options: Jinx withdraws his objection; the IEEE WG
votes by e-mail to reconvene and delay the standard by four months; or
the standard does not coerce implementations to distinguish #F from
'().

(b) Assignments to top-level bindings of names specified in the Draft
Standard.  I will not complicate the discussion much further.  There
is one point that must be clarified, however. Will and others
incorrectly state that the proposed wording makes it an error to
assign to a top level binding of a variable specified in the Standard
without first defining it.  It is not an error -- that would suggest
that implementations are encouraged to detect the occurrence and
report it to the user -- instead we deliberately phrased it as "a
conforming program may not contain an assignment..."  This wording
follows from my general "non coercion rule" above: implementations may
do as they choose, but portable programs can't depend on the results.

For your convenience, I repeat the proposed paragraph below.  I urge
you to read it as carefully as we wrote it (it took us over two hours
to understand the issues and write these three sentences).  Please
consider the following facts:

(a) There exist two kinds of implementations: those that distinguish
DEFINITION from ASSIGNMENT at the top level (perhaps they have
multiple top level environments or they choose to separate the user's
top level environment from a system level environment) and those that
identify these two operations.

(b) There are, in essence, four categories of variables at the top
level: (1) those specified in the standard (and hence visible there),
(2) those defined by the program (some of which may have the same
names as the predefined ones and therefore shadowing them as far as
the program is concerned), (3) those defined by the implementation but
not the standard, and (4) those that have no visible binding.  For
each of these four categories and two kinds of implementations, you
must understand what it means to DEFINE and ASSIGN the variable in
question.

    Conforming programs may contain top level definitions of -any-
    variable.  In a conforming implementation, no definition shall
    modify the behavior of any procedure specified in this Standard.
    A conforming program may not contain an assignment to a variable
    in the top level environment unless it has previously bound that
    variable with a top level definition; the effect of such
    assignments is unspecified.

For the record: I'm happy to reword this (I admit it is unclear as
stated) once I understand the general sentiment, and I have no truly
strong feelings about how it should go.  On the other hand, I will be
in the position of having to explain this to outsiders during the
balloting period and I will need a good understanding of the rationale
at that time.  It is important, therefore, that this community
seriously consider the issue from all angles.  That means thinking
about all 16 possible top-level operations alluded to above!

Sorry this is so long.

--Jim