Squeak-e February 2003

squeak-e@lists.squeakfoundation.org

17 participants
29 discussions

RE: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
by Withers, Robert 07 Feb '03

07 Feb '03

> -----Original Message----- > From: Anthony Hannan [mailto:ajh18@cornell.edu] > "Mark S. Miller" <markm(a)caplet.com> wrote: > > (The above argument is also bit of a preview of my upcoming > "What's Wrong > > with Dynamic Scoping?") > > I agree dynamic scoping is bad (my "smart" capabilities would have > relied on it). The only tricky thing is how to handle exceptions. Guys, I don't agree that dynamic scoping is bad, it just may not be secure in it's current form. Colin's recent comments drives this point home. If the environment isn't open from top to bottom to our investigation and modification, then it isn't going to be Smalltalk. This is a critical feature to retain. Traits, continuations and my eventual sending redirectors are other examples where either dynamic scoping or system openness are crucial to allow us the facility. The reason I include both dynamic scoping and system openness, is that the openness of Squeak _currently_ depends on dynamic scoping. We shouldn't lose this as we shift towards more security; in fact we should only extend squeak to start supporting security, and keep it backwards compatible. We can start this process by looking at providing more vm support for evental sending, finishing CapTP, and by migrating Lex's Islands work to 3.5. Thus I think the short-term (couple of months) goal should be supporting security level 2 of Mark's original proposal. > Your right, I'm giving too much authority to Kernel creators. > So instead > I propose that once a creator "releases" his class he can no longer > change it. If he wants to make revisions he has to create a new > subclass. Others may decide to use his new subclass or not. They may > migrate existing instances to the new class and/or use the > new class for > new instances. I don't like this restriction. Classes and code should be able to evolve. Now if an 'Island' has classes bound into it, those classes shouldn't change, unless the right capabilities to change them are held. I think the argument Mark is making is that there isn't a central authority. In fact, there is no third party security sever or third party interface respository. I do think that we could specify the protocols for a base library, but that's really what the ANSI spec is about. There may be some library specification additions for supporting security/eventual sends. > MarkM wrote: > > Same problem then. I think these can't be automatically > replicated, because > > there is no one authority everyone would mutually trust. At > least I hope there > > won't be. A world in which there's some one authority > everyone is willing to > > make themselves fully vulnerable to is a world ripe for > dictatorship. > > Yes, like above I will change this so no one has authority once the > pool is "released". However, I will still allow the creator > to add new > classes to a pool. This is where he could add his new > subclass versions. > Adding to a pool is benign. Again, I think that with the right capability, these things could be changed 'locally'. The issue is that there isn't a global authority. I am encouraged that although this list is turning out to be on the quiet side, there is much interest in what we are considering. The fact that we are doing so in a thoughtful way is to our advantage. I will be a little more active this weekend, now that the work week is winding down. I want to implement RemoteHandlers (virtual circuits with remote objects) and the objectMap. The other dimension, that I have been doing a little work with this past week, is cleaning up the EventualReferences. I am hanging out on the IRC channel #squeak-e and will be available there to guide anyone wanting to dive into this very intriguing mechanism. Look at ReferenceContext (the eventual reference), and RedirectionManager (the underlying redirection mechanism). If you build a redirection vm, make sure you doit to 'RedirectionManager enable'. I will update the SqueakElib package this evening. cheers, rob

1 0

Re: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
by Anthony Hannan 07 Feb '03

07 Feb '03

In last paragraph of my last post Anthony Hannan <ajh18(a)cornell.edu> wrote: > Ie. all classes of possible collaborators must reside in the > method class's pool. should read: Ie. all INTERFACES (abstract classes and class extensions) of possible collaborators must reside in the method class's pool. Cheers, Anthony

1 0

Re: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
by Anthony Hannan 07 Feb '03

07 Feb '03

