On Fri, Feb 14, 2014 at 10:17 PM, Taylan Ulrich Bayırlı/Kammer < [email protected]> wrote:
> > The `eqv?' definition says that records are equivalent if denoting the > same location and points to section 3.4, which explains that the notion > of "storage being newly allocated" is what denotes the creation of > objects with distinct locations, yet section 5.5 (<constructor name> > point) doesn't use that phrase. In short, we base record equivalence > semantics on their location, yet don't specify their location. > Correct. The section needs to be expanded to specify at least the discerning of > obviously inequivalent records (mutable and created with distinct calls > to the constructor, or immutable but having non-eqv? fields). (Note > that we already support immutable record types by omitting mutators.) > There are two issues, of course - specifying under what circumstances, if any, a record constructor must return a newly allocated record, and specifying the eqv? semantics. "The returned record must be newly allocated if any <modifier name> is > provided, or if not all fields have an initial value that is equivalent > per eqv? (section 6.1) to the corresponding field value of a record of > the same type." > I'm not sure what you're trying to specify about the initial values here, but it may be simpler to just leave this out. "The constructor guarantees a newly allocated record if there are any mutable fields." You can't assume anything about immutable records, including the degenerate empty record case. [Note, simply not providing a <modifier> is not sufficient to guarantee immutability in the presence of SRFI 99 style record introspection.] Ideally, IMO, the equivalence semantics of all objects created with > constructors would follow the logic we used for procedures > Ah, well this was rather controversial itself :) While a stronger case can be made for desiring predictable record identity, similar optimizations still apply. This isn't really something we can just write in as an errata. Maybe in R8RS. :-) > Yes, I think so. -- Alex
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
