'foo' = #foo -> true or false? 
Author Message
 'foo' = #foo -> true or false?

Squeak says a symbol can be equal to a string.
VW says a symbol is never equal to a string.

Seaside (currently porting it from Squeak to VW) heavily relies on Squeak's
behavior. To get things going, I taught VW to emulate Squeak's behavior, but I
don't feel very happy in an image where String>>= and Symbol>>= are overridden
:-).

Is one of both blatantly wrong? Is my override dangerous? I'd appreciate any
insights here...

--

GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B



Tue, 19 Oct 2004 16:21:28 GMT  
 'foo' = #foo -> true or false?

Quote:
> Squeak says a symbol can be equal to a string.
> VW says a symbol is never equal to a string.

I'd say VW is right and Squeak is wrong.
1. Equality should be commutative, that is (a=b) == (b=a)
2. Equality of symbols is defined as identity, that is,
   (a=b) == (a=b) if a is a Symbol

So it follows that a=b can't ever be true if b is a Symbol and a isn't.
That's how it should be implemented.

Cheers,
Hans-Martin



Tue, 19 Oct 2004 18:10:42 GMT  
 'foo' = #foo -> true or false?
On 3 May 2002 10:10:42 GMT, Hans-Martin Mosner

Quote:


>> Squeak says a symbol can be equal to a string.
>> VW says a symbol is never equal to a string.

>I'd say VW is right and Squeak is wrong.
>1. Equality should be commutative, that is (a=b) == (b=a)
>2. Equality of symbols is defined as identity, that is,
>   (a=b) == (a=b) if a is a Symbol

>So it follows that a=b can't ever be true if b is a Symbol and a isn't.
>That's how it should be implemented.

Should 1 = 1.0?

Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.



Tue, 19 Oct 2004 19:22:33 GMT  
 'foo' = #foo -> true or false?

Quote:

> On 3 May 2002 10:10:42 GMT, Hans-Martin Mosner


> >> Squeak says a symbol can be equal to a string.
> >> VW says a symbol is never equal to a string.

> >I'd say VW is right and Squeak is wrong.
> >1. Equality should be commutative, that is (a=b) == (b=a)
> >2. Equality of symbols is defined as identity, that is,
> >   (a=b) == (a=b) if a is a Symbol

> >So it follows that a=b can't ever be true if b is a Symbol and a isn't.
> >That's how it should be implemented.

> Should 1 = 1.0?

I was talking about Symbols specifically. Numbers are a different kind
of animal.
Of course 1 = 1.0, and 1 = (5/5), and 1 = (Complex real: 1 imag: 0).
The problem with symbols is that they are subclassed from String, and
the argumentation for different number subclasses intutively applies to
different string subclasses (as far as those subclasses are different
representations, such as ByteString and TwoByteString). Symbols are
something completely different, and in my optiion it's purely an
implementation artefact that they are subclasses of String.

Cheers,
Hans-Martin



Tue, 19 Oct 2004 20:28:24 GMT  
 'foo' = #foo -> true or false?
or perhaps 'correspondsTo:'.  Can we equate apples and oranges?  apples
and pears?  apples and crab apples?

An interesting question is when does polymorphism stop being helpful and
start adding to the reader's confusion?  when should we use a different
method name?

Perhaps it would help by asking the question "When would one want #foo =
'foo' to be false"; or: "under what circumstances is it permissible to
have #== return different results from #=".

Part of the answer may be in the question "does it do any harm to
existing code?"

In a similar situation, I feel that streams and strings should both be
able to respond to the #, (comma) method, and that I should be able
concatenate a string's characters to a stream that way.  Some people are
uneasy about that, but I have yet to see where it proves a problem in
practice - and it is much clearer to read in a series than #nextPutAll:.
And coding gets even easier and less prone to error if I can also
concatenate characters that way.  Compare this code to the standard
practice:

        maryStream , ' had ', $a, ' little ', lambString

no more exceptions when you accidentally use nextPutAll: in lieu of
nextPut: (or vice versa).

Quote:

> Sounds like #sameAs: is more appropriate than '='.
> Just like ('abcd' = 'ABCD') is false and ('abcd' sameAs: 'ABCD') is true.
> It would make sense to say (#abcd sameAs: 'abcd') is true.



>>Squeak says a symbol can be equal to a string.
>>VW says a symbol is never equal to a string.

>>Seaside (currently porting it from Squeak to VW) heavily relies on

> Squeak's

>>behavior. To get things going, I taught VW to emulate Squeak's behavior,

> but I

>>don't feel very happy in an image where String>>= and Symbol>>= are

> overridden

>>:-).