"Mark S. Miller" <markm(a)caplet.com> wrote: > > At 09:47 PM 2/6/2003 Thursday, Anthony Hannan wrote: > >Sorry this was not written more clearly. A "smart capability" is a > >revocable capability that is automatically revoked if used by someone > >other than the designated client (sender). > > I'm still confused. How would it tell who it is being used by? Earlier I wrote: > >> [...] What do you mean by "confirm the sender"? What > >> information would you examine, and what notion of sender would you compare > >> it against? [...] > > Likewise, above you write "designated sender". Designated how? What would be > designated? Do you imagine designating the individual object that may send > to a given capability? Why would this be useful? > > > If Alice gives Bob a "smart" > >capability to Carol. That capability will only forward messages to > >Carol if the message is from Bob. If Bob gives the capability to anyone > >else it won't work. I've have just realized my "smart" capabilities scheme is useless. Even if it prevents Bob from giving the capability directly to others it does not prevent him from acting on other's behalf. He could act like a forwarder for others thus giving out the capability indirectly. So please ignore my "smart" capabilities. I will remove if from my paper. Thanks for catching me on this. > Please read Capability Myths Demolished. I did. Very good paper! > The bigger issue is that with proper capability foundations, this kind of > behavior isn't possible. It would violate the encapsulation of the sender > for the receiver to know anything about the sender other than: > > * What the sender decided to send to the receiver as arguments. > * That the sender therefore must have had capabilities to these arguments > and to this receiver. > > Nothing else is the receiver's business. This information hiding allows > senders to reorganize freely the nature of the computation from which these > messages are emitted, since this change of organization can't be sensed by > the receivers. This is good modularity just as much as it is good security. Good point. I agree. > (The above argument is also bit of a preview of my upcoming "What's Wrong > with Dynamic Scoping?") I agree dynamic scoping is bad (my "smart" capabilities would have relied on it). The only tricky thing is how to handle exceptions. > As of ParcPlace 2.5, ignoring thisContext, the above properties were also > true of regular Smalltalk programming. Violating them takes us away from the > object paradigm and the capability paradigm. Yes, we will have to eliminate thisContext from Squeak-E. It should be enough to just have the following, implemented as primitives: [^ ...] (block remote return) ensure: ifCurtailed: on:do: signal. > >I threw it in as an alternative to information flow security. > > I don't know anything about information flow security. Please check out: Andrei Sabelfeld and Andrew C. Myers. Language-Base Information-Flow Security. IEEE Journal on Selected Areas in Communications, special issue on Design and Analysis Techniques for Security Assurance, 21(1), January 2003. <http://www.cs.cornell.edu/andru/pubs.html> It is interesting work and seems to be an active area of research. It relies on static typechecking of programs whose variable types have been annotated with security labels. It provides end-to-end security; information can never flow from higher to lower security, even derived information. > >Yes, common classes are common across the universe and replicated on > >users' machines that use them. But they still may need to be evolved, > >so some trusted "Squeak Central" users may have authority to change > >them. Their changes would be propogated to all machines that have > >replicas of them. > > Once I make the decision to install a security kernel of some sort, whether > a secure OS or language kernel, everything else I do on it is then fully > vulnerable to the misbehavior of that kernel. I'm trusting it with a lot. I > don't make that decision casually, and I make it based on my sense of the > scrutiny given to that code by an open community. > > When I make that installation decision, I make it with regard to a > particular version of the code. Granted, once I've done so, I probably > regularly decide to upgrade to the later version published by the same > organization without adequate further thought. But (at least for me), > I *must* make that decision manually each time. Otherwise, I make myself > vulnerable to the organization itself, rather than just to each individual > version of their (hopefully widely reviewed) code. Your right, I'm giving too much authority to Kernel creators. So instead I propose that once a creator "releases" his class he can no longer change it. If he wants to make revisions he has to create a new subclass. Others may decide to use his new subclass or not. They may migrate existing instances to the new class and/or use the new class for new instances. > >> 3.2: > >> Are you proposing that each pool dictionary be replicated across all users? > > > >Yes, replicated to all users that are using them. Remember, I envision > >all users working on the same object graph (same Smalltalk image). > >Parts of the graph that a user is accessing are replicated or proxied to > >his machine. > > > >> If so, then these must contain no authority as you've heard me harp on. > > > >That is where read-only classes come in (section 3.3). Each pool only > >contains read-only cabilities to classes. Additionally, each pool > >cannot be changed (elements cannot be added, removed, changed) unless > >someone has a capability to do so (like "Squeak Central" authority to > >change common classes above). > > Same problem then. I think these can't be automatically replicated, because > there is no one authority everyone would mutually trust. At least I hope there > won't be. A world in which there's some one authority everyone is willing to > make themselves fully vulnerable to is a world ripe for dictatorship. Yes, like above I will change this so no one has authority once the pool is "released". However, I will still allow the creator to add new classes to a pool. This is where he could add his new subclass versions. Adding to a pool is benign. > >> 3.4: > >> Really really cool. But, since you wish to prevent the class extension from > >> overriding the common class it's extending, what happens if the common class > >> later defines a method for one of the messages defined by some extension? > > > >They would essentially be different selectors (messages). > >Typed-selectors (section 3.6 below) provides separate selector > >namespaces for each class and class extension, so there would be no > >conflict. A class may only be polymorphic with another class if they > >both inherit from the same abstract superclass (interface) that > >introduces the polymorphic selector. Classes and their class extensions > >do not inherit common selectors so they can't be polymorphic or > >conflict. > > Doesn't this require selectors in the source always to be written in the > qualified form? Not if the selector by itself is unique among all possible selectors visible in the method class's pool. Remember, a method can only send selectors of abstract classes/extensions found in the method's class pool. Ie. all classes of possible collaborators must reside in the method class's pool. Internally, all selectors will be qualified (in case the pool changes) but when displayed only ambiguous selectors will need to be qualified. Of course, the user may set a preference to qualify all selectors when displayed. Thanks, Anthony

