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

Personal opinion: performance is a dangerous motivator. Yes, it is
a necessity, but it is often abused as a reason to do something.

There's a semantic difference between eq? and equal? from the point
of view of mutability. Two objects are eq? if modifying one also
modifies the other. They are equal? but not eq? if they are the
"same", but modifying one will not modify the other.

I know I'm in a minority here, but I like mutable objects, and
this distinction between eq? and equal? is important.

For characters, the mutability argument fails: I don't think
characters, even multi-byte characters, should be mutable.
Thus, they should be eq?.

Just my 2 cents,

John

On 5/4/2013 12:06 PM, Robby Findler wrote:
> 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
> <mailto: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
>     <mailto: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
>     <mailto: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 <mailto: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
>      >>
>      >>
>
>
>
>
> _________________________
>    Racket Developers list:
>    http://lists.racket-lang.org/dev
>