Roel Wuyts <Roel.Wuyts at ulb.ac.be> writes:
> 'foo' = 'foo' 			true		"ok"
> 'foo' == 'foo' 			true		"NOT OK"
> 
> The underlying reason is that whenever I execute one of these
> expressions in a workspace, a method is created behind my back and
> then executed. In the case of comparing two strings, the compiler
> creates *a single literal for both strings*. This is plain wrong: a
> string is a collection of characters, and therefore these are two
> different instances of this collection that happen to have the same
> contents.

Indeed it is good to get this straight.  The semantics you propose
makes me thing of cons in Scheme, where cons is guaranteed to give you
a fresh object every time it is executed.  Additionally, the result is
guaranteed to be mutable, so it's especially important that separate
calls to cons return separate objects!

The other viewpoint also seems to also make sense, though: literals
describe a *read-only* object, and thus the compiler may reuse them if
it likes.

FWIW, the ANSI standard supports read-only literals, but does not
require them to be.  It says that you get undefined behavior if you
try to modify an object created via a literal. See section 3.4.6.3,
"String literals".  We do not have to conform to ANSI, of course, but
other Smalltalks might consider it.


Also, FWIW, if you like the ANSI version, it is easy to implement.
Here is a version using a dead forked dialect of Squeak; it should be
easy to dust it off should anyone want.  This version goes further
than discussed in this thread, and even makes floats and large integers
be immutable.  :)  The code is in islands.zip on the following page;
look inside the zip for immutLits1.5.cs and immutLits2.2.cs.

  http://wiki.squeak.org/squeak/2074


If anyone is passionate about this issue, by all means open up a
Mantis entry!  Judging from the discussion so far, however, it may be
hard to come to a decision....

-Lex