working with Squeak 2.7 we discovered the following situation
#squeak = 'squeak' false 'squeak' = #squeak true
mathematics defines equivalence as a relation that is 1. reflexive 2. symmetric 3. transitive
Well, the above just ain't symmetric.
The problem arises because Strings and Symbols are the same species of collection. This satisfies the definition of equivalence that String inherits, whilst Symbol redefines equivalence to be identity.
My assertion is that in Smalltalk a String should never be equivalent to a Symbol. (Too much code depends upon Symbol identity being the same as equivalence.)
Given that, what is the correct course of action... 1. Make Strings and Symbols different species. 2. Redefine #= in String to ensure that a string and a symbol never are declared equivalent
[ | ] John Sarkela CTO The Fourth Estate, Inc.
On Wed, 5 Apr 2000, John W. Sarkela wrote:
working with Squeak 2.7 we discovered the following situation
#squeak = 'squeak' false 'squeak' = #squeak true
mathematics defines equivalence as a relation that is 1. reflexive 2. symmetric 3. transitive
Well, the above just ain't symmetric.
Thanks because, in this situation #= doesn't represent equivalence!
In keeping with the proposals to Pythonize Squeak's syntax, #= has been redefined to denote "sorta not assignment", and, as everyone knows Symbols are very picky about their assignments (they have to watch their image after all), where as a String will give enough of itself to hang you!
No, I'm just kidding. Fixing this seems like a good idea, but I worry a touch about breakage of stuff which "accidentally" depends on this behvaior. I'm not speaking entirely hypothetically, as I seem to recall difficulty with nil, 'nil', and #nil in some package I was porting (alas, I can't recal the details).
Have you mad eyour proposed change? Did anything obvious break?
Cheers, Bijan Parsia.
Haven't made the change yet. Up to my own devices, I would ensure that a string and a symbol are never equivalent. This would be consistent with VisualWorks and VSE. I can't easily check other dialects at this moment, but I suspect that most others follow the fold.
I would be quite surprised if any code "depended" upon asymmetric behavior of equivalence. That leaves code that depends upon strings and symbols occasionally being equivalent... let's just say I wouldn't want code like that deployed in any mission critical applications...
Conclusion: a string and a symbol should never be equivalent Proposed Solution: redefine #= in String to exclude equivalence with Symbols.
anybody think I missed the boat here?
John S [ | ] knight of the curly brace face ;-}>
From: Bijan Parsia bparsia@email.unc.edu Reply-To: squeak@cs.uiuc.edu Date: Wed, 5 Apr 2000 17:53:28 -0400 (EDT) To: squeak squeak@cs.uiuc.edu Subject: Re: [BUG] equivalence between strings and symbols Resent-From: squeak@cs.uiuc.edu Resent-Date: 5 Apr 2000 21:54:16 -0000
On Wed, 5 Apr 2000, John W. Sarkela wrote:
working with Squeak 2.7 we discovered the following situation
#squeak = 'squeak' false 'squeak' = #squeak true
mathematics defines equivalence as a relation that is
- reflexive
- symmetric
- transitive
Well, the above just ain't symmetric.
Thanks because, in this situation #= doesn't represent equivalence!
In keeping with the proposals to Pythonize Squeak's syntax, #= has been redefined to denote "sorta not assignment", and, as everyone knows Symbols are very picky about their assignments (they have to watch their image after all), where as a String will give enough of itself to hang you!
No, I'm just kidding. Fixing this seems like a good idea, but I worry a touch about breakage of stuff which "accidentally" depends on this behvaior. I'm not speaking entirely hypothetically, as I seem to recall difficulty with nil, 'nil', and #nil in some package I was porting (alas, I can't recal the details).
Have you mad eyour proposed change? Did anything obvious break?
Cheers, Bijan Parsia.
John W. Sarkela wrote:
Haven't made the change yet. Up to my own devices, I would ensure that a string and a symbol are never equivalent.
Am I the only one being confused by this terminology? I would call #= equality, and save equivalence for #==. Even though the ordinary name for #== is identity, other languages such as Prolog call this equivalence, vs equality for #=.
My two cents are that a string and a symbol should be able to be equal, if not equivalent, because in my view equality/#= typically concerns contents, not identity. I'm almost sure there are other cases where elements of different classes (with a common ancestor) answer true for the #= test. Anyway, this often makes good sense.
Still, I find it very interesting that the asymmetry arises from one class overriding the other's equality definition. That almost has a philosophical dimension to it.
We found other 'strange' behavior with strings and symbols... for example: #squeak printString -> 'squeak'
This is sometimes confusing (especially for some of the stuff that we are doing). It is also different than in some other Smalltalks. I think that it should be:
#squeak printString -> '#squeak'
Well, here I think String>>printString should quote its results too, for consistency, no? Note that printString gives you the contents, which makes the former correct, although I agree that this may be confusing. Otherwise, storeString will do what you need IIRC.
Henrik
squeak-dev@lists.squeakfoundation.org
-
Bijan Parsia -
Henrik Gedenryd -
John W. Sarkela