HLL Process Model

[Francois-Rene Rideau]

Jecel said:
> 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.

Well, as always, I really think we should let the objects be free to
decide what kind of context they will run in, let the implementors choose
what kind of paradigm to use, and build generic wrappers that translate
one paradigm into the other (e.g. repeaters are x->1 -> x->m; queuers are
m->x -> 1->x; restricting many to be one being left as an exercise ;).
   As usual, those wrappers will be automatically invoked when an object
using one paradigm interfaces an object using one another.



> 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.

   For both efficiency and security reasons, I say it must possible
to statically bind attributes.


> 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.

   Yes, we must be careful about vocabulary. I guess the LLL maintainer
(when there be) will have the last word, unless it's the HLL one (that's
me, and I prefer use the words objects and modules).



> 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.

Right, it must be clearly settled. However, I say let it be settled
objectwise, and not systemwise; let the implementors choose whichever
paradigm they prefer (different implementors may choose different
paradigms). To begin with, I'd choose the ones that match the hardware
in the simplest way (i.e. one-to-one); but we sure should eventually have
efficient many-to-many support one day (i.e. before version 2.0).