[oz@nexus.yorku.ca: ports...]

[jinx (Guillermo J. Rozas)]

    Actually, it seems like it's even more important to specify that
    eof-object? is not true of anything that could be the result of a READ,
    which includes everything on the list of disjoint types except
    procedures.

Clearly EOF-OBJECTs are the result of READ when READ is invoked on an
file port at the "end of file", so we can't require EOF-OBJECTs not
to be returned by READ.  Furthermore, I'm not sure that it is a good
idea to require that READ only return EOF-OBJECTs at the "end of
file".  The rationale is as follows:

- Some systems may want to have the equivalent of #. (ugh!).  We would
be requiring such systems to have a different reader, or to restrict
EVAL so that it could not return EOF-OBJECTs.

- Some systems may associate with each printed object some tag (a hash
number, interaction number, etc.) which may be used to specify at
read-time the object (so that printed procedures, for example, may be
referred to).  Such systems would then have to special case
EOF-OBJECTs potentially printed by WRITE, for otherwise the user could
specify them via the tag.

Admittedly, in either case, the user might be in trouble since her/his
interaction stream might be closed behind them, but that is her/his
problem for trying to read an EOF-OBJECT, although that may have been
the intent (akin to typing ^D in Unix).

I would not object to making EOF-OBJECTs distinct from any CHARACTER?,
although it's not clear to me that it is necessary or desirable, since
after all, it would only be natural for someone to implement
EOF-OBJECT? as a test for ASCII end-of-text.


At the meta level, I'm very worried about this frenzy to make
everything distinct from everything else.  You are committing
implementations to either have more primitive types, or more expensive
type tests.  In particular, I don't see how all this generalizes if we
ever attempt to integrate something like JAR's record package.  At
that point we will have a RECORD? predicate, and to be perfectly
consistent, RECORDs should be disjoint from all other types, but that
would prevent me from representing ports (and perhaps even lists) as
records, which I don't think anyone desires.

I think we are gradually overspecifying this language, and we may
easily get ourselves into a hole.