1 0

squeak-e and ANSI Smalltalk
by Allen Wirfs-Brock 07 Feb '03

07 Feb '03

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(a)instantiations.com

4 7

Re: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
by Mark S. Miller 07 Feb '03

07 Feb '03

At 09:47 PM 2/6/2003 Thursday, Anthony Hannan wrote: >Sorry this was not written more clearly. A "smart capability" is a >revocable capability that is automatically revoked if used by someone >other than the designated client (sender). I'm still confused. How would it tell who it is being used by? Earlier I wrote: >> [...] What do you mean by "confirm the sender"? What >> information would you examine, and what notion of sender would you compare >> it against? [...] Likewise, above you write "designated sender". Designated how? What would be designated? Do you imagine designating the individual object that may send to a given capability? Why would this be useful? > If Alice gives Bob a "smart" >capability to Carol. That capability will only forward messages to >Carol if the message is from Bob. If Bob gives the capability to anyone >else it won't work. If "Bob" is an individual object, this breaks subcontracting among objects, and leads to a system that's very hard to program. If Bob is a large aggregate of objects, then we have other problems. In either case, this allowing or disallowing based on the alleged identity of the sender is the ACL paradigm. This way madness lies. Please read Capability Myths Demolished. > "Smart" is bad term. Also, hopefully this kind of >capability isn't needed in a well designed system. So let's design the system well enough that we don't need it. The bigger issue is that with proper capability foundations, this kind of behavior isn't possible. It would violate the encapsulation of the sender for the receiver to know anything about the sender other than: * What the sender decided to send to the receiver as arguments. * That the sender therefore must have had capabilities to these arguments and to this receiver. Nothing else is the receiver's business. This information hiding allows senders to reorganize freely the nature of the computation from which these messages are emitted, since this change of organization can't be sensed by the receivers. This is good modularity just as much as it is good security. (The above argument is also bit of a preview of my upcoming "What's Wrong with Dynamic Scoping?") As of ParcPlace 2.5, ignoring thisContext, the above properties were also true of regular Smalltalk programming. Violating them takes us away from the object paradigm and the capability paradigm. >I threw it in as an >alternative to information flow security. I don't know anything about information flow security. >Yes, common classes are common across the universe and replicated on >users' machines that use them. But they still may need to be evolved, >so some trusted "Squeak Central" users may have authority to change >them. Their changes would be propogated to all machines that have >replicas of them. Once I make the decision to install a security kernel of some sort, whether a secure OS or language kernel, everything else I do on it is then fully vulnerable to the misbehavior of that kernel. I'm trusting it with a lot. I don't make that decision casually, and I make it based on my sense of the scrutiny given to that code by an open community. When I make that installation decision, I make it with regard to a particular version of the code. Granted, once I've done so, I probably regularly decide to upgrade to the later version published by the same organization without adequate further thought. But (at least for me), I *must* make that decision manually each time. Otherwise, I make myself vulnerable to the organization itself, rather than just to each individual version of their (hopefully widely reviewed) code. >> 3.2: >> Are you proposing that each pool dictionary be replicated across all users? > >Yes, replicated to all users that are using them. Remember, I envision >all users working on the same object graph (same Smalltalk image). >Parts of the graph that a user is accessing are replicated or proxied to >his machine. > >> If so, then these must contain no authority as you've heard me harp on. > >That is where read-only classes come in (section 3.3). Each pool only >contains read-only cabilities to classes. Additionally, each pool >cannot be changed (elements cannot be added, removed, changed) unless >someone has a capability to do so (like "Squeak Central" authority to >change common classes above). Same problem then. I think these can't be automatically replicated, because there is no one authority everyone would mutually trust. At least I hope there won't be. A world in which there's some one authority everyone is willing to make themselves fully vulnerable to is a world ripe for dictatorship. >> 3.4: >> Really really cool. But, since you wish to prevent the class extension from >> overriding the common class it's extending, what happens if the common class >> later defines a method for one of the messages defined by some extension? > >They would essentially be different selectors (messages). >Typed-selectors (section 3.6 below) provides separate selector >namespaces for each class and class extension, so there would be no >conflict. A class may only be polymorphic with another class if they >both inherit from the same abstract superclass (interface) that >introduces the polymorphic selector. Classes and their class extensions >do not inherit common selectors so they can't be polymorphic or >conflict. Doesn't this require selectors in the source always to be written in the qualified form? ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

