[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: why generative?
From: William D Clinger <will@xxxxxxxxxxx>
Subject: Re: why generative?
Date: Thu, 3 Sep 2009 20:15:50 -0400 (EDT)
> Shiro Kawai wrote:
> > Here's one idea:
> > An implementation may extend make-rtd so that it can take
> > a symbol 'nongenerative and another symbol (name) in the
> > optional argument list. Then make-rtd returns an RTD
> > that is semantically equivalent to another RTD with the
> > same field specs, parent rtd, opaqueness, sealedness,
> > and the name. How to realize this equivalence is up
> > to the implementation; it can calculate a unique signature
> > and use it to distinguish rtds, it can memoize make-rtd
> > arguments, or it can use element-wise comparison.
> Isn't that equivalent (modulo the use of 'nongenerative
> instead of 'uid) to the recommended semantics for the 'uid
> extension that's already described by the draft of SRFI 99?
SRFI-99 says "The semantics of this extension [uid] is the
same as described by R6RS".
R6RS requires the system to check the rtd with the same uid
must have the same field specs etc. This *requires* some form
of a global table that maps uid to existing rtds. This is
also the cause that the code must use lengthy and cryptic
uids like GUID to avoid accidental conflict of uids.
In my suggestion, two rtds are different even if it has the
same uids but different field specs. A library can have
a record type with nongenerative id 'Point and two fields
x and y, and another library can have a record type with
id 'Point and three fields x, y and z. Two record types
are distinct. I don't think this will cause confusion.