[comp.lang.smalltalk] Smalltalk Implementation Summary

kjx@comp.vuw.ac.nz (R James Noble) (12/07/89)

I have received several responses to my posting regarding Smalltalk
implementation. Thanks to all who replied. The general consensus was
as follows:-

a) Cascaded message sends.  Little Smalltalk is wrong in its
interpretation of this syntax: a b c; d should send c then d to the
result of (a b).

b) Blocks should be fully reentrant, and allow block temporaries.
Syntax: [ :a1 :a2 | t1 t2 | ... ]

c) Mutable literals. The most popular suggestion was to include classes
LiteralArray and LiteralString which would not include modification
messages .. no at:put: .  The second option was that mutable literals
were an important part of the language and should not be changed.

d) Multiple inheritance.  Standard Smalltalk does not include multiple
inheritance. It could be something worth including, especially if it
actually worked.

e) Class library. The core classes (Numbers, Collections) would need
to remain much the same. Graphics classes and the user interface are
heavily used by some people, however several other suggested that it
is getting obsolete, and so could be replaced. No-one seemed to care
about the internals of the Class hierarchy or the compiler, provided
the "feel" (mainly the external interfaces) of Smalltalk was retained.
The actual hierarchy of classes was considered less important than the
functionality and interface.

One strong opinion was that any system called Smalltalk should be
reasonably close to ParcPlace and/or the Blue Book. Unless a system is
at least as powerful as St-80 it should not be called a Smalltalk,
Smalltalk like, perhaps. It would need to support standard syntax,
possibly with changes b) and c) above, and the class library would
have to be reasonably close, perhaps as close as Digitalk (which
everyone seems to class as a "real" Smalltalk).

In reference to another question, I know of no Public Domain Smalltalk
implementation which would meet these criteria. (But would be happy to
be proved wrong!).




--
R James Noble
Graduate Student, Computer Science Department
Victoria University, Box 600, Wellington 1, New Zealand
kjx@comp.vuw.ac.nz 		     ...!uunet!vuwcomp!kjx      

sabbagh@acf5.NYU.EDU (sabbagh) (12/09/89)

In article <1989Dec6.235311.12726@comp.vuw.ac.nz> kjx@comp.vuw.ac.nz (R James Noble) writes:
>
>I have received several responses to my posting regarding Smalltalk
>implementation. Thanks to all who replied. The general consensus was
>as follows:-
> [stuff deleted]
>b) Blocks should be fully reentrant, and allow block temporaries.
>Syntax: [ :a1 :a2 | t1 t2 | ... ]

Also, blocks must carry around the environment in which they are
defined. Consider

aMethod: arg
 ^[ : aBlockArg | aBlockArg foo: arg].

which is entirely legal in Smalltalk.  Blocks may also refer to 
temporary variables delcared in the method.


Hadil G. Sabbagh
E-mail:		sabbagh@csd27.nyu.edu
Voice:		(212) 998-3125
Snail:		Courant Institute of Math. Sci.
		251 Mercer St.
		New York,NY 10012

186,282 miles per second -- it's not just a good idea, it's the law!

jcg@iris.brown.edu (James Grandy) (12/14/89)

In article <1989Dec6.235311.12726@comp.vuw.ac.nz> kjx@comp.vuw.ac.nz (R 
James Noble) (you) write(s):
> b) Blocks should be fully reentrant, and allow block temporaries.
> Syntax: [ :a1 :a2 | t1 t2 | ... ]
> 

Isn't this a bit hard to parse? How do you know, given that a block 
without temporaries looks like this:   [ :a1 :a2 | ... ] , 
whether t1 is the receiver of the first message in the block 
or a temporary? Of course, if you drop the bar separator when 
there are no arguments, not only is the block easier to parse, 
but it now looks more like a method header:
  
                          [ :a1 :a2   a1 foo: a2]

Then, with arguments, the block is as before:

                          [ :a1 :a2 | t1 t2 | t1 <- a1 foo a2 ]

Maybe not feasible if you want to be language compatible with other 
Smalltalks, but...


James Grandy
(401) 862-1610                jcg@iris.brown.edu
IRIS Brown University
Box 1946, Providence, RI 02912

rich@inmet.inmet.com (12/15/89)

Is this legal in Smalltalk?  I know blocks are not true lambda closures. 
Little Smalltalk generates an error when you execute the "test" method.

	test
		self getAblock value
|
	getAblock
		^ [ ^ 2 ]

If the block that getAblock doesn't explicitly return, then it goes OK.

Richard Man
	uunet!inmet!rich

susser@apple.com (Joshua Susser) (12/16/89)

In article <22600003@inmet> rich@inmet.inmet.com writes:
> Is this legal in Smalltalk?  I know blocks are not true lambda closures. 
> Little Smalltalk generates an error when you execute the "test" method.
> 
>         test
>                 self getAblock value
> |
>         getAblock
>                 ^ [ ^ 2 ]

The environment a block executes in is called a BlockContext (BC from now 
on).  Blocks themselves are not first-class objects, but BCs are.  A BC 
has a reference back to the MethodContext (MC) where it was *created* - 
this is called the home context, and it is where code in a block goes to 
get variables declared in its enclosing scope.  When you say "^" in a 
block, you are returning FROM THE HOME CONTEXT to the home context's 
sender context.  This is why things like "ifTrue: [^self]" can work.

When you send getABlock, you activate the method and create a MC.  Then 
you create a BC which refers to its home context, the current MC.  Then 
you return from the current MC.  This can only be done once.  So when you 
evaluate the block, and it tries to return from its home context AGAIN, 
you have serious problems.

So why can you only return from a method once?  I don't know, go ask Peter 
Deutsch.  Actually, he may have fixed this in the current version of 
Smalltalk-80.  It's been over a year since I've used Smalltalk-80, so I 
haven't kept up with their technology.

One feature I've always missed in blocks was a local return construct.  There are times when I want to bail out of a block in the middle, and return a value to the place that called the block.  This would allow for some more flexible control stuctures like loop exits, continues, etc.

-Joshua

------------------------------------------------------------------------------
Joshua Susser                                             Apple Computer ,Inc.
Object Percussionist                                 Advanced Technology Group
arpa: susser@apple.com                             20525 Mariani Ave. MS 76-2D
uucp: {sun,nsc,...}!apple!susser                           Cupertino, CA 95014
AppleLink: susser.j                                               408/974-6997

"I beat on objects."

moss@takahe.cs.umass.edu (Eliot &) (12/19/89)

I just thought I would note, in relation to the discussion posted of
BlockContexts and MethodContexts, that Smalltalk 2.5 now has BlockClosures,
and each invocation of a block (via value, value:, etc.) uses a new Context
for the locals, args, etc. In short, Smalltalk now has true closures and true
static scoping of the variables rather than the previous hacky approximation
to closures. Please don't direct detailed questions to me, though, I'm still
picking 2.5 apart to understand the details ....		Eliot
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer and Information Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206; Moss@cs.umass.edu

moss@takahe.cs.umass.edu (Eliot &) (12/20/89)

Actually, in Smalltalk 2.5 from PARC Place, blocks *are* true lambda closures.
I think Smalltalk implementers generally consider this to be a long needed fix
to the language and its implementation. In 2.5, one gets a BlockClosure for
each block, and a new Context is created for each invocation of that closure.
There is also full static scoping (block level addressing), with important
optimizations to speed up the implementation. Perhaps someone at PARC Place
would care to comment further?				Eliot
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer and Information Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206; Moss@cs.umass.edu