1 0

Re: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
by Anthony Hannan 07 Feb '03

07 Feb '03

Hi Mark, thanks again for your critique, here are my responses: Mark S. Miller <markm(a)caplet.com> wrote: > Anthony Hannan wrote (in his Shared Smalltalk paper): > 2.2: > > If you have to give out stronger capability objects, make sure the client is > > trustworthy, since it may pass the capability along to other objects. It is > > possible to create smart capabilities that confirm the sender at runtime, > > but this requires maintaining an access control list that is usually more > > trouble than handing the capabilities out correctly in the first place. > [likewise, but out of order] > > In extreme cases, where you need to give a stronger capability to an > > untrusted client, you can have the capability check who the sender or user > > is as mentioned earlier. You can have it wrap all results in new > > capabilities that also check who the sender/user is, and so on. This > > provides end-to-end security without trusting client objects, albeit with > > extra overhead. > > What problem do these "smart capabilities" solve that isn't better solved > using pure capabilities? What do you mean by "confirm the sender"? What > information would you examine, and what notion of sender would you compare > it against? These "smart capabilities" looks to me like a mixture of > capability and ACL notions. Among other things, it means that a sender > effectively has extra authority because of his identity, rather than just > the authority he chooses to use. This leads to confused deputy problems. > In terms of Figures 3 and 4 of Capability Myths Demolished > http://zesty.ca/capmyths/usenix.pdf , you have arrows pointed both ways. I > think this may be approximately what Li Gong's ICAP > http://citeseer.nj.nec.com/gong89secure.html tried to do. Sorry this was not written more clearly. A "smart capability" is a revocable capability that is automatically revoked if used by someone other than the designated client (sender). If Alice gives Bob a "smart" capability to Carol. That capability will only forward messages to Carol if the message is from Bob. If Bob gives the capability to anyone else it won't work. "Smart" is bad term. Also, hopefully this kind of capability isn't needed in a well designed system. I threw it in as an alternative to information flow security. > The next paragraph beginning with > > A fundamental difference > is just great. I don't remember seeing it explained this way before. I'm glad you like it. I think the idea of objects as clients/principles and not just users/processes is the paradigm shift needed to appreciate capability security. > 2.4: > In E, to declare an object PassByCopy it must satisfy three conditions: > * OpenState -- all its instance variables must be accessible through its > interface in a standard way. I think this maps exactly to what you're saying. > * OpenSource -- the object must make its source available through a > standard request on its interface. > * Frozen -- the instance variables must be immutable. (It would be adequate > to check that they aren't assigned to.) ... > If your copied objects aren't Frozen, then you'll need to coordinate > distribute state, which is tricky Yes, I'm assuming coordinated replicas which I know is tricky and therefore did not talk about it in my paper. I'm hoping classes and methods which don't change often can be replicated. PassByProxy would be used for most regular objects unless they meet the conditions you state above for PassByCopy. > 3: > > Since common classes are the same across users we will model them as > > actually being identical objects that are replicated but kept in sync [2]. > > This allows them to be changed together if need be by an authorized user. > > Aren't the common classes common across the universe? Who would have enough > authority to change these? I think I'm missing something. Yes, common classes are common across the universe and replicated on users' machines that use them. But they still may need to be evolved, so some trusted "Squeak Central" users may have authority to change them. Their changes would be propogated to all machines that have replicas of them. > 3.1: > I love your description of users and portals. I think it's exactly right. Yes, a user is just another object with it own capabilities. > 3.2: > Are you proposing that each pool dictionary be replicated across all users? Yes, replicated to all users that are using them. Remember, I envision all users working on the same object graph (same Smalltalk image). Parts of the graph that a user is accessing are replicated or proxied to his machine. > If so, then these must contain no authority as you've heard me harp on. That is where read-only classes come in (section 3.3). Each pool only contains read-only cabilities to classes. Additionally, each pool cannot be changed (elements cannot be added, removed, changed) unless someone has a capability to do so (like "Squeak Central" authority to change common classes above). > 3.4: > Really really cool. But, since you wish to prevent the class extension from > overriding the common class it's extending, what happens if the common class > later defines a method for one of the messages defined by some extension? They would essentially be different selectors (messages). Typed-selectors (section 3.6 below) provides separate selector namespaces for each class and class extension, so there would be no conflict. A class may only be polymorphic with another class if they both inherit from the same abstract superclass (interface) that introduces the polymorphic selector. Classes and their class extensions do not inherit common selectors so they can't be polymorphic or conflict. Polymorphism through inheritance implies tolerance for multiple inheritance. See http://minnow.cc.gatech.edu/squeak/1783 for my view of mulitple inheritance. Note, I did not propose multiple inheritance in my paper but I think I'm going to add it to make typed selectors and class extensions more complete. > 3.5: > > A user may also add a subclass to any class. If the superclass is read-only > > then the subclass can not access the superclass's instance variables or > > pool, only its own instance variables and pool. > > If the superclass sends a message to self, does the subclass receive it, as > one would naively expect? Yes. > 3.6: > > Finally, if the message name is found in more than one class interface, > > then those classes are presented to the user for him to choose. > > In this case, the choice should be represented by making the selector in the > source explicit (eg, your later "collection.do"). Otherwise, the source text > is not the complete source. Yes, agreed. > It also makes detached class extensions possible. > > Intriguing. How do you mean? I think this one's important to understand. I tried to explain this at the end of section 3.4. Since each selector (message) knows which abstract class or class extension (interface) it is part of, we know if we are calling a class extension method or a regular method. If we are calling a class extension method we look through it and its subclasses for the appropriate method without looking through the base class or its superclasses (class extensions can have subclasses that mirror the subclass hierarchy of the base class). The class extension subclasses are lookuped in the same order as their base classes starting with the class of the receiver. Cheers, Anthony

