Dave --

An assignment is on a different metalevel than a function call because the former has side-effects (which could possibly change many subsequent computations) and the latter doesn't. I think of an assignment statement as being like (re)defining possibly many functions -- it's a good idea to eliminate or confine them as much as possible for most programming. I think of gotos as being at a different metalevel than a procedure call -- likewise they should be eliminated and/or confined, and so forth. The ability to dynamically change the *meaning* of what an instance is, or what inheritance is, is at a different metalevel than simply using current meanings for these. 

A useful example from the murky MetaObject Protocol book is: suppose you decide to build a superHypercard kind of media authoring system in Squeak. You would like to make things as uniform as possible for the end-users, so you would like to have them think about the objects on the screen as being of the same species as much as possible. This leads to an object model that could possibly require hundreds of instance variables used to hold "properties" of the object. But only dozens might be needed for any given object. There are several ways to do this in different systems, including just stuffing them in there. What Gregor and Danny say you should do is to essentially subclass Class Instance and define (say) a hash coding scheme for the access and rebinding of the slots. This constitutes a change of metalevels in that you are dealing with a deep property of your entire system. Their notion is that you should be able to make this metachange in such a way that it can be very efficiently compiled and become a part of the lowest level virtual machine.

This is possible to do in Squeak right now, but it is messy because currently there is no class structure for the lowest level objects and very little modularity in the VM simulation definition -- but there could be and will be.

Another interesting example of metacontrol might be in the area of trying to enforce the meanings of different polymorphisms. For example, in Squeak there is a convention to make many methods (e.g. "print") polymorphic over all classes. But in fact Squeak allows you to define a (say) print method on any class that will do anything but print if you so choose. One really old topic that I and others have written about for decades is the notion of having classes for at least some of the methods. For example, you could imagine a Class Print whose instances are *methods that try to print*, and only allow the programmer to specify a limited number of options that don't violate "printability" for the classes they belong to. These "slot" classes are useful in many contexts including multiple inheritance (what should system do if several e.g. print methods are to be found in the different chains?), overriding a method but trying to retain some of the generic meaning, and all kinds of complex organizations of knowledge (e.g. I have a method called "right" and I want to know what its opposite is -- who knows this? Class Right should and does).

I am still trying to understand this stuff myself, and I don't have a calculus for infallible discovery of metalevels. Most of the answers that seem right I get from imagining a complex system already running, and asking what kinds of changes will lead to what kinds of {results *cross* propagations}. This readily yields up distinctions between (say) function calls and assignment statements.

Re: a Smalltalk balloon for making Art of MetaObject Protocol understandable to the larger world. I know I said it, but I didn't mean it. There is only one Dan Ingalls and it would be a real metalevel error to give the next Smalltalk balloon for anything less than what he has accomplished. However, I would certainly be willing to come up with a bottle of good champagne for such a public service!

Cheers,

Alan

----------

At 5:53 PM -0400 2/28/98, David Farber wrote:
>>But I think a critical point here is that just being able to clone willy-nilly
>>is confusing one metalevel with another -- and here is where I disagree with
>>the "Lieberman" and SELF (what I think of as the LISP, or "data structure")
>>schools of prototypes. I feel it is very important to at some point make a
>>commitment to "kind" (I use this word because better terms like "type" and
>>"class" have already been colonized with too-specific meanings in the computer
>>world). So, while I think that you should be able to do absolutely anything
>>with and to your programming system, I also think there should be "guardians at
>>the gates" when you go from one metalevel to another. E.g. it shouldn't be as
>>easy to change the inheritance chain as it is to send a safe message to another
>>object.
>>
>>     An analogy is that one of the reasons we put in encapsulation and tried to
>>get rid of data structures is because an assignment statement is a different
>>metalevel than a function call, and you just should not be able to do either
>>equally easily. Our initial idea was to at least confine the dangerous
>>assignments while we were learning how not to need them. Obviously, allowing
>>the equivalent of easy assignments to deep structural elements (like
>>inheritance pointers, etc.) is a worse idea. The first Smalltalks also allowed
>>"no overhead" syntax definitions -- it was an integral part of programming.
>>This gave us an easily extensible language on all fronts of syntax, semantics
>>and pragmatics, but turned out to be a bad idea for the same reasons. In
>>Smalltalk-76 we perhaps reacted too much in the opposite direction, and didn't
>>put a more appropriate meta-level in the language for defining syntax -- but
>>the earler way we worked simply led to a tower of Babel.
>
>okay, i am trying to keep up here. how is an assignment on a different
>metalevel than a function call. since you made the assertion, i can
>certainly see where you are headed, but what is critera for a metalevel?
>
>>     But it is really terrible if you just ban such things. That is too
>>moralistic and smacks of the Wirth school of (non)programming. This is why well
>>thought out metasystems should allow the good designer/programmer to have their
>>cake and eat it too. The "Metaobject protocol" by Greg and Danny, et. al., at
>>PARC is an inspiring further advance in what we had done there in the '70s, and
>>it gives some tantalizing insights into what could yet be invented....
>
>you mentioned this book in your oopsla keynote, but i haven't been able to
>get my hands on it. to be honest, i haven't tried that hard to get it
>because you remarked that it was probably only comprehensible to someone
>with an extensive Lisp back ground (which ain't me) and it really needed to
>be rewritten for Object Land at large (for which, i believe, you offered a
>second Smalltalk balloon like the one you gave Dan). so, since *you* read it
>and seemed to get a lot out of it, why don't you clue the rest of us in on
>some of its more salient points and how you think we might be able to
>translate them in squeak (or the next blue thang).
>
>thanks,
>dave
>
>--
>        j. david farber
>    oo architect+mentor
>numenor labs incorporated
>in sunny boulder colorado
>    dfarber at numenor.com
>        www.numenor.com