Identity vs equality (was Re: [Newbies] Assignment)

Thanks for the answer.


But I'm confused do you imply that the order in which the elements  
were added had an impact on the set?

in VisualWorks

| s1 s2 |

s1 := Set new.
s1 add: #foo.
s1 add: 'foo'.
s1 size
2

s2 := Set new.
s2 add: 'foo'.
s2 add: #foo.
s2 size
2

So I have problem to understand what was the real problem: is Squeak  
set badly implemented?
Is VisualWorks that wrong? I think that these behavior are core and  
this is strnage that there is
a so big difference between two smalltalks

>
>> I do not understand why #'hello' as a symbol should be = to 'hello'.
>
> Because 'hello' is equal to #'hello' as a symbol.

I'm sorry to look that terribly stupid but a string is not equal to a  
symbol. At least in VisualWorks this is clear

'Hello' = #'Hello'
        false

#'Hello' = 'Hello'
        false


>
>> It would have been good that such an important change would have  
>> been discussed on the mailing-list.
>
> It has. Before your time.

I started to play with squeak before 2000 (around 1998). But  
certainly not following everything. I guess that I started on 2.3c  
which was crashing
on solaris.

> The original version of the method has a stamp saying "di  
> 4/11/2000". And if you look at the archives of Squeak-dev in the  
> second half of 2000 I'm sure you'll find the discussion.

I will because I do not understand why a string is equal to a symbol.  
To me this is not because we use inheritance and that object have a  
similar (but not quite the same interface) that they are equal at  
least in VW and Lisp symbols and strings are not equal.
>
> Cheers,
>   - Andreas
>
>

I browsed the archive from June to November looking for set, string  
and symbol. If someone has a better
search engine I would be interested reading this thread.


>
> It has. Before your time. The original version of the method has a  
> stamp saying "di 4/11/2000". And if you look at the archives of  
> Squeak-dev in the second half of 2000 I'm sure you'll find the  
> discussion.

stephane ducasse wrote:
> I browsed the archive from June to November looking for set, string
> and symbol. If someone has a better
> search engine I would be interested reading this thread.
>
The email I sent back in August of 2000, containing 7 changesets that
fixed this issue, is not in the archives anymore.

Thanks,
Andres.

stephane ducasse wrote:
> But I'm confused do you imply that the order in which the elements were
> added had an impact on the set?

Yes.

>
> in VisualWorks
>

Well, but in VisualWorks also:

String>>= aString
        "Answer whether the argument is a string, and is not a symbol,
        and the receiver's size is the same as aString's size, and each of the
receiver's
        elements equal the corresponding element of aString"

        | size |
        aString isString ifFalse: [^false].
        aString isSymbol ifTrue: [^false].
        (size := self size) = aString size ifFalse: [^false].
        1 to: size do:[:index | (self at: index) = (aString at: index) ifFalse:
[^false]].
        ^true

So in other words, in VisualWorks Strings and Symbols always compare
false which is perfectly symmetric.

Cheers,
   - Andreas

2007/8/12, Andreas Raab <[hidden email]>:
Just happens to be opposite of Squeak. Ah the joys of portable
Smalltalk code. BTW GST does it the same way as VW.

Cheers
Philippe

On Sun, 12 Aug 2007 12:21:16 -0700, Andres Valloud
<[hidden email]> wrote:

> The email I sent back in August of 2000, containing 7 changesets that
> fixed this issue, is not in the archives anymore.

I've got the whole thing archived, including the attachments...

Later,
Jon

--------------------------------------------------------------
   Jon Hylands      [hidden email]      http://www.huv.com/jon

  Project: Micro Raptor (Small Biped Velociraptor Robot)
           http://www.huv.com/blog

Surely the question is one of value versus identity. Which leads to the
question, what 'value' does #hello represent. To me the fact that it is
a symbol is an implementation detail encapsulated inside the
implementation. Its external behaviour is that of a string literal (i.e.
immutable) as is its value.

I see this as analogous with numbers. Is 1 = 1.0 and 1.0 = 1. I should
hope so. 1.0 is implemented according to the float internal
representation, and 1, is implemented as a literal.

