Re: Generative record types

["R. Kent Dybvig" <dyb@cs.indiana.edu>]

> Perhaps it would help me and others who have been on the sidelines if
> someone (you?) could summarize why those proposals failed in the past
> (and how, if at all, those proposals differed from ours).  My
> impression, gleaned from sampling past discussions, is that a lot of
> discussion centered around issues like opacity.  We tried to
> explicitly deflect attention from that.

My objections to the make-record-type proposal are as follows.  As you
can see, they are largely addressed by your define-struct proposal.

1. I am in favor of opaque types, and object to the make-record-type
proposal on the grounds that it builds into the language support for
breaking abstractions.  If we had a mechanism for specifying
programming environment support, abstraction breaking mechanisms would
be worth considering, but not as part of the language.

One value of opacity is that it simplifies program analysis, both by
the user and by the compiler.  When programming, it's nice to be able
to scan the code where a record type declaration is visible and know
whether a field is used, whether it is assigned, and what type of value
it holds.  If any part of the program to which we pass the object can
obtain a field accessor or mutator, we've lost this ability.  Why do I
care?  I can give several reasons, but one simple one is that I like to
remove from records fields that are no longer needed, and I have a lot
more homework to do if I can't be sure someone isn't creating accessors
and/or mutators on the fly.  Why does the compiler care?  The compiler
might like to do type inference, which is made much more difficult if
we can't even determine where or whether field mutations occur.  The
run-time system may also care: Our storage management system, for
example, likes to segregate immutable objects from mutable ones for
performance reasons, and we can't do that unless we can prove that no
field mutators exist.

2. I object to the procedural interface and prefer a syntactic
interface for two reasons.  First, the procedural interface is verbose,
so that portable code that uses it either will be ugly or will have to
carry with it the (possibly sizable) definition of a syntactic
extension.  Short snippets of expository code involving records either
won't be short or, if they employ a syntactic extension without
defining it, won't be well-specified.

Second, the procedural interface is difficult to compile efficiently
because it is too unstructured and too general.  The result will be
that each implementation that bothers to try to generate good code will
recognize only certain stylized uses (those produced by the local
define-record-type syntactic extension), so that code won't be portable
with any reasonable degree of efficiency.  By standardizing on a
syntactic construct, we stylize all code and introduce restrictions,
e.g., that all accessors and mutators be created together, that will
allow even simple compilers to generate good code.

3. I prefer that we build in a way to specify immutability of fields,
although with a syntactic interface a good programmer or compiler can
determine immutability easily enough.