> I have to take (minor) issue with your assertion that it would be
> a good thing if literals could not be modified.  This causes nearly
> as many problems as it solves, sadly.  Its one of those ideas
> that sounds so good (like making browsers auto-update when code
> changes are accepted elsewhere) that can turn around and bite you.

Can you give an example of the kind of problem that would occur from making
literals read-only (other than backward compatibility)?  I'm not
challenging, I just can't think of any.  Now that I know what I know about
literals, I won't ever intentionally modify a literal anyway, so it seems
that help from the system in enforcing this policy would be good.

Also, is there some deep Smalltalk principle here that is the explanation
for this policy of sharing literals in a method, or is it just to save
memory?  Every other high-level language that I've used -- TCL, Java (is
java high-level?), Perl, Python, Basic, O'Caml, ML, Prolog, Lisp, Matlab --
all create a new object in response to a string or array literal.  (Actually
ML and Python use immutable strings, so this whole problem isn't an issue
for those two, at least for strings.) Note that these languages are free to
not actually create a new object each time; they could use a copy-on-write
scheme to avoid unnecessary copying yet still give the semantics of unique
objects.  For instance.

|a b|
a := 'hello'.
b := 'hello'.

At this point, a and b could still be pointing to the same string object,
but I wouldn't have to know that, because when I ran

a at: 2 put: $i.

The system would ensure that a got its own copy of the string at this point.

Just curious,
Adam