Keith

On Sun, 12 Aug 2007 11:48:16 -0700, stephane ducasse  
<[hidden email]> wrote:

> I browsed the archive from June to November looking for set, string
> and symbol. If someone has a better
> search engine I would be interested reading this thread.
>

I found it using "site:" with Google.

You can see a bit of it on:  
http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-September/


Look for:

String/Symbol equality

Keith Hodges wrote:
> Surely the question is one of value versus identity. Which leads to the
> question, what 'value' does #hello represent. To me the fact that it is
> a symbol is an implementation detail encapsulated inside the
> implementation. Its external behaviour is that of a string literal (i.e.
> immutable) as is its value.
>
> I see this as analogous with numbers. Is 1 = 1.0 and 1.0 = 1. I should
> hope so. 1.0 is implemented according to the float internal
> representation, and 1, is implemented as a literal.

Thanks for the example. It's a very good analogy.

Cheers,
   - Andreas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Raab schrieb:
Is it? I think one could argue, that 1 is just an abbreviation of 1.0
and since N is a subset of R, 1.0 in N is "the same object" as 1.0 in R. No?
Further the values of 1kg and 1km are both numbers like strings and
symbols are sequences of characters, but I wouldn't say that 1kg=1km.
Nothing forbids literal strings to be immutable, like they are in
VisualWorks, but literal strings won't become Symbols just because of that.

Alex
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGwBjxYiF2wSTEZ9gRAn6wAJ9zbi9vfcPRzpANPP4rMk/8i7EbaQCfRIC1
aUkXq5s82zceZqDz0c8/JwY=
=C/nO
-----END PGP SIGNATURE-----

Alexander Lazarević wrote:
Sure.

> Further the values of 1kg and 1km are both numbers like strings and
> symbols are sequences of characters, but I wouldn't say that 1kg=1km.

Sure.

> Nothing forbids literal strings to be immutable, like they are in
> VisualWorks, but literal strings won't become Symbols just because of that.

Err ... so what is your point? Are you claiming that 1 should not equal
1.0? Or that there is a substantial difference between 'foo' and #foo
and that they shouldn't compare equal? Or that 'foo' = #foo but #foo ~=
'foo'? Somewhere you lost me with whatever point you were trying to make.

*My* only point was that comparison should be symmetrical, as
excemplified by the fact that iff 1 = 1.0 then 1.0 = 1. If you disagree
with that please explain why there should be a difference in comparing
either way.

Confused,
   - Andreas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Err ... so what is your point? Are you claiming that 1 should not equal
> 1.0?

? No.

> Or that there is a substantial difference between 'foo' and #foo
> and that they shouldn't compare equal?

Yes.

> Or that 'foo' = #foo but #foo ~= 'foo'?

No.

> *My* only point was that comparison should be symmetrical, as
> excemplified by the fact that iff 1 = 1.0 then 1.0 = 1.

Ah ... crossreading the thread I lost the symmetry aspect. Sorry for the
confusion.


Alex
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGwCliYiF2wSTEZ9gRAntxAKCLoQrj6rcQ45JgJH8TknMT7EwNagCgzMNz
i0FM4fPnAwSHa9dsAJTtmuo=
=NBj0
-----END PGP SIGNATURE-----

Alexander Lazarević a écrit :
I Just want to add that Float are rather a subset of Q rather than R.
They are only fractions with denominator being a power of two.

And yes, we all expect = to behave symmetrically, whatever our
mathematical background, though it strictly does not have to.

This is one of my pets, and i'm glad to remind everybody that once
symmetry is cured, = is still not an equivalence relationship, because
transitivity is often broken.

a := 2 raisedTo: 80.
b := a asDouble.
c := a+1.
self should: [(a = b) & (b = c) ==> (a = c)].

Andres Valloud argued that Float should never equal Integer because they
are inexact.

I found this a little extremist because 1.0 is still exact. I proposed
instead to answer true only if conversion is exact.

The problem with IEEE is that inexact flag is not bound to the float
itself but somewhere in a processor register... So we forget this
information as soon as we store the result. Anyway, most Float will be
inexact. So both acceptions are acceptable.

