>From: William D Clinger <xxxxxx@ccs.neu.edu>
Subject: Re: why generative?
Date: Thu, 3 Sep 2009 13:10:39 -0400 (EDT)

> Shiro Kawai wrote:
> > Yeah, that was my mistake.  We don't even need to calculate
> > a hash value.  Make-rtd can create a symbol that encodes the
> > input values that matter (e.g. concatenating canonical
> > representations of each value with a special separator).
> > Such a symbol serves as a unique id.
>
> Maybe, but I still don't see it.  What if one of the arguments
> to make-rtd is a mutable record?

By making RTD "functional" I'm thinking that an RTD will never
change its behavior as a type descriptor in any observable way
after it is created.  (An implementation may add extra mutable
information, e.g. debug log, but they shouldn't affect the
behavior of the RTD as a type.)

Current SRFI-99 make-rtd doesn't seem to be able to take
mutable records.  The only aggregate types it can take are
a vector as fieldspecs and an RTD as parent.  I believe
the fieldspecs vector and its elements should be treated
immutable semantically (i.e. RTD is defined by its content
at the creation).  If the fieldspecs vector and its content
are immutable, the parent RTD is also "functional".

My proposal allows uid to take a mutable record.  The sole
purpose of passing mutable record as uid is, however, to
guarantee uniqueness; the field is compared by eq? thus
only their addresses matter.

> If that were all it required, I wouldn't care about that.
> I'm more concerned about the semantics and what seems to me
> to be an implied recursion that compares potentially circular
> and potentially mutable objects.

If RTD's fieldspecs (including its elements) and parent are
immutable, and we compare uid with eq?, we don't need to worry
about these.

> > I do see it a big disadvantage that R6RS-style nongenerative
> > uid implies a separate global namespace *semantically*.
> > We've been very careful introducing separate namespaces, and
> > I don't feel like this uid namespace is justified well.
> > Making rtd "functional" is one way to eliminate this separate
> > global namespace.
>
> One standard justification for using generative or nominal
> equality as the default instead of structural equality comes
> from records whose fields have implicit units.  Consider,
> for example, several record types that both contain immutable
> fields x and y.  Some represent points in polar coordinates,
> others in Cartesian; some use inches as the units, others use
> light-years; others don't represent points at all.
>
> With your proposal, all those record types would be treated
> as the same unless the programmers remember to add a unique
> object that differentiates them.  The R6RS approach of using
> a uid when you want them to be the same feels less dangerous
> to me.

In most programming languages programmers do give unique names
to the different record types with same field specs.  I assume
we can ask that much of work to the programmer's side if she
wishes to have distinct types.

Using the syntactic layer, a programmer gives a name to the
record.  The syntactic layer may use that to create a unique id
to distinguish types with the same fieldspecs.

--shiro