SD
stephane ducasse
Sun, Feb 2, 2025 5:35 PM
Hello people
In Pharo (following Squeak tradition) a string is equals to its symbol representation.
e.g.
’tintin’ = #tintin
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
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
JJ
Jupiter Jones
Sun, Feb 2, 2025 7:41 PM
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
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
AK
Aik-Siong Koh
Mon, Feb 3, 2025 4:42 AM
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
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
>
>
>
>
>
RO
Richard O'Keefe
Mon, Feb 3, 2025 5:33 AM
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
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
>
>
>
>
>
>
MD
Marcus Denker
Tue, Feb 4, 2025 9:35 AM
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
> 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
RO
Richard O'Keefe
Tue, Feb 4, 2025 11:15 AM
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
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