1 0

Re: [Squeak-e] Programming the VM
by cg＠cdegroot.com 05 Feb '03

05 Feb '03

Andreas Raab <squeak-e(a)lists.squeakfoundation.org> said: >I don't know where you heard that the object format is going to be changed >in 3.5 but adding a pointer to every object is unlikely to be done unless >you have a Very Good Reason(tm). It will instantly break all plugins and the >added space and GC overhead is not to be taken lightly. > Last thing I heard was that there were some changes necessary for various things, and that 3.5 would be the version where this would, as far as possible, would all be collected so that we'd have a break in image file format only once. But that was last October, before I went into a long dive involving directory services and other ugly business matters :-) I've already been thinking about the implications GC-wise and space wise. Probably some compression is possible and necessary. 90% of all objects, certainly in the beginning, will point to a default environment. A bit indicating whether there's additional environment info could save a lot of space and time. A second bit might indicate whether a short or long environment pointer is used (6-8 bit index in a table vs. 32 bit pointer). Immutables probably wouldn't need to have it at all. Anyway, the discussion *might* be premature; however, before diving into options it would be nice to know how feasible they are. So I fear that we need to discuss ways *how* to make this happen more-or-less in parallel with the discussion *what* exactly we want to make happen (e.g., what do we want to point to). In other words, even though it's premature from a technical viewpoint, as none of use here wants to fork Squeak (I hope) it is probably prudent to inventory the options for doing things like this as early as possible and see how/whether support can be raised. Politics, again... -- Cees de Groot http://www.cdegroot.com <cg(a)cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B Cogito ergo evigilo

