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

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.

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).

This is a pretty big change, however, so I'm not sure it would be worth it.

Robby



On Sat, May 4, 2013 at 11:56 AM, Jon Zeppieri <zeppieri at gmail.com> wrote:

> 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
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130504/384c1bb2/attachment.html>