Less verbose type definition form (was: [R6RS] Records comments)

[dyb at cs.indiana.edu]

Marc,

A record-definition facility based on your syntax could probably be made
to work for my purposes, since I won't often want to specify the product
names explicitly.  I can certainly see, however, why it is not suitable
for those who do want to specify the names of all products explicitly:
always having to use keywords to specify the constructor and predicate
is surely going to seem tedious and inelegant, and the resulting record
definitions will be no less verbose.

Even for my purposes, there are some cosmetic things I would change.
For example, I would require that the fields be listed first, not
interspersed with the keyword options, and I would group the fields or
keyword options within parens to lift the restriction on field names
not ending in colons.

I would also include better support for specifying constructors.  With or
without your proposed constructor extension, the code that sets up a
child record needs to know more than I think it should have to know about
parent records: in particular, the exact number of parent fields and how
they should be initialized.  This can be solved in a general way with a
constructor-procedure option that defers to the parent constructor for
its part; I can elaborate on this if you want.  I've actually implemented
this more general mechanism but backed off to essentially what is in our
proposal because the mechanism in our proposal naturally handles nearly
all of the constructors I've ever wanted to write.

I will also note that your syntax won't be any less verbose for the
majority of record definitions I write.  I seldom define a record
for which the initial field values are in one-to-one correspondence
with constructor arguments, so I'll either have to write a separate
constructor and polute the namespace with an extra name (which I can't
rid myself of because I have no local modules ;-) or add both init:
keywords and an explicit constructor: option to the record definition.
Most of the records I use have immutable fields, and I'll want to specify
that as well.

In fact, in my experience, fields that are initialized by constructor
arguments can nearly always be declared immutable, while fields that
must be mutable are nearly always initialized to some default value.
So I would almost never take advantage of your simple syntax.

In short, while I think you and I might be able to hammer out a syntax
based on your proposal that is agreeable to both of us, it may leave
those who want to explicitly name their products unhappy.  I think the
other proposal strikes a better balance and would prefer to work with it
as a basis.  As I said before, I'm willing to include shorthand syntaxes
if necessary to reach consensus, even though I feel it is more elegant
to specify mutability and field initialization explicitly.

Kent