[R6RS] eq?/eqv? on immutable pairs, records, etc.

[R. Kent Dybvig]

> What other immutable objects are we talking about?  Procedures,
> immutable records and hash tables, right?

Right, and possibly immutable strings and bytevectors.

> For procedures, it seems especially insidious to require a location.

I don't care as much about making eq?/eqv? work reliably on procedures as
for immutable pairs and records.  In r5rs and perhaps before, however, the
intent was that eq?/eqv? would work on procedures used to implement
objects with state.  Some people (including me) felt this was useful, some
did not.  I've also seen people use eq? to recognize specific procedures
in the interfaces for various procedures.  (Common Lisp's hash-table
mechansism does this.)

> I don't care about hash tables---we might as well give even the
> immutable ones a location.

I think the treatment of hashtables should be consistent with the treatment
of records.

> However, for immutable records, it seems to me unboxing analyses are
> kind of important---especially as records are the means of choice to do
> representation hiding.  Maybe we could add another clause or an option
> to the `immutable' clause that forces a location.

Systems that unbox must already handle cases where objects escape and in
such cases either (a) avoid unboxing, (b) retain the original boxed object
as well as the unboxed pieces, or (c) rebox at the point of escape.  With
approaches (a) and (b) the system can simply consider reaching a call to
eq?/eqv? as a form of escaping, with virtually no added compile-time cost
or complexity and no run-time cost for objects to which eq? and eqv? are
not actually applied.  I do not see how to make approach (c) work in
general.  On the other hand, I suspect that approach (b) is typically more
effective than approach (c), and it is more general in that it allows a
partially immutable object to be partially unboxed.  So losing the ability
to use approach (c) bothers me much less than, say, losing the ability to
use immutable records as keys in a hash table.

We could add an identity option to the record system, and I would rather
do that than lose eq?/eqv? for immutable records, but there's little
enough benefit to allowing implementations to copy immutable objects that
I prefer to keep the language simple.

Kent