>>Is one of both blatantly wrong? Is my override dangerous? I'd appreciate

> any

>>insights here...

>>--

>>GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B



Tue, 19 Oct 2004 21:50:44 GMT  
 'foo' = #foo -> true or false?

Quote:

> Sounds like #sameAs: is more appropriate than '='.
> Just like ('abcd' = 'ABCD') is false and ('abcd' sameAs: 'ABCD') is true.
> It would make sense to say (#abcd sameAs: 'abcd') is true.

Which is, of course, exactly how it works in VisualWorks.

Chris
--



Tue, 19 Oct 2004 21:47:26 GMT  
 'foo' = #foo -> true or false?

Quote:

> On 3 May 2002 10:10:42 GMT, Hans-Martin Mosner


>>>Squeak says a symbol can be equal to a string.
>>>VW says a symbol is never equal to a string.

>>I'd say VW is right and Squeak is wrong.
>>1. Equality should be commutative, that is (a=b) == (b=a)
>>2. Equality of symbols is defined as identity, that is,
>>  (a=b) == (a=b) if a is a Symbol

>>So it follows that a=b can't ever be true if b is a Symbol and a isn't.
>>That's how it should be implemented.

> Should 1 = 1.0?

Well, yes. But only because 1.0 = 1 also. I'm not sure I see the point
you were/are trying to make Ron?

I agree with Hans. VW is more correct.

There are a couple of keyword alternatives which are commutive in both
directions:

match:
sameAs:
compare:

I would bet that using match: and sameAs: as is, is probably not what
Cees wants, since they are case insensitive, but maybe.

match: dispatches to match:ignoreCase: with true as the paramter, so one
can use the variant to include case sensitivity. compare: is case
sensitive. sameAs: cannot be.

If we look up the collection heirarchy and abstract the question, we
find isSameSequenceAs:. This is effectively strcmp (a case sensitive
compare) and it too is comutative between a symbol and string. Heck, you
could use this guy to compares strings against symbols against arrays of
characters.

If speed is of interest, match:ignoreCase: and isSameSequenceAs: are
hands down much faster than the others, for the case sensitive route.
sameAs: is slightly faster than match: in the insensitive realm.

Funky--you can even do wildcards inside of symbols with match:

#'Y*s' match: 'yes' --> true

--
Travis Griggs
Key Technology
10 2 letter words: "If it is to be it is up to me"



Tue, 19 Oct 2004 23:44:21 GMT  
 'foo' = #foo -> true or false?
These comments compare VisualWorks 5i2 notion of equality for strings
with Smalltalk-80's notion, and then digress on equality in general. I
happen to have 5i2 at hand. Contradictions emerge as soon as you peel
back the covers. VW has changed the ST80 semantics and introduced new
paradoxes.

Smalltalk-80 used to have non-commutative equality for strings and
symbols, although I can't find it in the Blue Book. In the late 80s or
early 90s I (and perhaps others) persuaded ParcPlace Systems to make
it commutative, with similar motivations to that of Hans below.

I think around the same time frame PPS changed the behavior at the
SequenceableCollection level to require that the two collections be of
the same species. But they overrode #= for String, dropping the
species requirement and adding a non-symbol requirement. Consider this
behavior:

comparison                               VW5i2  ST80

1  'a' = #a                              false  true
1  #a  = 'a'                             false  false

2  OrderedCollection new = Array new     false  true--I think
2  Array new = OrderedCollection new     false  true--I think

3  ISO8859L1String new = MacString new   true   n/a
3  MacString new = ISO8859L1String new   true   n/a

Aren't VW5i2's results for 2 and 3 are inconsistent? Why should
OrderedCollection and Array not compare, but the two strings compare?

Some method comments are incorrect, such as for By{*filter*}codedString #=.
The comment should be correct, because the method uses a VM primitive.

Consider the following equality examples from 5i2. The first violates
commutativity. The second violates intuition. If two objects are the
same, shouldn't they be equal? A mathematician must have written this.
A physicist would not have generated a walkbalk. The third seems
inconsistent. As long as Smalltalk lets you create empty instances of
abstract classes, shouldn't two instances be equal? They are for
String but not for Object.

1  Magnitude new = nil                      walkback
1  nil = Magnitude new                      false

2  Infinity positive == Infinity positive   true
2  Infinity positive = Infinity positive    walkback

3  Object new = Object new                  false
3  String new = String new                  true

VisualWorks has changed other Smalltalk-80 equality behavior. For
example, Associations used to only compare their key because the
inventors thought they would only be used in Dictionaries. When
developers found other uses, the PPS engineers were persuaded to also
compare the values.

                      VW5i2  ST80

(1 -> 1) = (1 -> 2)  false  true

In many mathematical systems, commutativity of equality and of certain
operations is assumed to be true. It comes much less naturally to a
language with Smalltalk's syntax of <receiver message>. I wonder
whether it would be more natural, or would be easier to enforce, for a
language that dispatches on the receiver and the argument(s).

Equality is complex both in semantics and implementation when you
study it. I wouldn't be surprised for philosophers to have written
books on it. The complexities of copying closely parallel those of
comparing.

Quote:


>>Squeak says a symbol can be equal to a string.
>>VW says a symbol is never equal to a string.

> I'd say VW is right and Squeak is wrong.
> 1. Equality should be commutative, that is (a=b) == (b=a)
> 2. Equality of symbols is defined as identity, that is,
>    (a=b) == (a=b) if a is a Symbol

> So it follows that a=b can't ever be true if b is a Symbol and a isn't.
> That's how it should be implemented.

> Cheers,
> Hans-Martin



Wed, 20 Oct 2004 09:32:52 GMT  
 'foo' = #foo -> true or false?

Quote:
> Equality is complex both in semantics and implementation when you
> study it. I wouldn't be surprised for philosophers to have written
> books on it. The complexities of copying closely parallel those of
> comparing.

And so what's left to the poor implementors but picking something simple
that makes sense?  A comparison that is not commutative, like in ST-80
clearly doesn't.  I also find in comforting to think that #foo is equal
only to #foo and nothing else.  As for Array new = OrderedCollection new, I
don't recall a single case when I would care.  Let philosophers write their
books.  Ditto for copying, and cheers to the inventor of #postCopy.

--

VisualWorks Engineering
[:s | s, s printString] value: '[:s | s, s printString] value: '



Wed, 20 Oct 2004 16:38:57 GMT  
 'foo' = #foo -> true or false?

Quote:
>And coding gets even easier and less prone to error if I can also
>concatenate characters that way.  Compare this code to the standard
>practice:

>    maryStream , ' had ', $a, ' little ', lambString

Or maybe, dare I suggest it:

        maryStream << ' had ' << $a << ' little ' << lambString

(I find the first comma a bit counter-intuitive)

--

GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B



Wed, 20 Oct 2004 16:15:23 GMT  
 'foo' = #foo -> true or false?
"Logically"
                 'foo' =  #foo  -> true
                 'foo' == #foo -> false

    Vlastik



Quote:
> Squeak says a symbol can be equal to a string.
> VW says a symbol is never equal to a string.

> Seaside (currently porting it from Squeak to VW) heavily relies on
Squeak's
> behavior. To get things going, I taught VW to emulate Squeak's behavior,
but I
> don't feel very happy in an image where String>>= and Symbol>>= are
overridden
> :-).

