Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcnc!unc!steele
From: steele@unc.cs.unc.edu (Oliver Steele)
Newsgroups: comp.lang.smalltalk
Subject: Re: literals
Message-ID: <805@unc.cs.unc.edu>
Date: Wed, 15-Jul-87 16:57:44 EDT
Article-I.D.: unc.805
Posted: Wed Jul 15 16:57:44 1987
Date-Received: Fri, 17-Jul-87 07:34:32 EDT
References: <938@argus.UUCP> <80500010@uiucdcsp>
Reply-To: steele@unc.UUCP (Oliver Steele)
Organization: University of North Carolina, Chapel Hill
Lines: 66

In article <80500010@uiucdcsp> johnson@uiucdcsp.cs.uiuc.edu writes:
>
>I claimed that it was a flaw in Smalltalk that "constant arrays" were not
>constants, and offered symbols as an example of a real constant.

I agree.  In an earlier article I tried to show that Smalltalk acted the
same as many other languages in this respect, but I think that this just
shows that many other languages are flawed too.

An example of why it is a flaw is that code such as

    squares

	| stream between |
	stream _ WriteStream on: ''.
	between _ '('.
	1 to: 10 do:
	    [:i |
		stream nextPutAll: between.
		i*i printOn: stream.
		between _ ', '.
		]
	stream nextPutAll: ')'.
	^stream contents

will only work correctly once, and that after it has been run once the
source no longer reflects the compiled method.  It's obvious to an
experienced Smalltalk programmer what is going on, but a run-time error
would preferrable to a subtle piece of self-modifying code.

>jan@tekchips says that if I want constants, I should make them by subclasses.
>That is exactly my complaint.  The flaw in Smalltalk is that I cannot.
>So-called constant arrays are by default of class Array, which is not
>constant.  They should instead be in class ConstantArray, which has no
>at:put: message.  It will probably have a basicAt:put: message, but that
>won't bother me.

This isn't the problem.  I just created ConstantString and ConstantArray,
which work as you would expect, and added conversion messages to go
between Constant<x> and <x>.  Then I changed Scanner|xStringLit and
Scanner|scanVector (I've got the names wrong, but the're pretty easy to
find) to return their contents asConstantString and asConstantArray, and
everything worked fine, up to a point.  Two points.

The point was that some Smalltalk code on my system (MacPlus with version
0.3) assumed that it would be able to modify strings passed to it.
Evaluating strings such as
			FileStream fileNamed: 'foo'
would give an error when a message tried to modify 'foo'.  This is just
sloppy programming, and could probably be eliminated without too much
trouble (if it's even present in other systems).

The other point is that code that does
		fee _ #(fi fo fum) copy.
will expect fee to be mutable.  I suspect I would have run into this if I
had recompiled much of the system after changing Scanner.  The only
workaround I can see is to let Constant<x>|copy be the same as
Constant<x>|as<x>, but this is very misleading and changes the semantics
of copy (copy no longer always returns an object of the same class).
Comments?

------------------------------------------------------------------------------
Oliver Steele				  ...!{decvax,ihnp4}!mcnc!unc!steele
							steele%unc@mcnc.org

	"They're directly beneath us, Moriarty.  Release the piano!"