[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: why generative?

This page is part of the web mail archives of SRFI 99 from before July 7th, 2015. The new archives for SRFI 99 contain all messages, not just those from before July 7th, 2015.

I responded to Shiro, but neglected to cc srfi-99.  Here it is,
with a minor correction.

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?  If you concatenate a flattened
representation of its current state, you won't get a match if
the same record is mutated and then used in a subsequent call
to make-rtd.

Even if all of the arguments to make-rtd are immutable, some may
contain mutable records, so you can't get around that just by
using eqv? to compare mutable fields.  I don't yet see a coherent

> It still requires one pointer dereference compared to the
> eq?-style pointer comparison.

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.

> 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.