> Is one of both blatantly wrong? Is my override dangerous? I'd appreciate
any
> insights here...

> --

> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B



Fri, 22 Oct 2004 08:55:44 GMT  
 'foo' = #foo -> true or false?
If Numbers are different from Strings and Symbols from OO programming view,
then OO programming view is wrong.

   Vlastik



Quote:

> > On 3 May 2002 10:10:42 GMT, Hans-Martin Mosner


> > >> Squeak says a symbol can be equal to a string.
> > >> VW says a symbol is never equal to a string.

> > >I'd say VW is right and Squeak is wrong.
> > >1. Equality should be commutative, that is (a=b) == (b=a)
> > >2. Equality of symbols is defined as identity, that is,
> > >   (a=b) == (a=b) if a is a Symbol

> > >So it follows that a=b can't ever be true if b is a Symbol and a isn't.
> > >That's how it should be implemented.

> > Should 1 = 1.0?

> I was talking about Symbols specifically. Numbers are a different kind
> of animal.
> Of course 1 = 1.0, and 1 = (5/5), and 1 = (Complex real: 1 imag: 0).
> The problem with symbols is that they are subclassed from String, and
> the argumentation for different number subclasses intutively applies to
> different string subclasses (as far as those subclasses are different
> representations, such as ByteString and TwoByteString). Symbols are
> something completely different, and in my optiion it's purely an
> implementation artefact that they are subclasses of String.

