Alex Shinn <alexshinn@gmail.com> 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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports