[R6RS] eq?/eqv? on immutable pairs, records, etc.
R. Kent Dybvig
dyb at cs.indiana.edu
Wed May 30 12:29:07 EDT 2007
As I mentioned, I would like to revisit the eq?/eqv? issue. When I gave
my blessing to go ahead if there was no support for my preference for eqv?
to behave as it traditionally has on allocated objects, I overlooked some
important uses for eqv?. I've already mentioned that the change breaks
eq?/eqv? hashtables for immutable objects. Since then I have been
reminded of another issue. One of my PhD students has developed a
live-analysis algorithm that derives its fast performance in part from the
ability to detect eq? sets (represented as immutable records; the details
aren't important). Adding an explicit identity field would not change the
asymptotic behavior, but it would change the constant factors.
I realize that by not permitting implementations to make multiple copies
of immutable objects, we would be inhibiting certain transformations.
Doing so adds no complexity, however, as implementations need only treat
such objects as they already must treat mutable objects. It is also
possible for implementations to uninhibit the transformations when they
can determine that the identity of an immutable object is never tested.
A reasonable compromise position might be to allow multiple copies of
quoted constants to be created, i.e., for the semantics to leave such
objects untagged. This would allow the kinds of beta substitutions that
we have talked about to occur without any additional checks.
More information about the R6RS