> Cheers,
> Hans-Martin



Fri, 22 Oct 2004 08:58:59 GMT  
 'foo' = #foo -> true or false?
I think Ron made a point:

 = means, that a contents of the object is the same as the other one's.
== means, that an object IS the other object as well ( they occupy the same
slot in memory)

 Vlastik


Quote:

> > On 3 May 2002 10:10:42 GMT, Hans-Martin Mosner


> >>>Squeak says a symbol can be equal to a string.
> >>>VW says a symbol is never equal to a string.

> >>I'd say VW is right and Squeak is wrong.
> >>1. Equality should be commutative, that is (a=b) == (b=a)
> >>2. Equality of symbols is defined as identity, that is,
> >>  (a=b) == (a=b) if a is a Symbol

> >>So it follows that a=b can't ever be true if b is a Symbol and a isn't.
> >>That's how it should be implemented.

> > Should 1 = 1.0?

> Well, yes. But only because 1.0 = 1 also. I'm not sure I see the point
> you were/are trying to make Ron?

> I agree with Hans. VW is more correct.

> There are a couple of keyword alternatives which are commutive in both
> directions:

> match:
> sameAs:
> compare:

> I would bet that using match: and sameAs: as is, is probably not what
> Cees wants, since they are case insensitive, but maybe.

> match: dispatches to match:ignoreCase: with true as the paramter, so one
> can use the variant to include case sensitivity. compare: is case
> sensitive. sameAs: cannot be.

> If we look up the collection heirarchy and abstract the question, we
> find isSameSequenceAs:. This is effectively strcmp (a case sensitive
> compare) and it too is comutative between a symbol and string. Heck, you
> could use this guy to compares strings against symbols against arrays of
> characters.

> If speed is of interest, match:ignoreCase: and isSameSequenceAs: are
> hands down much faster than the others, for the case sensitive route.
> sameAs: is slightly faster than match: in the insensitive realm.

> Funky--you can even do wildcards inside of symbols with match:

> #'Y*s' match: 'yes' --> true

> --
> Travis Griggs
> Key Technology
> 10 2 letter words: "If it is to be it is up to me"



Fri, 22 Oct 2004 09:01:37 GMT  
 'foo' = #foo -> true or false?

Quote:

> = means, that a contents of the object is the same as the other one's.

The receiver can return true or false as it sees fit - memory compare,
double dispatch, recursive tree-walk, whatever.

Quote:
>== means, that an object IS the other object as well ( they occupy the same
> slot in memory)

That is my understanding how how #== is implemented.

My shallow understanding is that symbols are intern'd such that = will
always return the same results as == and is hence cheaper at run time
(at the expense of the intern).

When you see a #foo in source, you're looking at the literal that means
'the *sole* object whose symbol is #foo'.  That 'foo' = #foo is false
comes down to the *definition* of symbols (hence there is potential
difference between vendors).  It is not a broken view of OO in any
sense - IMHO.

ps. Is is #=,#== or =,==?  I don't usually see the symbol prefix
on these selectors ....

--



Fri, 22 Oct 2004 08:20:10 GMT  
 'foo' = #foo -> true or false?
Quote:

> If Numbers are different from Strings and Symbols from OO programming view,
> then OO programming view is wrong.

Huh? Care to explain the logic behind this argument?

Cheers,
Hans-Martin



Fri, 22 Oct 2004 15:37:02 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. is (member # :test 'foo) -> :test #'foo optimization allowed?

2. require '../foo/bar'

3. INCLUDE 'FOO.FOR/list'

4. A use for "foo = foo()"

5. if foo.__class__ == Foo: #in C?

6. foo.py vs. foo.pyc

7. Difference between $foo and [set foo]

8. eval $foo - does $foo get bytecompiled?

9. $foo == "" or [llength $foo] == 0

10. difference between ::foo::woof and foo::woof?

11. Date format from [file atime/mtime foo.foo]

12. %w(foo) v.s. ['foo']

 

 
Powered by phpBB® Forum Software