[racket-dev] racket2 suggestion: removing (or extending) eqv?

Something about my response below has been bothering me, and I think I know what it is: the correspondence between characters and the fixnums that represent their code points seems -- how to put it? -- more complete if it extends to their equality predicates. So, yeah, in addition to performance, there's an aesthetic motivation, too.

On May 4, 2013, at 12:03 PM, Jon Zeppieri <zeppieri at gmail.com> wrote:

> Just for performance. No other reason.
> 
> -Jon
> 
> On Sat, May 4, 2013 at 12:01 PM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> I'm curious: why do you want all characters to be eq? to each other instead
>> of just equal??
>> 
>> Robby
>> 
>> 
>> On Sat, May 4, 2013 at 10:57 AM, Jon Zeppieri <zeppieri at gmail.com> wrote:
>>> 
>>> Since incompatible future changes seem to be coming up a lot, I
>>> thought I'd add one more. What do the members of this list think of
>>> removing eqv? all of its associated machinery (e.g., memv, hasheqv,
>>> etc.)?
>>> 
>>> (Along with this change, it would be nice if characters could all be
>>> immediately represented, so that those with equal code points would be
>>> eq? RIght now, all unicode code points can be encoded in 22 bits, I
>>> think. I'm not so familiar with racket's current representation of
>>> characters, but I figure that they could easily be fit into a single
>>> machine word on 64-bit builds. I don't know how difficult it would be
>>> on 32-bit builds. And, of course, there's no guarantee that the number
>>> of code points won't increase significantly.)
>>> 
>>> Alternatively (and following Sam's line of thought from [1]), eqv?
>>> could be extended to cover all of racket's immutable data structures.
>>> In this case eqv? should also be made generic so that user-defined
>>> immutable data structures can use it, as well.
>>> 
>>> 
>>> [1] http://lists.racket-lang.org/users/archive/2013-April/057510.html
>>> _________________________
>>>  Racket Developers list:
>>>  http://lists.racket-lang.org/dev
>> 
>>