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