Scheme authorizes the above two implementations.
In Squeak, we have all the elements for making a decision,
implementation are ready in mantis, the thread have been over-discussed,
we just need an authority to choose, or vote if some prefer democracy.
Instead of that, we take no decision at all... Sure, the bug is minor,
but it's always better to avoid bugs in foundations.

By the way, not only Float are broken, try:

a := (3 to: 2).
b := #().
c := (2 to: 1).
self should: [(a = b) & (b = c) ==> (a = c)].

This also is on mantis...

And don't play with set with these beasts, when they equal, their hash
rarely do so (has a solution in mantis too).

Nicolas

I agree that the symmetry in the solution is a must else we would  
have really strange behavior (like the ones you mentioned).
I was wondering what is the advantage to have strings and symbols  
been equals. I still do not understand deeply the pros and the
cons of each approach. This is true that we could consider that a  
symbol is a special string (unique) but I wonder what are the in
terface incompatibility. My question is if today I would have to  
design a library would I make the difference or not. And I'm puzzled.

Stef


On 12 août 07, at 21:21, Andreas Raab wrote:

> stephane ducasse wrote:
>> But I'm confused do you imply that the order in which the elements  
>> were added had an impact on the set?
>
> Yes.

I agree indeed it is quite important.

On 13 août 07, at 03:20, Keith Hodges wrote:

> Surely the question is one of value versus identity. Which leads to  
> the question, what 'value' does #hello represent. To me the fact  
> that it is a symbol is an implementation detail encapsulated inside  
> the implementation. Its external behaviour is that of a string  
> literal (i.e. immutable) as is its value.

I would love to be so sure in fact. I wonder (no time to browse now  
just packing fast to move) what are the real interfaces and their  
difference
between symbols and strings, because we do not use them in similar  
contexts.

>
> I see this as analogous with numbers. Is 1 = 1.0 and 1.0 = 1. I  
> should hope so. 1.0 is implemented according to the float internal  
> representation, and 1, is implemented as a literal.
>
> Keith
>
>

tx

On 13 août 07, at 07:34, Blake wrote:

nicolas cellier a écrit :
>
> a := 2 raisedTo: 80.
> b := a asDouble.
> c := a+1.
> self should: [(a = b) & (b = c) ==> (a = c)].
>

Sorry, I'm mixing the dialects... Read:

a := 2 raisedTo: 80.
b := a asFloat.
c := a+1.
self should: [(a = b) & (b = c) ==> (a = c)].

Nicoals

Andreas, as you can see even symmetry is not yet there...
As soon as a bug is fixed, one other makes surface, try:

        'A' asText = 'A'. "true"
        'A' = 'A' asText. "false"

Playing with = is something dangerous...

Nicolas

On 13/08/07, nicolas cellier <[hidden email]> wrote:
>
> Andreas, as you can see even symmetry is not yet there...
> As soon as a bug is fixed, one other makes surface, try:
>
>         'A' asText = 'A'.       "true"
>         'A' = 'A' asText.       "false"
>
yes, coercion makes the difference:

#symbol asString = 'symbol'  "true"
'symbol'  = #symbol asString "true"

#symbol = 'symbol'  asSymbol "true"

> Playing with = is something dangerous...
>
> Nicolas
>
>
>


--
Best regards,
Igor Stasenko AKA sig.

nicolas cellier wrote:
> This is one of my pets, and i'm glad to remind everybody that once
> symmetry is cured, = is still not an equivalence relationship, because
> transitivity is often broken.
>
> a := 2 raisedTo: 80.
> b := a asDouble.
> c := a+1.
> self should: [(a = b) & (b = c) ==> (a = c)].

Nice example. But in all fairness, transitivity isn't really broken in
the above because coercion is not a lossless operation. You are using
equality in a strictly mathematical sense and in this strict sense b and
c are not equal but only appear to be because of inexact coercion of c.

> In Squeak, we have all the elements for making a decision,
> implementation are ready in mantis, the thread have been over-discussed,
> we just need an authority to choose, or vote if some prefer democracy.

I don't remember the thread. Where is it?

Cheers,
   - Andreas