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