Alex Shinn <[email protected]> writes: > `gensym's have names, so they would not be empty. > > For the tokens you create above, it really doesn't matter > if you substitute one for the other. Given that there is > no other way in the language to tell them apart, it doesn't > make sense to require `eqv?' to do so, at the expense of > potential optimizations.
Right, I was thinking with a too "low-level" mind-set, equating usage of a record constructor with an explicit allocation. > Many people want different extensions to records, > notably the ability to create opaque and/or immutable > records, as well as inheritance, etc. We left both such > extensions and `equal?' semantics on records up to > the large language, and so were conservative in what > we specified in the small language for `eqv?'. I understand but, at present there seem to be *no* semantics at all for record equivalence, not even the requirement to discern obviously inequivalent ones. 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. 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.) (On the other hand I take back the former alternative in my proposal; we shouldn't prescribe new allocation for equivalent immutable records, implementations should be allowed to optimize there, so simply substituting "a newly allocated record" for "a new record" in section 5.5 is not an option.) I'm making the concrete proposal of appending the following sentence to the paragraph that explains <constructor name> in section 5.5: "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." A bit awkward but I can't come up with anything clearer, feel free to improve the wording. Ideally, IMO, the equivalence semantics of all objects created with constructors would follow the logic we used for procedures: every object returned by a call to a constructor is conceptually tagged to make `eqv?' return #true, but returning #false is only prescribed in the case of operational inequivalence. (We /could/ also prescribe #false return for distinct location tags but allow constructors to return objects with identical location tags.) The conceptual tags could be extended to apply to object literals of the relevant types as well. This would bring great uniformity and shorten our prose in several sections, and the semantics would be ideal as far as I see, describing the bare minimums for both #true and #false returns from `eqv?'. (We might want to also prescribe an upper bound for the time complexity of `eqv?', for certain types of objects.) Maybe in R8RS. :-) Taylan _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
