[ENH] Empty return expression

Michael Klein Mklein at nts.net
Fri Oct 1 18:17:35 UTC 1999



On Monday, September 27, 1999 5:08 PM, Stephen Pair wrote:
>  I (Michael Klein) wrote:
> > 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
> 
> That same argument could be applied to C++ by C++ers in saying that 99% of
> the time you don't need classes exposed as first class objects.  For this
> reason, and many others, I prefer Smalltalk. 

Yes, but, like the inspiration of genius, that remaining 1% is crucial.
C++ give you no powerfull hooks.  If you are lucky, your C++ will cough
up the name of the class of an object in a non-portable fasion.]

Also, you seemed to have mistaken my perception of Smalltalk for an
argument of why it should stay like it is.  I really do wish people gave
some *good* thought to the art of a Smalltalk meta-object protocol.

I'm pointing out that by adding OO "features" to Smalltalk, you give up
a prime benifit of it's simplicity.  Read again what I said about
exceptions.
They use powerful hooks like thisContext, and unwind-protection (in VW).
The are part of the code base, like OrderedCollection.

> However, I wish things like
> message sending, message handling, instance variable accessors, and
> messaging were more generalized and accessible.  I hope that eventually
> Squeak will evolve far beyond ANSI Smalltalk.

I hope that ANSI Smalltalk will evolve, but I'm afraid I'm quite alone
amongst Smalltalkers
in that regard.  Squeak, and all of the other Smalltalks are already far
beyond
ANSI.  ANSI is merely an agreement upon the known.

> > For example, Smalltalk give you single static inheritence, but if you
> > want to implement
> > multiple or dynamic inheritence, you can.
> 
> But not easily.

Compared to what?  Java?  C++?  Fortran?
Sure, it's probably easier to do in Self than Smalltalk.  Scheme...
tough to say.

> > Likewise for
> > multi-polymorphism (although I'm
> > sure we can do better than double-dispatching & coersion).  You can be a
> > productive
> > Smalltalk programmer, and never even know about primitive methods.
> 
> Of course, and that's a (or should be) key design goal.

Sure.  Primitive methods and the prime anomoly are rites of passage for
Smalltalkers.

> > 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).
> >
> > I'm afraid that if we add stuff like this to Smalltalk, it will turn
> > into CLOS.
> 
> In my opinion thisContext is a key concept and we should not strive to hide
> it's presence.  Also, implementing a return with ^ seems non-smalltalky to
> me.  It seems cleaner and more consistent to say "thisContext
> terminateAndAnswer: someObject" (although it is obviously more cumbersome to
> type).  The more expressive form clearly indicates exactly what is
> happening.

It's not hidden.  Its just a power tool thats not for everyday use.

I dont what to see code like:

	| tempVar |
	thisContext tempAt: 1 put: 'Initial Value'

I want:

	| tempVar |
	tempVar :=  'Initial Value'

You may find it insightful to browse references to: #tempAt:  and
#tempAt:put:


Similarly, Bad:

	gun perform: #shoot.

Good:

	gun shoot.

Obfuscatory:

	gun perform: #perform:with: with: #shoot

I usually introduce programmers to Smalltalk by saying:

	"Smalltalk is a very simple language.  There's only three things you
can do:
	Assign a variable,
	Return a value,
	and send a message.

This is obviously a gross simplification, but since everybody knows
about what the
first 2 things do, this puts the focus upon *messaging*, the soul of
Smalltalk.

Not objects.  Not Classes.  Not inheritence.

> And, InstructionStreams are really the fundamental unit of processing and
> should take much of the responsibility currently held in Process.
> Especially when considering how one would architect a Squeak that takes
> advantage of multi-processor CPUs.

I'm personally more concerned with language design, not implementation.
But, fundamentatly, there's got to be that eval/apply gem somewhere.
As far as InstructionStreams being fundamental... I'm against byte-code
standardization.  It only solves political problems.

(of course most of Smalltalk's problems are political (compared to Java,
for example)
not technical, but that's a whoooole other thread)
(Do Smalltalker's *really* want Smalltalk to be more popular?  In any
revolution
there are 2 sides.... the establishment, and the movement)

> > I say we build stuff like this around the powerful hooks... much the way
> > Exceptions
> > are built around thisContext.  Smalltalk was never about quiet syntax.
> > Smalltalk is
> > about deeper semantics.
> >
> > 	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!
> 
> I didn't mean to imply that "thisContext terminate" should terminate the
> Process (as it does), but rather that it should complete processing of a
> method context (as "^self" does).
> 
> - Stephen
> 

Squeak kinda has this:

	thisContext return: 'The Answer' to: thisContext home sender

But it is so far from working that it's funny.  The OOPSLA paper shows
how to make
it work.


Before I close this lengthly response, let me point out that the above
questions I asked
are not rhetorical.  I really want to know what all of you out there
think.

If I were to pick one existing OO feature that I would be interested in
exploring in Smalltalk,
it would be method combination (maybe mixed with mult-methods)

-- Mike Klein





More information about the Squeak-dev mailing list