4 4

Comments on Anthony's "...Shared Smalltalk"
by Anthony Hannan 05 Feb '03

05 Feb '03

Hi Mark, Thank you for critiquing my Shared Smalltalk paper. It is greatly appreciated especially from the one who enlightened me to capabilities in the first place. I will respond to your questions/points tomorrow in another email. For now I thought I would answer some quick questions you had in another email under the subject "Re: Comments on Lex's "Object as Capabilities in Squeak" "Mark S. Miller" <markm(a)caplet.com> wrote: > At 12:26 AM 1/31/2003 Friday, Lex Spoon wrote: > >There is a big engineering effort to get away from dynamic binding of > >class names yet still have limited access to classes. Happily, though, > >the independent modules efforts for Squeak seem to be solving this exact > >issue along with their other goals. > > Where can I read about this? There has been long discussions on how to separate the image, or at least its code, into modules. Some incomplete solutions have been developed (see http://minnow.cc.gatech.edu/squeak/Modules). The current solution is changeset packages catalogued in SqueakMap (http://minnow.cc.gatech.edu/squeak/SqueakMap). Lex is refering to modules that provide restricted namespaces, unlike SqueakMap packages, but more like Pools described in my Shared Smalltalk paper. > >Code uses World all over the place: there are 98 direct accesses to the > >variable, and 119 senders of #currentWorld. > > How do I make such queries in my image? Highlight "World" and hit Alt-Shift-N. Highlight "currentWorld" and hit Alt-n. For a complete list of options, select 'help...' -> 'command-key help' off of the World menu which comes up when you click on the background. Cheers, Anthony

1 0

Another Nested VM Proposal
by Mark S. Miller 05 Feb '03

05 Feb '03

