[Pharo-project] String and Symbol comparison
I want to open this for discussion: In all Smalltalk dialects the following expressions evaluate to false: 'abc' = #abc --> false #abc = 'abc' --> false This means a String and a Symbol is never the same thing, even if they contain the same characters. In Squeak/Pharo this is different though (at least this is symmetrical, pre 3.9 this wasn't even symmetrical): 'abc' = #abc --> true #abc = 'abc' --> true Unfortunately this difference makes writing portable code that deals with symbols and strings a huge pain. And it is hard to test, debug and find those kind of problems. I wonder if it would be possible to change that behavior in Squeak to match the other Smalltalk implementations? I guess this would break some code, but at least this problem would then be gone forever. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
I should say that I always like the fact that
'abc' = #abc --> false #abc = 'abc' --> false
Because a symbol and a string are different to my eyes. But when there was the discussion a while back I understood that a symbol is a kind of string. Now how can we make progress on that point - evaluate the risks - write some tests for strings and symbols - give a try - but do that for pharo 1.1 :) stef On Nov 14, 2008, at 7:46 AM, Lukas Renggli wrote:
I want to open this for discussion:
In all Smalltalk dialects the following expressions evaluate to false:
'abc' = #abc --> false #abc = 'abc' --> false
This means a String and a Symbol is never the same thing, even if they contain the same characters. In Squeak/Pharo this is different though (at least this is symmetrical, pre 3.9 this wasn't even symmetrical):
'abc' = #abc --> true #abc = 'abc' --> true
Unfortunately this difference makes writing portable code that deals with symbols and strings a huge pain. And it is hard to test, debug and find those kind of problems.
I wonder if it would be possible to change that behavior in Squeak to match the other Smalltalk implementations? I guess this would break some code, but at least this problem would then be gone forever.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, Nov 14, 2008 at 8:57 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I should say that I always like the fact that
'abc' = #abc --> false #abc = 'abc' --> false
Because a symbol and a string are different to my eyes. But when there was the discussion a while back I understood that a symbol is a kind of string.
Now how can we make progress on that point - evaluate the risks - write some tests for strings and symbols - give a try - but do that for pharo 1.1 :)
Ok, I will file an issue so that we don't forget. Along the same lines is that strings implement the complete arithmetic protocol. In my opinion that should go away as well: it is a source of errors and portability issues. Furthermore it looks really unprofessional: '1' + '2' --> '3' (in Pharo/Squeak) I guess this is some eToy remnant. Lukas
stef
On Nov 14, 2008, at 7:46 AM, Lukas Renggli wrote:
I want to open this for discussion:
In all Smalltalk dialects the following expressions evaluate to false:
'abc' = #abc --> false #abc = 'abc' --> false
This means a String and a Symbol is never the same thing, even if they contain the same characters. In Squeak/Pharo this is different though (at least this is symmetrical, pre 3.9 this wasn't even symmetrical):
'abc' = #abc --> true #abc = 'abc' --> true
Unfortunately this difference makes writing portable code that deals with symbols and strings a huge pain. And it is hard to test, debug and find those kind of problems.
I wonder if it would be possible to change that behavior in Squeak to match the other Smalltalk implementations? I guess this would break some code, but at least this problem would then be gone forever.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Yeap! Stef On Nov 14, 2008, at 9:10 AM, Michael Roberts wrote:
+1 on removing arithmetic protocol
cheers, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I created: http://code.google.com/p/pharo/issues/detail?id=331 http://code.google.com/p/pharo/issues/detail?id=332 It would be useful to be able to tag issues for specific milestones. Lukas On Fri, Nov 14, 2008 at 9:05 AM, Lukas Renggli <renggli@gmail.com> wrote:
On Fri, Nov 14, 2008 at 8:57 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I should say that I always like the fact that
'abc' = #abc --> false #abc = 'abc' --> false
Because a symbol and a string are different to my eyes. But when there was the discussion a while back I understood that a symbol is a kind of string.
Now how can we make progress on that point - evaluate the risks - write some tests for strings and symbols - give a try - but do that for pharo 1.1 :)
Ok, I will file an issue so that we don't forget.
Along the same lines is that strings implement the complete arithmetic protocol. In my opinion that should go away as well: it is a source of errors and portability issues. Furthermore it looks really unprofessional:
'1' + '2' --> '3' (in Pharo/Squeak)
I guess this is some eToy remnant.
Lukas
stef
On Nov 14, 2008, at 7:46 AM, Lukas Renggli wrote:
I want to open this for discussion:
In all Smalltalk dialects the following expressions evaluate to false:
'abc' = #abc --> false #abc = 'abc' --> false
This means a String and a Symbol is never the same thing, even if they contain the same characters. In Squeak/Pharo this is different though (at least this is symmetrical, pre 3.9 this wasn't even symmetrical):
'abc' = #abc --> true #abc = 'abc' --> true
Unfortunately this difference makes writing portable code that deals with symbols and strings a huge pain. And it is hard to test, debug and find those kind of problems.
I wonder if it would be possible to change that behavior in Squeak to match the other Smalltalk implementations? I guess this would break some code, but at least this problem would then be gone forever.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
-- Lukas Renggli http://www.lukas-renggli.ch
yes! may be create a tag for m1.1 On Nov 14, 2008, at 9:13 AM, Lukas Renggli wrote:
I created:
http://code.google.com/p/pharo/issues/detail?id=331 http://code.google.com/p/pharo/issues/detail?id=332
It would be useful to be able to tag issues for specific milestones.
Lukas
On Fri, Nov 14, 2008 at 9:05 AM, Lukas Renggli <renggli@gmail.com> wrote:
On Fri, Nov 14, 2008 at 8:57 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I should say that I always like the fact that
'abc' = #abc --> false #abc = 'abc' --> false
Because a symbol and a string are different to my eyes. But when there was the discussion a while back I understood that a symbol is a kind of string.
Now how can we make progress on that point - evaluate the risks - write some tests for strings and symbols - give a try - but do that for pharo 1.1 :)
Ok, I will file an issue so that we don't forget.
Along the same lines is that strings implement the complete arithmetic protocol. In my opinion that should go away as well: it is a source of errors and portability issues. Furthermore it looks really unprofessional:
'1' + '2' --> '3' (in Pharo/Squeak)
I guess this is some eToy remnant.
Lukas
stef
On Nov 14, 2008, at 7:46 AM, Lukas Renggli wrote:
I want to open this for discussion:
In all Smalltalk dialects the following expressions evaluate to false:
'abc' = #abc --> false #abc = 'abc' --> false
This means a String and a Symbol is never the same thing, even if they contain the same characters. In Squeak/Pharo this is different though (at least this is symmetrical, pre 3.9 this wasn't even symmetrical):
'abc' = #abc --> true #abc = 'abc' --> true
Unfortunately this difference makes writing portable code that deals with symbols and strings a huge pain. And it is hard to test, debug and find those kind of problems.
I wonder if it would be possible to change that behavior in Squeak to match the other Smalltalk implementations? I guess this would break some code, but at least this problem would then be gone forever.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I traced all the senders of #= where either the receiver is a string and the argument is a symbol and vice versa. I run this for all tests (the number indicates the number of occurrences). ((IdentityDictionary new) add: (#inputUpTo:nestedOn:errorMessage:-
57); add: (#assertVersionInfo:matches:->8); add: (#testChanges->1); add: (#=->9); add: (#pragmaStatement->214); add: (#grabAddressWithRoute->11); add: (#update:->3); add: (#testDateAndTimes->156); add: (#numberOfCategoryOfElement:->876104); add: (#basicRemoveElement:->179302); add: (#actionSelector:->128); add: (#testEncodingName->1); add: (#testAccessing->1); add: (#grabAddresses->12); add: (#nameForVer:base:->2); add: (#testDayOfWeek->3); add: (#scanForPreviousVersion->10); add: (#assertDict:matchesInfo:->4); add: (#testWeekday->2); add: (#testLoadAndUnload->1); add: (#blockSelectCallName:->3561); add: (#grabGroupAddress->15); add: (#matchToken:->221); add: (#blockSelectModuleName:->5409); add: (#hasEqualElements:->17); add: (#testRevertOverrideMethod->1); add: (#visibleClasses->553); add: (#category:matches:->109854); add: (#borderColor:->256); add: (#testMethodsWithEnabledCallX->2); add: (#pragmaLiteral->3); add: (#directoryContentsFor:->111045); add: (#versionForName:in:->5); add: (#indexOf:startingAt:ifAbsent:->29695); add: (#testRemoveFromSystem- 1); add: (#fileOutCategory:on:moveSource:toFile:->18); add: (#testMonth->3); add: (#testNameOfMonth->2); add: (#''~=''->125513); add: (#includes:->524976); add: (#testCreation->1); add: (#methodsForSelectedProtocol->26); add: (#testPartiallyRevertOverrideMethod->1); add: (#denyAListHasSelection:- 4); add: (#grabBasicAddress->3); add: (#classify:under:suppressIfDefault:->71); add: (#filterFileNames:forVersionNamed:->411); add: (#remove:ifAbsent:- 5512); add: (#methodsForSelectedClass->2410); add: (#testMethodsWithDisabledCallX->1); add: (#classCommentString->45); add: (#scanFor:->31750); add: (#piece->126); add: (#testSetUp->2); yourself)
This gives a rough idea of what code needs to be reviewed and possibly adapted. Adrian On Nov 14, 2008, at 09:24 , Stéphane Ducasse wrote:
yes! may be create a tag for m1.1
On Nov 14, 2008, at 9:13 AM, Lukas Renggli wrote:
I created:
http://code.google.com/p/pharo/issues/detail?id=331 http://code.google.com/p/pharo/issues/detail?id=332
It would be useful to be able to tag issues for specific milestones.
Lukas
On Fri, Nov 14, 2008 at 9:05 AM, Lukas Renggli <renggli@gmail.com> wrote:
On Fri, Nov 14, 2008 at 8:57 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I should say that I always like the fact that
'abc' = #abc --> false #abc = 'abc' --> false
Because a symbol and a string are different to my eyes. But when there was the discussion a while back I understood that a symbol is a kind of string.
Now how can we make progress on that point - evaluate the risks - write some tests for strings and symbols - give a try - but do that for pharo 1.1 :)
Ok, I will file an issue so that we don't forget.
Along the same lines is that strings implement the complete arithmetic protocol. In my opinion that should go away as well: it is a source of errors and portability issues. Furthermore it looks really unprofessional:
'1' + '2' --> '3' (in Pharo/Squeak)
I guess this is some eToy remnant.
Lukas
stef
On Nov 14, 2008, at 7:46 AM, Lukas Renggli wrote:
I want to open this for discussion:
In all Smalltalk dialects the following expressions evaluate to false:
'abc' = #abc --> false #abc = 'abc' --> false
This means a String and a Symbol is never the same thing, even if they contain the same characters. In Squeak/Pharo this is different though (at least this is symmetrical, pre 3.9 this wasn't even symmetrical):
'abc' = #abc --> true #abc = 'abc' --> true
Unfortunately this difference makes writing portable code that deals with symbols and strings a huge pain. And it is hard to test, debug and find those kind of problems.
I wonder if it would be possible to change that behavior in Squeak to match the other Smalltalk implementations? I guess this would break some code, but at least this problem would then be gone forever.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
this number is striking may be there is optimization crying to be done. #numberOfCategoryOfElement:->876104 #directoryContentsFor:->111045 On Nov 14, 2008, at 9:56 AM, Adrian Lienhard wrote:
I traced all the senders of #= where either the receiver is a string and the argument is a symbol and vice versa. I run this for all tests (the number indicates the number of occurrences).
((IdentityDictionary new) add: (#inputUpTo:nestedOn:errorMessage:-
57); add: (#assertVersionInfo:matches:->8); add: (#testChanges->1); add: (#=->9); add: (#pragmaStatement->214); add: (#grabAddressWithRoute->11); add: (#update:->3); add: (#testDateAndTimes->156); add: (#numberOfCategoryOfElement:- 876104); add: (#basicRemoveElement:->179302); add: (#actionSelector:->128); add: (#testEncodingName->1); add: (#testAccessing->1); add: (#grabAddresses->12); add: (#nameForVer:base:->2); add: (#testDayOfWeek->3); add: (#scanForPreviousVersion->10); add: (#assertDict:matchesInfo:->4); add: (#testWeekday->2); add: (#testLoadAndUnload->1); add: (#blockSelectCallName:->3561); add: (#grabGroupAddress->15); add: (#matchToken:->221); add: (#blockSelectModuleName:->5409); add: (#hasEqualElements:->17); add: (#testRevertOverrideMethod->1); add: (#visibleClasses->553); add: (#category:matches:->109854); add: (#borderColor:->256); add: (#testMethodsWithEnabledCallX->2); add: (#pragmaLiteral->3); add: (#directoryContentsFor:->111045); add: (#versionForName:in:->5); add: (#indexOf:startingAt:ifAbsent:- 29695); add: (#testRemoveFromSystem->1); add: (#fileOutCategory:on:moveSource:toFile:->18); add: (#testMonth->3); add: (#testNameOfMonth->2); add: (#''~=''->125513); add: (#includes:- 524976); add: (#testCreation->1); add: (#methodsForSelectedProtocol- 26); add: (#testPartiallyRevertOverrideMethod->1); add: (#denyAListHasSelection:->4); add: (#grabBasicAddress->3); add: (#classify:under:suppressIfDefault:->71); add: (#filterFileNames:forVersionNamed:->411); add: (#remove:ifAbsent:- 5512); add: (#methodsForSelectedClass->2410); add: (#testMethodsWithDisabledCallX->1); add: (#classCommentString->45); add: (#scanFor:->31750); add: (#piece->126); add: (#testSetUp->2); yourself)
This gives a rough idea of what code needs to be reviewed and possibly adapted.
Adrian
On Nov 14, 2008, at 09:24 , Stéphane Ducasse wrote:
yes! may be create a tag for m1.1
On Nov 14, 2008, at 9:13 AM, Lukas Renggli wrote:
I created:
http://code.google.com/p/pharo/issues/detail?id=331 http://code.google.com/p/pharo/issues/detail?id=332
It would be useful to be able to tag issues for specific milestones.
Lukas
On Fri, Nov 14, 2008 at 9:05 AM, Lukas Renggli <renggli@gmail.com> wrote:
On Fri, Nov 14, 2008 at 8:57 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I should say that I always like the fact that
'abc' = #abc --> false #abc = 'abc' --> false
Because a symbol and a string are different to my eyes. But when there was the discussion a while back I understood that a symbol is a kind of string.
Now how can we make progress on that point - evaluate the risks - write some tests for strings and symbols - give a try - but do that for pharo 1.1 :)
Ok, I will file an issue so that we don't forget.
Along the same lines is that strings implement the complete arithmetic protocol. In my opinion that should go away as well: it is a source of errors and portability issues. Furthermore it looks really unprofessional:
'1' + '2' --> '3' (in Pharo/Squeak)
I guess this is some eToy remnant.
Lukas
stef
On Nov 14, 2008, at 7:46 AM, Lukas Renggli wrote:
I want to open this for discussion:
In all Smalltalk dialects the following expressions evaluate to false:
'abc' = #abc --> false #abc = 'abc' --> false
This means a String and a Symbol is never the same thing, even if they contain the same characters. In Squeak/Pharo this is different though (at least this is symmetrical, pre 3.9 this wasn't even symmetrical):
'abc' = #abc --> true #abc = 'abc' --> true
Unfortunately this difference makes writing portable code that deals with symbols and strings a huge pain. And it is hard to test, debug and find those kind of problems.
I wonder if it would be possible to change that behavior in Squeak to match the other Smalltalk implementations? I guess this would break some code, but at least this problem would then be gone forever.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
-- Lukas Renggli http://www.lukas-renggli.ch
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Adrian Lienhard -
Lukas Renggli -
Michael Roberts -
Stéphane Ducasse