RE: RECORDs proposal

["Michael R. Blair" <ziggy@hx.lcs.mit.edu>]

 Not to detract from the Multiple Values Return debate nor the Numbers polemic
(both of which are very informative), but lest we forget about RECORDs, I have
a couple questions.  Forgive me if I missed a discussion, the outcome of which
is reflected in the original proposal, but I am concerned that the current
proposal makes it difficult for me to treat the order of slot-names in a
record as irrelevant.  First,

>  (RECORD-TYPE-SLOT-NAMES rtd)
>
>  Returns a list of the symbols naming the slots in members of the type
>  represented by rtd.  The returned value is EQUAL? to the slot-names
>  argument given in the call to MAKE-RECORD-TYPE that created the type
>  represented by rtd.

Why stipulate that this be EQUAL? to the original call?  Why does it not
suffice for it to be merely SET-EQUAL? (that is, some permutation of the
original slot-names list)?

Is there something technical you can do with the result as specified that you
would not necessarily be able to do with the result of the looser spec?  Note
one possible implementation of the looser spec is to do just what you
specified: use the identity permutation.

Why do I ask?  I would like to create a rtd by first sorting the slot-names
argument (e.g., by lexicographical order of the slot-names' print names) and
create an rtd with this sorted slot-names list.  This is because I want
slot-names to be order-irrelevant.

To that end, I'm not sure I find RECORD-CONSTRUCTOR particularly useful as it
is. To point:

>  (RECORD-CONSTRUCTOR rtd)
>
>  Returns a procedure for constructing new members of the type represented by
>  rtd.  The returned procedure accepts exactly as many arguments as there
>  were slot-names in the call to MAKE-RECORD-TYPE that created the type
>  represented by rtd; these are used, in order, as the initial values of
>  those slots in a new record, which is returned by the constructor
>  procedure.

My concern is that the generated constructor operates By Order of Arguments,
what CLtL notes is sometimes called a BOA constructor.  What I want is a
construction procedure Wherein (arg) ORder is Considered IRrelevent: a
construction WORCIR (Worker?  Rather suggests that it does a little more work
than a mere limbless reptile, no?).  For example:

I would rather see a constructor procedure that looks more like:

(DEFINE make-mumble (RECORD-CONSTRUCTOR mumble-rtd))

(make-mumble slot-name val slot-name val...)

It should signal an error if I name a slot not in the slot-names of mumble-rtd
It could be an error if I fail to name a slot that IS in the slot-names of
mumble-rtd.

Again, the point being that I want the order of slot names to be irrelevant.
To do otherwise would be to give me something not much more useful than
VECTORs.  Thus when I make an instance of some record type, I don't want to
have to order the initial values to match the irrelevantly ordered slot-names.
I would rather provide slot-name/value duples.

For the case where you don't mind observing the irrelevant defined order
(e.g., to avoid naming all the slots) you could use a RIGID-RECORD-CONSTRUCTOR
which could function as you specified. (RECORD-BOA-CONSTRUCTOR)

Or better yet, I would like a syntax like:

 (make-mumble ((slot-name val)(slot-name val)...))

since I imagine object instantiation to be essentially a binding and packaging
operation [make a bunch of bindings, package them into a RECORD, and return
the RECORD], but I wouldn't dare propose that lest you all banish me to the
mythical macro library or condemn me of perpetuating syntax.

Fnord. Not to mention defaulting. Fnord.
							~Ziggy