[R6RS] Records draft

[Michael Sperber]

[BTW, your MUA has been mangling your emails recently, especially
multi-column displays.]

Marc Feeley <feeley at iro.umontreal.ca> writes:

> 2) The short form is (define-record-type name formals...) and the  
> long form is (define-record-type (name constructor predicate) formals...).   
> Why parens in the second case and not in the first?  Only because formals is  
> a list and it would be ambiguous to put parens only around the constructor  
> and predicate. This strange syntax is caused by using a positional-only approach  
> to specifying the arguments of the define-record-type form.  

I'm not sure I understand the comment: First off, the
DEFINE-RECORD-TYPE form is *not* positional-only, as can be seen in
your first example:

>        keyword-based                  positional-based (as proposed)
>
>    (define-record-type point     (define-record-type point (x y)
>      x                             (fields ((mutable x) x)
>      y)                                    ((mutable y) y)))
                                      ^^^^^^ keyword

In fact, we used keywords exactly for the reasons you advocate.  (The
same holds for the PARENT and NONGENERATIVE clauses.)

I think what you mean is keywords within the clauses of the FIELDS
form.  The syntax we have certainly allows that, even though we didn't
have any optional things we wanted to put in at the time.  I'm
certainly amenable to discussing alternatives for syntax within
FIELDS, but I'm not sure it's really a productive way of spending our
time (see below).

As to why the first operand of DEFINE-RECORD-TYPE is the way it is:
Our view (Kent's and mine, Mike Ashley was also there) was that just
specifying the record-type name is a shorthand for specifying the
names of the predicate and the constructor.  Keyword syntax for that
would be possible, but that would make the DEFINE-SIMPLE-RECORD-TYPE
(where these clauses would be required) more verbose (at least to the
point where the three of us could figure it out), and would hurt the
smoothness of the transition between the two.

>    I can imagine a future extension of the record definition form
>    where more than one constructor can be specified.  But such an
>    extension will be hard to tack-on to the syntax proposed.

No, it will be trivial to tack on in essentially the same way as you
propose, because the record clauses carry keywords.

> 4) The name "define-record-type" is too long for my taste, I prefer
>    "define-record" or simply "define-type".  How sweet it would be to
>    have lightweight (and easily understandable) code like this:
>
>      (define-type point x y)

I disagree that it is easily understandable, but that's beside the
point: We won't come up with with a record-type-definition form that
everyone likes---the proliferation of different ones in the various
implementations, and the discussion we're having right here proves
that.  Arguing about the "best" syntax on this list is therefore
highly unlikely to get us anywhere.

What we should do instead is provide a common infrastructure, and take
a shot at providing a reasonable convenience layer.  That's why there
are three layers in the proposal.  The convenience layer can't be and
doesn't have to be perfect.  For Kent and myself, the "smooth upgrade
path" between the primitive syntax layer and the convenience layer was
important in taking that shot.

Whatever convenience layer we provide, not everybody will be happy
with it, and they can go and define their own.  Making this work:

(define-type point x y)

is trivial on top of of DEFINE-RECORD-TYPE.

> 5) Finally, I see no mention of "final" (non extensible) record  
> types, 

I'd be happy to put that in.  I'm not sure it's a good default
though---what if you want to extend a record-type definition sitting
in a piece of code you can't change, where the author merely forgot to
put in that additional keyword?

-- 
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla