ports (really disjointness of types)

[will@cs.uoregon.edu]

[I attempted to send this message two weeks ago, but it apparently
failed to get out of Oregon.  (We've had software problems since
one of our disk drives died.)  In answer to oz's question to
scheme-standard, I favor a type hierarchy (though not the one oz
suggests).  That is, I don't see the point of trying to split the
entire space of objects into a canonical set of pigeonholes, but
I do see that requiring certain common types to be disjoint makes
it easier to write portable code.  Furthermore it is essential to
my understanding of Scheme that certain types overlap; see examples
below.]

    why...are [ports] somehow kept out of the "disjointness of types" ??

Without answering this question, does anyone know whether there
might be any significant benefit to allowing the set of input ports
to overlap with the set of output ports?  I am aware of claims that
this is useful, but I'd like to understand why.  (I am not impressed
by the convenience of packaging two ports within a single object,
which is the only explanation I have heard.)

    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.

This is specified already as part of the description of EOF-OBJECT?.

    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....

That's why the description of EOF-OBJECT? does not say that end
of file objects cannot be returned by READ, but says instead that
"no end of file object will ever be an object that can be read
in using READ".

    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.

To be perfectly consistent we will have to decide, or fail to
decide, how we want records to fit into the subtype structure
we've been constructing for Scheme.  We already have types that
overlap:  the type of LIST overlaps with the types of PAIR and the
type NULL, but the most impressive example is the type structure
of numbers:
                           NUMBER
                         /   |   \
                       /     |     \
                  EXACT      |      INEXACT
                   |         |        |
                   |       COMPLEX    |
                   |     /   |   \    |                   
                   |   /     |     \  |
          EXACT COMPLEX      |      INEXACT COMPLEX
                   |         |        |
                   |       REAL       |
                   |     /   |   \    |                   
                   |   /     |     \  |
             EXACT REAL      |      INEXACT REAL
                   |         |        |
                   |       RATIONAL   |
                   |     /   |   \    |                   
                   |   /     |     \  |
         EXACT RATIONAL      |      INEXACT RATIONAL
                   |         |        |
                   |       INTEGER    |
                   |     /   |   \    |                   
                   |   /     |     \  |
          EXACT INTEGER             INEXACT INTEGER

There's no official type structure for Scheme, of course, so
anyone can deny that any of these examples are really types.
On the other hand it's quite useful to regard them as types,
and so for expository purposes the R*RS speaks of them as
though they were (e.g. in sections 1.3.3 and 6.5 of R3.99RS).

My point is that it would be perfectly consistent to allow the
type RECORD to overlap with every type defined in the R*RS,
thereby allowing implementations in which all objects are
RECORDs.  Furthermore I believe this would be desirable.

Peace, Will