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