Why we should remove {} from Squeak

Richard A. O'Keefe ok at atlas.otago.ac.nz
Mon Oct 1 23:36:54 UTC 2001


ducasse stephane <ducasse at iam.unibe.ch> writes:
	> so it obviously CAN be eliminated.  That doesn't mean it should be.
	> #@ can be eliminated too:  aNumber @ anotherNumber is equivalent to
	> Point x: aNumber y: anotherNumber.  That doesn't mean #@ should be
	> eliminated.
	
	There is a big different @ is a message not a parsed construct
	with specific rules!!!!!
	
As a Squeak *user* I couldn't care less.
The analogy holds good:  (feature X *could* be eliminated)
does NOT entail (feature X *should* be eliminated).

You want a syntactic analogue?  Here's one:  Smalltalk could get by
without blocks.  
    
    BlockReplacement

Where there is now a block

	... [:a1 ... :an| stuff ] ...

referring to method variables v1 ... vk, write

	|t|
	t _ BlockReplacement
	    for: thisContext
	    in: self
	    selector: #c:m1:...mk:


and add a method
	c: homeContext m1: a1 ... mk: ak
	stuff

replacing			by
	vi			homeContext at: #vi
	vi := e			homeContext at: #vi put: e
	^e			homeContext return: e

There's no shortage of details to be worked out, but the thing _could_ be
done.  This might even be a reasonable implementation strategy.  That
does not mean the feature SHOULD be eliminated.

	> The practical questions are
	> - would eliminating this feature save more code in the parser and elsewhere
	> than it would cost in all the code using it (remember, not all such code
	> is known to SqC or anyone else)
	
	I could remove it!
	
This is a fact of no interest or value to anyone else.
The fact that someone who doesn't LIKE the feature would not be harmed
by deleting it should neither surprise nor inform anyone.

	> - is ideological purity worth the loss of clarity?
	
	Sure else Smalltalk would be like Java
	
In a word:  rubbish.  Smalltalk *HAS* this feature and is not like Java.
(Hint:  'int' is not a class in Java.  Hint:  look at control structures.)

	> - would it be feasible to make {} support a module?
	> 
	> At 8:49 +0200 9/30/01, ducasse stephane wrote:
	>> #() is necessary because it is compiled statically and cannot
	>> not be simulated by other construct.
	>>  Storing #() in Stack frame is not really good
	>> but this is an implementation aspect.
	> 
	> This is false.  Any use of # can be eliminated by adding a class variable
	> and a class method using lazy initialisation.  For example,
	> #( abc 'abc' 4  3.4  $r )
	
	This is not my point.  I was just saying that storing #() in
	stake frame can lead to strange error.

The points that were explicitly made were "#() is necessary" and
"#() ... cannot be simulated by other construct."
As I have shown, neither is true.
	
	I'm really sorry to see the level of the discussion
	
Can anyone else tell me what is wrong with a polite reductio ad absurdum
argument?





More information about the Squeak-dev mailing list