HLL Process Model

[Jecel Mattos de Assumpcao Jr.]

On Sat, 11 Mar 95 2:06:33 MET Francois-Rene Rideau wrote:
> Chris said:
> > The other alternative I have to this is the cell model I proposed.
> > (Remember that these are NOT the same cells that Mike proposed.) The
> > basics of what I said:
> >   -Basic unit of processing is the cell.
>    Ok. That's what I already called object, or module, but cell is shorter.
> 
> >   -Cells are composed of an internal group of sub-cells.
>    Let's say "may", which only says that objects may be organized arbitrarily.
> 
> >   -Cells are connected via one-directional channels.
>    Yup. They are typically called that object function members, or methods.
> Sending the data into the channel is the same as calling the method, or
> sending a message, etc.

If feel I have caused some confusion around here. Fare has assumed that
Chris' cell model is just the plain object model with another name. I
tried not to assume anything and asked a lot of questions to find out
what we were talking about. For all I know, Chris might have been
proposing a static dataflow model for Tunes.

Let's take as an example the "one-directional channels" thing. In
just two dimensions, we have these choices:

Model             Sender             Receiver
-----------------------------------------------
CSP               one                one
RPC               many               one
Linda             many               many

Where CSP is Communicating Sequential Processes, RPC is Remote
Procedure Call ( the "normal" object model is of this type ) and
Linda is another model. Each one has its good and bad points. And
many implications for the rest of the system design.

Objects are linked ( in a very dynamic way ) to others via its
attributes ( or slots or members ). It has fixed number of output
"channels", but the target of these outputs changes at execution
time. On the other hand, it has a single input. I don't know
anything about "cells" and so asked about them as I didn't assume
these restrictions. Sorry if this caused a big confusion over a
small vocabulary mix up.
 
> > Maybe there would be some way to combine processes and objects into
> > one concept, as they have sort of done is BETA.  That'd certainly be
> > neat, but the two are probably seperate enough that it might not be
> > worthwhile.
>    To me, there's no such thing as processes. There are pure objects,
> and objects that contain a state. All objects are accessed through
> methods. Variables are objects that have get and set methods that
> fulfill some algebraic relations. By keeping sending messages to self,
> objects can keep running. There also are resource pools, so that exploding
> objects should not overwhelm stable ones. But again, no need for coarse
> grained process. Let's adapt abstractions to actual computing needs, and
> not adapt habits to stupid arbitrary abstractions.

There *are* many questions to be solved. You can't sweep them under
the rug by saying "no such thing as processes". If an object sends
a message to another, you have to decide if they execute in parallel
with each other or not. If an object received two messages from
different objects, what happens? It is not as simple as it looks.

-- Jecel