[Squeak-e] squeak-e and ANSI Smalltalk

[Robert Withers]

Hi Allen,

This is very interesting news.  I don't know how important eventual 
sending is in providing a system supporting capabilities.  There is a 
really rough implementation I did, on the swiki ( 
http://minnow.cc.gatech.edu/squeak/2410 ), but it is broken in several 
places (self sending through an inspector on an eventual reference).  
In looking at the ANSI spec, there was a discussion of the 
computational model and it is a immediate call/return model of 
execution, which I have pasted below.  Additionally, the protocol 
specifications define a return value, which may not support a promise 
model of execution.

What are your thoughts about changing the computational model of squeak 
in this way?

I suppose the broader question is do we need to do this to support 
capabilities?

cheers,
rob

"from the ANSI speciffication"

A message send causes execution of the currently active method to be 
temporarily suspended and for program execution to continue starting 
with the first expression of another method. A message send directs a 
message to an object. The object is called the receiver of the message. 
A message consists of a method selector and a set of arguments. Each 
argument is a reference to an object. When an object receives a 
message, the method selector of the message is used to select the 
method from the object's behavior that corresponds to the selector. The 
method becomes the new locus of execution. Special processing takes 
place if the receiver's behavior does not include a method 
corresponding to the message's method selector.

A return terminates execution of a method and causes execution to 
resume within the method that executed the message send that activated 
the method containing the return. Execution continues immediately 
following the message send expression. The return provides a value (an 
object reference) that becomes the value of the message send.




On Friday, January 31, 2003, at 07:59 PM, Allen Wirfs-Brock wrote:

> I just want to mention that when I read Lex's "Object as Capabilities 
> in Squeak" I was struck by the number of similarities between it and 
> much of what is in the ANSI Smalltalk specification.  Just as one 
> example, in ANSI Smalltalk a reference to OrderedCollection doesn't 
> necessarily bind to a "class object". It is simply a "named object" (a 
> constant global binding) to an object that is required to conform to 
> the protocol <OrderedCollection factory> and this protocol only 
> includes a few instantiation messages.
>
> In developing the ANSI Smalltalk specification we were trying to 
> define the core user language and protocols that is most commonly used 
> in application programs, rather than in tools or the reflective 
> implementation of a Smalltalk environment.  To do so, we needed to 
> strip away all the meta-level and implement artifact messages that 
> clutter all conventional Smalltalk implementation.  This sounds very 
> similar to what you need to do to define a secure dialect of > Smalltalk.
>
> If you haven't read the ANSI spec. for awhile (or ever) you might find 
> that this perspective offers some clues to the perennial question 
> "what were your guys smoking when you wrote that spec?".
>
> If you don't have a copy of the ANSI Smalltalk Standard a near final 
> draft is still available at:
>
> 	ftp://ftp.smalltalksystems.com/sts-pub/x3j20/standard_v1_9.doc
> or
> 	ftp://ftp.smalltalksystems.com/sts-pub/x3j20/standard_v1_9.rtf
>
> Allen_Wirfs-Brock at instantiations.com
>
>
> _______________________________________________
> Squeak-e mailing list
> Squeak-e at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeak-e
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3763 bytes
Desc: not available
Url : http://lnx-12.ams-2.theinternetone.net/pipermail/squeak-e/attachments/20030201/dce966bf/attachment.bin