[Squeak-e] squeak-e and ANSI Smalltalk

[shane at shaneroberts.com]

I have a question about this.  Part of the philosophy which 
motivated the creation of Squeak (as I understand it) is to be an 
"open" system.  That is users/researchers can get at any part of the 
system.  So my question is, would you want to violate this 
philosophy by changing Squeak to "control" access to parts of the 
system?

Or would capabilities be something that you implement between 
"images", that is, different instantiations of the image run-time?

Are capabilities something that becomes important for inter-host 
communication over a network?  Or for intra-host (on the same 
host) user process cooperation?

I'm not sure what these questions mean in terms of "normal" 
Smalltalk operation and security measures.  Has anyone on this list 
dealt with Smalltalk security issues before, without relying upon 
host operating system services?

Shane


On 1 Feb 2003 at 17:02, Robert Withers wrote:

> 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"
> 
> 
> <fontfamily><param>Arial</param><smaller>A <italic>message
> send</italic> 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
> <italic>receiver</italic> of the message. A <italic>message
> </italic>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 <italic>return</italic> 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.
> 
> </smaller></fontfamily>
> 
> 
> 
> 
> On Friday, January 31, 2003, at 07:59 PM, Allen Wirfs-Brock wrote:
> 
> 
> <excerpt>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
> 
> 
> </excerpt>