Programmer-defined data types, last (?) version

[Alan Bawden <bawden@parc.xerox.com>]

    Date: Tue, 5 Sep 89 07:27:19 edt
    From: Jim Miller <jmiller%cs.brandeis.edu@relay.cs.net>
    ...  I don't like the fact that the type name is a string, and the
    rationale makes no sense to me whatsoever....  Why not leave the
    position entirely unrestricted, since it has only one property of
    interest: given a record you can retrieve this value.

Perhaps I want to write a portable browser.  I want to be able to display
things like:

  The object #<RECORD 343241> is a Spaceship.  It's fields are:
    CAPTAIN:  #<RECORD 442425>
    X-POS:    3142.776
    Y-POS:    0.0

If an implementation is free to re-use that argument, assigning it a role
other than as a DISPLAYable representation of the type, then in that
implementation you will see:

  The object #<RECORD 343241> is a #<CLASS 671726>. 
  It's fields are: 
    CAPTAIN:  #<RECORD 442425>
    X-POS:    3142.776
    Y-POS:    0.0

So my browser wasn't really portable after all.

It is true that the only formal property you can specify about the first
argument to MAKE-RECORD-TYPE is that you can read it back later.  But
programming languages are more than just a denotational semantics.

MAKE-RECORD-TYPE has an infinite number of arguments left unspecified
(assuming we don't adopt a recent proposal), which seems to me plenty of
room to experiment.  Why insist on overloading the first one?