At http://www.erights.org/javadoc/org/erights/e/elang/evm/Evaluator.html you'll find a strange old unimplemented proposal for handing E sub-expressions off to a reified evaluator while maintaining their lexical context. This proposal is strange because it enables one to introduce virtualization boundaries at expression granularity. This causes a complexity for E absent from Squeak-E: An E expression not only uses bindings introduced to its left, it also produces bindings that can be used by expressions on its right. As I recall, there's no corresponding issue in Smalltalk. In any case, an actual API for introducing lexically scoped virtualization should probably be limited to object-definition-granularity. Also, the above proposal doesn't take account of any of the subtle techniques that can make a big difference in the efficiency of virtualization. It may not preclude any of them either, but I haven't thought about it. ******************************* To build a safe and high-functionality system, one should start by building a safe and low functionality system, and then incrementally add functionality while preserving safety. The other way around doesn't work. As fascinating as these issues are, I believe we should make Squeak-E safe and coherent (to something like the level E is). Once we have that, we'll be in a much better position to making it highly self-malleable. But during the whole process, let's keep talking about the ambitious things we'd like to do, so we don't paint ourselves into a corner. ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

1 0

Are Handlers Dynamically Scoped? (was: Comments on Lex's "Object as Capabilities in Squeak")
by Mark S. Miller 04 Feb '03

04 Feb '03

At 11:16 AM 1/31/2003 Friday, Anthony Hannan wrote: >Yes, exception handling needs dynamic scope, doesn't it? Do you propose >handling exceptions differently? Exception handing was an aspect of PPS2.5 that I never did learn real well. Where is Squeak's exception handling documented? As I recall, PPS2.5 had both terminating and resumable exception handlers. Let's take these separately. Terminating Exceptions E uses only terminating exceptions, on the same model (for present purposes) as C++ and Java. Since I don't remember PPS2.5's terminating exceptions being any different from this, I'll just assume they're the same until I hear otherwise. I will use Java as the reference for this model, as it's probably the most mutually well known. Java try-catch and try-finally blocks do have some semantics in common with dynamic scoping. They push and pop on the stack according to nested dynamic extents, just as dynamic variable bindings do. When one is needed, the dynamically closest applicable one is looked up, presumably by looking back on the stack, corresponding to a deeply-bound implementation of dynamic scoping. However, I claim this isn't dynamic scoping. The "throw" is not directly invoking the corresponding "catch". Rather, the stack is being unwound and "finally {..}" clauses are getting run on the way out. If one of these finally clauses itself throws, we proceed to unwind with the new Exception *instead of* the old one. These effects fit poorly into the dynamic scoping model. Instead, what fits well is a simple extension of the continuation passing model of call-return computation (CPS). When writing in a call-return language, there's always one unstated additional parameter on all calls -- the continuation -- representing the rest of the computation the caller will perform once the callee returns. In denotational semantics, Actors, or Scheme, where CPS originated, the continuation was simply a function of one argument, where this argument was the value to be returned. (It's a separate matter as to whether the language allows the continuation to be reified, or treats it only as an explanatory device. Smalltalk, Scheme, and Actors do the first. C++, Java, and E do the second. For various reasons http://www.eros-os.org/pipermail/e-lang/2001-July/005418.html I recommend the second, but we can leave this argument to another time.) As explained in section ii of http://erights.org/elib/concurrency/msg-passing.html , to account for terminating exceptions, we model the implicitly passed continuation as an object with two methods resolve: result and smash: exception A throw just calls the smash method of its continuation. The peculiar behavior of a try-finally is just the peculiar behavior of the continuation it creates. (Note: to model E we need three methods in the continuation, but I think we can ignore that for present purposes.) So, clever implementations aside, the computational model is explained purely in terms of local message sending without any magic reaching up the stack (deep binding) or stateful variables being magically shared (shallow binding). I claim it's not dynamic scoping at all. Resumable Exceptions Although I may have programmed in languages that happened to support resumable exceptions, I myself have never used them in any language. So if this is where the "Are Handlers Dynamically Scoped?" issue is, I'll wait until someone explains their semantics, or points me at documentation. If these are indeed dynamically scoped, then we need to ask whether they are a good idea. ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

8 28

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Squeak-e February 2003