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 <zeppi...@gmail.com> wrote: > Just for performance. No other reason. > > -Jon > > On Sat, May 4, 2013 at 12:01 PM, Robby Findler > <ro...@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 <zeppi...@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 >> >> _________________________ Racket Developers list: http://lists.racket-lang.org/dev
