Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcnc!unc!rentsch
From: rentsch@unc.cs.unc.edu (Tim Rentsch)
Newsgroups: comp.lang.smalltalk
Subject: Re: literals
Message-ID: <740@unc.cs.unc.edu>
Date: Fri, 3-Jul-87 17:21:55 EDT
Article-I.D.: unc.740
Posted: Fri Jul  3 17:21:55 1987
Date-Received: Sat, 4-Jul-87 14:24:12 EDT
References: <938@argus.UUCP>
Reply-To: rentsch@unc.UUCP (Tim Rentsch)
Organization: University of North Carolina, Chapel Hill
Lines: 51
Keywords: literals methods

In article <938@argus.UUCP> bmc@argus.UUCP (Bob Czech) writes:
> I've been working on a variation of the smalltalk model and in
> studying the VM I've found that if you have a string constant in a
> method and assign it to an instance variable and somewhere down the
> line you make a modification to that string, that the constant in the
> method would hence change.  Is this correct?  And if so, I see it as
> a major flaw that you would be able to modify a constant!  

That is correct, even though somewhat surprising when first
encountered.  The easiest way to correct the undesired behavior is
to use
			iv  <-  'foo' copy.
rather than
			iv  <-  'foo'.
to do the assignment.


This feature may indeed be a flaw from the programming language
design point of view, but it is not wrong from the programming
language definition point of view.  The token between single
quotes is a string *literal*, not a string *constant*.  The
distinction is shown clearly as far back as System/360 assembly
language, as consider the code fragment

	LA	1,5                put the number 5 in register 1
	ST	1,=F'123456'       store the result over the literal
	L	2,=F'123456'       load the value in the literal cell
	...

Pretty obviously this code will result in the value 5 ending up
in register 2.  (No argument about whether this is good or bad
coding style, the programmer obviously should be shot.)

As long as you remember that objects are actually out there for
literals, this all makes perfect sense, and applies to other literals
such as Symbols and Arrays.  

All of the problems mentioned so far are basically with at:put:,
either on the literal itself or its contained objects in the case of
Arrays.  But this is not the only problem -- use of become: on a
literal will also proceed as usual, and almost certainly wreak havoc
of some sort, if not on the program then on the sanity of the person
working on the code.

My conclusion:  not an altogether satisfactory mechanism, literals
are still very useful, and I can't immediately suggest anything
better.  Any ideas?

cheers,

Tim