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