Jason Marshall
Sun, 02 Apr 2000 00:10:50 PST

>One thing that I have noticed about myself is that I will speak as if 
>am talking of implementation.  I am not.  I usually talk in terms of 
>apparent model.  This model, technically, has nothing to do with

Interface frequently suggests a default implementation, but rarely
dictates it.

>Function instances (also called Messaging State Machines) are objects
>that are executable.  In C a function instance is the stack space a
>function would use and the space taken for temporary variables.  It
>would not include the executable code, that is a "function"  Please 
> for a better

You've just described a stack frame, or an activation record, yes?

>Function instances, in DBOS, have a single context variable.  A 
>variable is much like a stack except it has a maximum and minimum size
>of one.  I can not seem to get rid of the context variable.  This does
>not bother me anymore.

Care to elaborate here?

>Broadcasting:  What is it?  How should it be modeled?
>Consider yourself an object.  Currently, to get work done, you send
>messages to other objects.  Semantically, I chose:
>	destination Object.MyMessage(Name="Kyle", Age=26);

As I recall, Smalltalk also makes the distinction of treating all 
calls as messages.  This makes some sense when you consider that
the language is dynamically typed, and so you can add or delete 
message handlers (methods/interfaces) at runtime.  I'm not aware of
the multicast mechanism, but my knowledge of the language is limited. 

>Each object has a message queue, and messages can be blocking or non
>blocking. There is no semantic model to distinguish the two yet.

Well, let me ask you this question:  Are you set on implementing this 
at the language level, or is it sufficient to do so in your standard 
That, of course, would clearly semantically differentiate the two, and 
seems to be the path most languages take to achieve multicast 
Of course, the problem there is when you leave a dangling reference to 
logically dead object, so maybe forcing the user to keep a clean 
to objects they want to keep around (instead of relying on an event 
to keep your object live), making things a bit more explicit.  On the 
hand, you still have the issue of needing parallel broadcast paths for 
contexts of information on the same subject.  For instance, if you have
two windows open at once, in the same instance of the application, how 
you prevent destructive cross-chatter?