<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 4, 2013 at 8:17 PM, John Gateley <span dir="ltr"><<a href="mailto:racket@jfoo.org" target="_blank">racket@jfoo.org</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">From the docs:<br> <br> >>><br> An impersonator is a wrapper for a value where the wrapper redirects some of the value’s operations. Impersonators apply only to procedures, structures for which an accessor or mutator is available, structure types, hash tables, vectors, boxes, and prompt tags. An impersonator is equal? to the original value, but not eq? to the original value.<br> <<<<br> <br> This is what I was saying below: chaperoned or impersonated objects<br> are equal? but not eq?. If two objects really are the same - defined<br> as side-effecting one also side-effects the other - then they are<br> eq? as well as equal?<br> <br></blockquote><div><br></div><div style>If you take this definition of "same" (mutating one mutates the other), then I think chaperoned values have to qualify, but they won't be eq?.</div><div style><br> </div><div style>Here's an example:</div><div style><div><br></div><div>#lang racket</div><div>(define v1 (make-vector 10 0))<br></div><div>(define (do-nothing-interpose-proc v i o) o)</div><div>(define v2 (chaperone-vector v1 do-nothing-interpose-proc do-nothing-interpose-proc))</div> <div>(eq? v1 v2) ;; = #f</div><div>(vector-ref v1 2) ;; = 0</div><div>(vector-set! v2 2 11)</div><div>(vector-ref v1 2) ;; = 11</div><div><br></div></div><div style><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> Chars don't have accessors or mutators, so should be eq?.<br> <br></blockquote><div><br></div><div style>But chars are not mutable so the rule "mutate one and change the other" doesn't apply. So they might be eq? or might not. Similarly with numbers. In the case of numbers with the current Racket, if you have an exact integer that is close enough to zero, then the same value (according to equal? (and 3rd grade math class)) will be eq?, but exact integers that are far enough from zero will be equal? without being eq?.</div> <div style><br></div><div style>Some characters have the equal? implies eq? property (the ASCII ones and maybe a few more, I'm not sure) and some don't (#\λ for example).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> Again, just my 2cents. I'm not a racket expert (racketeer?)<span class=""><font color="#888888"><br> <br></font></span></blockquote><div><br></div><div style>No worries! And being racketeer is more of a state of mind than any great expertise, IMO. Your name has come up in my hearing before and I, for one, would be delighted to consider you a racketeer.</div> <div style><br></div><div style>Robby</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><font color="#888888"> John</font></span><div class=""><div class="h5"><br> <br> <br> On 5/4/2013 7:50 PM, Eric Dobson wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> The mutability argument does not hold in Racket. non eq? things can be<br> mutated and affect each other using chaperones and impersonators.<br> <br> On Sat, May 4, 2013 at 5:27 PM, John Gateley <<a href="mailto:racket@jfoo.org" target="_blank">racket@jfoo.org</a>> wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> Personal opinion: performance is a dangerous motivator. Yes, it is<br> a necessity, but it is often abused as a reason to do something.<br> <br> There's a semantic difference between eq? and equal? from the point<br> of view of mutability. Two objects are eq? if modifying one also<br> modifies the other. They are equal? but not eq? if they are the<br> "same", but modifying one will not modify the other.<br> <br> I know I'm in a minority here, but I like mutable objects, and<br> this distinction between eq? and equal? is important.<br> <br> For characters, the mutability argument fails: I don't think<br> characters, even multi-byte characters, should be mutable.<br> Thus, they should be eq?.<br> <br> Just my 2 cents,<br> <br> John<br> <br> <br> On 5/4/2013 12:06 PM, Robby Findler wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br> Well, I'm not sure that I buy that motivation, since I think decisions<br> about what should be eq? to what should be driven by performance (and<br> eq? should only be used for performance) but lets put that aside.<br> <br> There are some unused bits in Racket's runtime representation of values,<br> namely when a value's bit representation ends in 10, we know that it<br> isn't a fixnum (since it doesn't end with 1) and that it isn't a pointer<br> (since pointers have end with 00 (at least)), so I think that means that<br> we could have all of the unicode code points represented in a way that<br> requires no allocation (currently, iiuc, the ASCII characters are just<br> pre-allocated at the runtime startup; they require no allocation because<br> you always just get the same pointer).<br> <br> This is a pretty big change, however, so I'm not sure it would be worth<br> it.<br> <br> Robby<br> <br> <br> <br> On Sat, May 4, 2013 at 11:56 AM, Jon Zeppieri <<a href="mailto:zeppieri@gmail.com" target="_blank">zeppieri@gmail.com</a><br> <mailto:<a href="mailto:zeppieri@gmail.com" target="_blank">zeppieri@gmail.com</a>>> wrote:<br> <br> Something about my response below has been bothering me, and I think<br> I know what it is: the correspondence between characters and the<br> fixnums that represent their code points seems -- how to put it? --<br> more complete if it extends to their equality predicates. So, yeah,<br> in addition to performance, there's an aesthetic motivation, too.<br> <br> On May 4, 2013, at 12:03 PM, Jon Zeppieri <<a href="mailto:zeppieri@gmail.com" target="_blank">zeppieri@gmail.com</a><br> <mailto:<a href="mailto:zeppieri@gmail.com" target="_blank">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" target="_blank">robby@eecs.northwestern.edu</a><br> <mailto:<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.<u></u>northwestern.edu</a>>> wrote:<br> >> I'm curious: why do you want all characters to be eq? to each<br> other instead<br> >> of just equal??<br> >><br> >> Robby<br> >><br> >><br> >> On Sat, May 4, 2013 at 10:57 AM, Jon Zeppieri<br> <<a href="mailto:zeppieri@gmail.com" target="_blank">zeppieri@gmail.com</a> <mailto:<a href="mailto:zeppieri@gmail.com" target="_blank">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<br> of<br> >>> removing eqv? all of its associated machinery (e.g., memv,<br> hasheqv,<br> >>> etc.)?<br> >>><br> >>> (Along with this change, it would be nice if characters could<br> all be<br> >>> immediately represented, so that those with equal code points<br> would be<br> >>> eq? RIght now, all unicode code points can be encoded in 22 bits,<br> I<br> >>> think. I'm not so familiar with racket's current representation<br> of<br> >>> characters, but I figure that they could easily be fit into a<br> single<br> >>> machine word on 64-bit builds. I don't know how difficult it<br> would be<br> >>> on 32-bit builds. And, of course, there's no guarantee that the<br> number<br> >>> of code points won't increase significantly.)<br> >>><br> >>> Alternatively (and following Sam's line of thought from [1]),<br> eqv?<br> >>> could be extended to cover all of racket's immutable data<br> structures.<br> >>> In this case eqv? should also be made generic so that<br> user-defined<br> >>> immutable data structures can use it, as well.<br> >>><br> >>><br> >>> [1]<br> <a href="http://lists.racket-lang.org/users/archive/2013-April/057510.html" target="_blank">http://lists.racket-lang.org/<u></u>users/archive/2013-April/<u></u>057510.html</a><br> >>> _________________________<br> >>> Racket Developers list:<br> >>> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/<u></u>dev</a><br> >><br> >><br> <br> <br> <br> <br> _________________________<br> Racket Developers list:<br> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/<u></u>dev</a><br> <br> </blockquote> _________________________<br> Racket Developers list:<br> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/<u></u>dev</a><br> </blockquote></blockquote> _________________________<br> Racket Developers list:<br> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/<u></u>dev</a><br> </div></div></blockquote></div><br></div></div>