<div dir="ltr">Well, I'm not sure that I buy that motivation, since I think decisions about what should be eq? to what should be driven by performance (and eq? should only be used for performance) but lets put that aside.<div> <br></div><div style>There are some unused bits in Racket's runtime representation of values, namely when a value's bit representation ends in 10, we know that it isn't a fixnum (since it doesn't end with 1) and that it isn't a pointer (since pointers have end with 00 (at least)), so I think that means that we could have all of the unicode code points represented in a way that requires no allocation (currently, iiuc, the ASCII characters are just pre-allocated at the runtime startup; they require no allocation because you always just get the same pointer).</div> <div style><br></div><div style>This is a pretty big change, however, so I'm not sure it would be worth it.</div><div style><br></div><div style>Robby</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"> On Sat, May 4, 2013 at 11:56 AM, Jon Zeppieri <span dir="ltr"><<a href="mailto:zeppieri@gmail.com" target="_blank">zeppieri@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.<br> <div class="HOEnZb"><div class="h5"><br> On May 4, 2013, at 12:03 PM, Jon Zeppieri <<a href="mailto:zeppieri@gmail.com">zeppieri@gmail.com</a>> wrote:<br> <br> > Just for performance. No other reason.<br> ><br> > -Jon<br> ><br> > On Sat, May 4, 2013 at 12:01 PM, Robby Findler<br> > <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> wrote:<br> >> I'm curious: why do you want all characters to be eq? to each other instead<br> >> of just equal??<br> >><br> >> Robby<br> >><br> >><br> >> On Sat, May 4, 2013 at 10:57 AM, Jon Zeppieri <<a href="mailto:zeppieri@gmail.com">zeppieri@gmail.com</a>> wrote:<br> >>><br> >>> Since incompatible future changes seem to be coming up a lot, I<br> >>> thought I'd add one more. What do the members of this list think of<br> >>> removing eqv? all of its associated machinery (e.g., memv, hasheqv,<br> >>> etc.)?<br> >>><br> >>> (Along with this change, it would be nice if characters could all be<br> >>> immediately represented, so that those with equal code points would be<br> >>> eq? RIght now, all unicode code points can be encoded in 22 bits, I<br> >>> think. I'm not so familiar with racket's current representation of<br> >>> characters, but I figure that they could easily be fit into a single<br> >>> machine word on 64-bit builds. I don't know how difficult it would be<br> >>> on 32-bit builds. And, of course, there's no guarantee that the number<br> >>> of code points won't increase significantly.)<br> >>><br> >>> Alternatively (and following Sam's line of thought from [1]), eqv?<br> >>> could be extended to cover all of racket's immutable data structures.<br> >>> In this case eqv? should also be made generic so that user-defined<br> >>> immutable data structures can use it, as well.<br> >>><br> >>><br> >>> [1] <a href="http://lists.racket-lang.org/users/archive/2013-April/057510.html" target="_blank">http://lists.racket-lang.org/users/archive/2013-April/057510.html</a><br> >>> _________________________<br> >>> Racket Developers list:<br> >>> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br> >><br> >><br> </div></div></blockquote></div><br></div>