About String and Symbol equality
Hello people In Pharo (following Squeak tradition) a string is equals to its symbol representation. e.g. âtintinâ = #tintin > true In other Smalltalk dialects this is not the case. We have been working (sponsored by Lifeware) to support both semantics (yes this is a kind of daunting task and it can raise bugs). Our objective is to help people make business with Pharo. So âsimpleâ cross compatibility is something that we consider e.g. to deploy applications in Gemstone for example. (We would love to have a Pharo compiler working on Gemstone generating Gemstone VM bytecodes this is why we love the work of James Foster but this is another story). So since we are pragmatic people we could be convinced that the semantics of Pharo is not good :) and that by default we should use the semantics of GS or VW. The first step is to be able to choose which one to use within Pharo and be able to switch. We are nearly there for Pharo 13. The second step is to get a nice default. And we need the help of the community for this. Do you have any advice, arguments for and against any of the two choices that could be put on the table to influence our decisions for Pharo 14. So let us know :) Stef on the behalf of the Pharo consortium. Stéphane Ducasse http://stephane.ducasse.free.fr 06 30 93 66 73 "If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes
my 2c... There are arguments for and against any of the semantics decisions, so leaving those aside for greater minds... +1 GemStone Pharo and GemStone have long been an enviable workflow for âcomplex problems". They go together in a project, each providing a necessary part of the puzzle. Pharo and VW more often play in the same space, not exactly competitors, but typically the choice of one OR the other for any particular project. Disclaimer - as much as I love VW, I work with GemStone almost every day and can attest that every little divergence between Pharo and GemStone adds a non-trivial burden to the project and team. GS also considers Pharo as a âreferenceâ platform. You mentioned Jamesâ amazing work running a Pharo image on GemStone. They have adopted the Pharo FileSystem, and the latest version has a first-step implementation of traits. Some of the Smalltalk community projects lost to Pharo through traits will get a new lease on life! However, itâs fair to expect that having been in isolation for so long, there will be semantic âgotchasâ to find. Would be nice if they could be minimised as part of Pharos' semantic policy. The closer Pharo & GemStone work together, the easier it will be to achieve awesome end-to-end smalltalk projects, and by extension, make the world a better place :)
On 3 Feb 2025, at 4:35â¯AM, stephane ducasse <stephane.ducasse@inria.fr> wrote:
Hello people
In Pharo (following Squeak tradition) a string is equals to its symbol representation. e.g. âtintinâ = #tintin
true
In other Smalltalk dialects this is not the case.
We have been working (sponsored by Lifeware) to support both semantics (yes this is a kind of daunting task and it can raise bugs).
Our objective is to help people make business with Pharo. So âsimpleâ cross compatibility is something that we consider e.g. to deploy applications in Gemstone for example. (We would love to have a Pharo compiler working on Gemstone generating Gemstone VM bytecodes this is why we love the work of James Foster but this is another story).
So since we are pragmatic people we could be convinced that the semantics of Pharo is not good :) and that by default we should use the semantics of GS or VW.
The first step is to be able to choose which one to use within Pharo and be able to switch. We are nearly there for Pharo 13.
The second step is to get a nice default. And we need the help of the community for this.
Do you have any advice, arguments for and against any of the two choices that could be put on the table to influence our decisions for Pharo 14.
So let us know :)
Stef on the behalf of the Pharo consortium.
Stéphane Ducasse http://stephane.ducasse.free.fr 06 30 93 66 73
"If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes
How did Pharo diverge from the other Smalltalks? Was it a good decision? stephane ducasse wrote:
Hello people
In Pharo (following Squeak tradition) a string is equals to its symbol representation. e.g. âtintinâ = #tintin
true
In other Smalltalk dialects this is not the case.
We have been working (sponsored by Lifeware) to support both semantics (yes this is a kind of daunting task and it can raise bugs).
Our objective is to help people make business with Pharo. So âsimpleâ cross compatibility is something that we consider e.g. to deploy applications in Gemstone for example. (We would love to have a Pharo compiler working on Gemstone generating Gemstone VM bytecodes this is why we love the work of James Foster but this is another story).
So since we are pragmatic people we could be convinced that the semantics of Pharo is not good :) and that by default we should use the semantics of GS or VW.
The first step is to be able to choose which one to use within Pharo and be able to switch. We are nearly there for Pharo 13.
The second step is to get a nice default. And we need the help of the community for this.
Do you have any advice, arguments for and against any of the two choices that could be put on the table to influence our decisions for Pharo 14.
So let us know :)
Stef on the behalf of the Pharo consortium.
Stéphane Ducasse http://stephane.ducasse.free.fr 06 30 93 66 73
"If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes
Not that anyone else probably cares, but the ANSI standard says - for All objects x y, x = y if and only if y = x. The Smalltalk-80 mixup over String and Symbol violated this, âXâ = #x but #x ~= âxâ. - two sequences are = iff they are the same size, corresponding elements are =, AND they are instances of the same class. - String is not a special case. I note that this definition, which was a break with tradition, was agreed by all Smalltalk vendors and some famous industry representatives more than 25 years ago, which should have given people time to catch up. I do appreciate that the developers of Squeak had other maddened grizzly bears to stun, but given the confusion, anyone who used strings and symbols as elements of the same set or keys of the same dictionary was already in for a lot of pain when they tried to port their code. Any code badly affected by the proposed change was already broken (because symol equality is temporally stable and string equality isnât, among other things). Trying to support both the broken traditional and the corrected ANSI definition at the same times like a lot of effort. How would that work? On Mon, 3 Feb 2025 at 6:36â¯AM, stephane ducasse <stephane.ducasse@inria.fr> wrote:
Hello people
In Pharo (following Squeak tradition) a string is equals to its symbol representation. e.g. âtintinâ = #tintin
true
In other Smalltalk dialects this is not the case.
We have been working (sponsored by Lifeware) to support both semantics (yes this is a kind of daunting task and it can raise bugs).
Our objective is to help people make business with Pharo. So âsimpleâ cross compatibility is something that we consider e.g. to deploy applications in Gemstone for example. (We would love to have a Pharo compiler working on Gemstone generating Gemstone VM bytecodes this is why we love the work of James Foster but this is another story).
So since we are pragmatic people we could be convinced that the semantics of Pharo is not good :) and that by default we should use the semantics of GS or VW.
The first step is to be able to choose which one to use within Pharo and be able to switch. We are nearly there for Pharo 13.
The second step is to get a nice default. And we need the help of the community for this.
Do you have any advice, arguments for and against any of the two choices that could be put on the table to influence our decisions for Pharo 14.
So let us know :)
Stef on the behalf of the Pharo consortium.
Stéphane Ducasse http://stephane.ducasse.free.fr 06 30 93 66 73
"If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes
On 3 Feb 2025, at 06:33, Richard O'Keefe <raoknz@gmail.com> wrote:
Not that anyone else probably cares, but the ANSI standard says - for All objects x y, x = y if and only if y = x. The Smalltalk-80 mixup over String and Symbol violated this, âXâ = #x but #x ~= âxâ. - two sequences are = iff they are the same size, corresponding elements are =, AND they are instances of the same class.
That seems to be a very limited view of equality (that the class has to be the same for all definitions of equality). To me that means it models more the technical detail of Implementation, not the Domain.
- String is not a special case.
But String *is* a special case: 'hello' asWideString = 'hello' "true" 'hello' asWideString class = 'hello' class "false" Marcus
No, String is NOT a special case in the ANSI standard, which is what I was specifically writing about. WideString is not in the standard, thank goodness (although at the time the standard was made, it was already clear that at least 16-bit characters were needed). The ANSI rule perfectly fits the semantics of all the ANSI classes and it only applies to sequences defined in the standard, as I thought was clear. It doesnât apply to numbers, for example. Other than the coherence requirements, there are no constraints on non-standard classes. The rule I quoted about âsame classâ can of course be overridden for specific cases, but in the ANSI stansrd there is no overriding that would justify âxâ = #x. Really, strings of 21-bit codes are the ârealâ strings and other kinds of string are just storage optimisations. It is much simpler if there is one sort of string. For what itâs worth, in my Smalltalk implementation Symbol is not a subclass of String. That way I donât have to worry about what Symbol>>at:put: does. (They do have a common abstract superclass.) On Tue, 4 Feb 2025 at 10:36â¯PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 3 Feb 2025, at 06:33, Richard O'Keefe <raoknz@gmail.com> wrote:
Not that anyone else probably cares, but the ANSI standard says - for All objects x y, x = y if and only if y = x. The Smalltalk-80 mixup over String and Symbol violated this, âXâ = #x but #x ~= âxâ. - two sequences are = iff they are the same size, corresponding elements are =, AND they are instances of the same class.
That seems to be a very limited view of equality (that the class has to be the same for all definitions of equality).
To me that means it models more the technical detail of Implementation, not the Domain.
- String is not a special case.
But String *is* a special case:
'hello' asWideString = 'hello' "true" 'hello' asWideString class = 'hello' class "false"
Marcus
participants (5)
-
Aik-Siong Koh -
Jupiter Jones -
Marcus Denker -
Richard O'Keefe -
stephane ducasse