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

On Sat, May 4, 2013 at 8:17 PM, John Gateley <racket at jfoo.org> wrote:

> From the docs:
>
> >>>
> 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.
> <<<
>
> This is what I was saying below: chaperoned or impersonated objects
> are equal? but not eq?. If two objects really are the same - defined
> as side-effecting one also side-effects the other - then they are
> eq? as well as equal?
>
>
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?.

Here's an example:

#lang racket
(define v1 (make-vector 10 0))
(define (do-nothing-interpose-proc v i o) o)
(define v2 (chaperone-vector v1 do-nothing-interpose-proc
do-nothing-interpose-proc))
(eq? v1 v2) ;; = #f
(vector-ref v1 2) ;; = 0
(vector-set! v2 2 11)
(vector-ref v1 2) ;; = 11




> Chars don't have accessors or mutators, so should be eq?.
>
>
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?.

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


> Again, just my 2cents. I'm not a racket expert (racketeer?)
>
>
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.

Robby


> John
>
>
>
> On 5/4/2013 7:50 PM, Eric Dobson wrote:
>
>> 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 <racket at 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 <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<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<http://lists.racket-lang.org/users/archive/2013-April/057510.html>
>>>>       >>> _________________________
>>>>       >>>  Racket Developers list:
>>>>       >>> http://lists.racket-lang.org/**dev<http://lists.racket-lang.org/dev>
>>>>       >>
>>>>       >>
>>>>
>>>>
>>>>
>>>>
>>>> _________________________
>>>>     Racket Developers list:
>>>>     http://lists.racket-lang.org/**dev<http://lists.racket-lang.org/dev>
>>>>
>>>>  _________________________
>>>   Racket Developers list:
>>>   http://lists.racket-lang.org/**dev <http://lists.racket-lang.org/dev>
>>>
>> _________________________
>  Racket Developers list:
>  http://lists.racket-lang.org/**dev <http://lists.racket-lang.org/dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130504/3d5ac776/attachment-0001.html>