[ENH] Empty return expression

Marcel Weiher marcel at metaobject.com
Thu Sep 30 10:05:23 UTC 1999


> From: "Stephen Pair" <spair at advantive.com>
>
> thisContext answer: 1.
> thisContext answer: 2.
> ^

I really like this!  It gently combines the more general symmetric  
message sends with the shorthand that's useful 99% of the time.

> From: Michael Klein <Mklein at nts.net>
>[...somewhat against the idea...]
> Smalltalk chooses a "fixed" point in language desing space that is good 
> for 99+ % of the time.
> It also gives you all of the powerfull hooks to handle the remaining 
> small amount.
> (The powerfull hooks are things like Behavior, #doesNotUnderstand:, 
> #become:, thisContext, etc)
> These are very powerful for building frameworks that allow "ordinary" 
> (99+%) methods to
> avail themselves of extreme coolness

Yes, the problem with these sorts of extensions is that the language  
itself (especially the syntax) has to evolve to allow many of these  
extremely cool features to actually be used.

> There was a good mind-bending paper at OOPSLA a decade or so ago,  
on how
> to add
> back-tracking to Smalltalk without VM support (using thisContext). 

For example, I typed that in a while ago (posted it to the list as  
well), and found that for something like it to actually be used, it  
would need better syntactic support.  Asynchronous messaging is a  
(small) step in that direction, and what I like about Doug's idea is  
that it tweaks the syntax almost imperceptibly to make asynchronous  
messaging much more natural to express.  If we have to express  
meta-constructed artifacts in meta-languages (outside the base  
language), they will not be used.

One of the really neat aspects of Smalltalk for moving language  
forward is that the fundamental abstractions (object, message,  
message-send) are actually *much more* general than their current  
implementations ( data-structures, late-bound procedures, procedure  
invocation with hierarchically structured name matcing) and need only  
be tweaked ever so slightly to become even more general.

> 	self doStuff. ^
> 		vs.
> 	self doStuff. Processor terminateActive.
>
> I certainly don't want a quiet syntax for killing a process!  I want to 
> HEAR the BANG
> of the bullet that kills it!

This is correct in the context of current Smalltalk-80, where a  
Process is a heavyweight construct and one most programmers simply do  
not see.  However, when doing asynchronous messaging, "process"  
termination is roughly analogous to method termination and just about  
as common.  I certainly wouldn't want to write "Processor  
terminateCurrentMethod" at the end of each method!

> I just see the fun of debugging a terminating spurious ^.
> It's like shooting you self in the foot with a silencer.  Your  
foot just
> disappears without a clue.

I also much rather have single exit methods, with the only exit  
being termination.  Can lead to slightly more complex if-nesting, but  
is usually worth it.


Marcel





More information about the Squeak-dev mailing list