The mutability argument does not hold in Racket. non eq? things can be mutated and affect each other using chaperones and impersonators.
On Sat, May 4, 2013 at 5:27 PM, John Gateley <rac...@jfoo.org> wrote: > 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 <zeppi...@gmail.com >> <mailto:zeppi...@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 <zeppi...@gmail.com >> <mailto: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 >> <mailto: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 <mailto: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 >> > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev _________________________ Racket Developers list: http://lists.racket-lang.org/dev
