Hi allen

do you have some papers that present the Digitalk approach (besides 
Modular ST)?
So that we can learn, digest, and recreate ;)

Stef


On jeudi, décembre 12, 2002, at 09:59  pm, Allen Wirfs-Brock wrote:

> At 09:26 AM 12/12/2002 +0100, Nathanael Schärli wrote:
>> ...
>> Nevertheless, I see that while developing and experimenting with such 
>> a
>> conceptual model, it would often be nice if the VM would already 
>> provide
>> more flexibility, even if this additional power would be accessible 
>> from
>> the image-level in a rather ad-hoc way.
>>
>> Nathanael
>
> I'm making my contribution to this thread off of Nathanael posting 
> because his points seems closest to my perspective on these issues. 
> So, here are my two bits worth.
>
> I think it is a mistake to think of the language and "virtual machine" 
> as a single tightly couple unit.  Instead you want to have a number of 
> layered abstractions which collectively implement your language(s).  
> Each layer has a specific purpose and should ideally only interact 
> with its neighboring layers. The design and implementation of each 
> layer can be optimized for its specific purpose. If you design the 
> lower layers of this tower carefully then you will have much 
> flexibility in supporting differing languages or language semantic 
> variations in the upper layers.
>
> Here is a cut at identifying a set of such layers starting from the 
> "highest" and proceeding to the "lowest".  Next to each I have 
> identified elements of a typical Smalltalk implementation that 
> conceptually fit into each layers
>
>         Language Specification (the ANSI Smalltalk standard, the 
> specification the syntax and sematics of Smalltalk programs)
>         Language Specific MOP  (objects modeling classes, metaclass, 
> methods, etc. bytecode compiler, etc.
>         Language Independent Object Execution Model  (the bytecode 
> instruction set,  contexts, closures, continuations, object structure, 
> etc.)
>         Execution Engine        (bytecode interpreter and/or jitter, 
> memory manager, etc.)
>         Host ISP Architecture   (your favorite microprocessor)
>
> You get a more rigid, less flexible, system when a layer knows too 
> much about other non-adjacent layers.  An example of this would be an 
> Execution Engine that knows it is specifically implementing ANSI 
> Smalltalk (or Smalltalk-80/Squeak or Self) and hence contains design 
> decisions based upon that knowledge. If you change the language in a 
> way that invalidates those decisions then the system won't work. This 
> sort of undesirable cross layer coupling works both ways, if your 
> language specification requires that the execution engine work in a 
> specific way then it will be very difficult to innovate at the 
> Execution Engine layer. It is very easy to blur these layers and 
> create such couplings when you are building a system, as a unit, to 
> support a single specific language.  This has tended to be the case 
> for most Smalltalk implementations.
>
> One way to design such layers is to focus on each layer's role and 
> what it provides to its immediately adjacent layers. Here is a closer 
> look at the three middle layers above.
>
> Language Specific MOP: Provides a language specific object model that 
> can be used to represent and manipulate programs and their runtime 
> state for some specific language. Translates such programs to/from the 
> Execution Model.
>
> Language Independent Object Execution Model: Provides a set of runtime 
> abstractions that can be used to represent programs in a variety of 
> object-orient languages. The runtime abstraction need be sufficient 
> for modeling the runtime semantics of all hosted language (this 
> mapping is performed by the MOP layer). The runtime abstractions also 
> need to efficiently implementable by the Execution Engine.
>
> Execution Engine: Animates the Object Execution Model by translating 
> its runtime abstractions to/from data structures and executable code 
> for some specific host ISP
>
> The issues that have been discussed in this thread, largely relate to 
> the Execution Model layer. The Squeak/Smalltalk-80 instruction set has 
> a very specific  runtime abstraction ("Superclass lookup") for message 
> binding.  This abstraction assumes a very specific set of language 
> semantics and a single very Smalltalk-80 specific MOP.  The Digitalk 
> Execution Model was "better" because it's runtime abstraction for 
> message binding was more general and less dependent upon a specific 
> MOP. It supports multi-level lookup without introducing or requiring 
> the language specific concept of superclass. However, the Digitalk 
> Execution Model had plenty of other "unnecessary" cross layer 
> dependencies.
>
> One specific recommendation I have is that if you want a system that 
> is going to be flexible enough to implement a variety of languages or 
> to implement alternative language semantics then your Execution Model 
> probably needs to separate the operations for "message binding" from 
> "method invocation". You also need a very flexible primitive binding 
> mechanism that is also easy to implement efficiently by Execution 
> Engines. The Digitalk object-specific "array of bindings" is a pretty 
> good starting point for thinking about such binding mechanisms.
>
> Allen_Wirfs-Brock at Instantiations.com
>
>
>
Dr. Stéphane DUCASSE (ducasse at iam.unibe.ch) 
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do
  different? ... especially if, by doing something different, today
  might not be your last day on earth" Calvin&Hobbes