HLL Process Model

[Jecel Mattos de Assumpcao Jr.]

On Sat, 11 Mar 95 2:06:35 MET Francois-Rene Rideau wrote:
> Jecel said:
> > Maybe Occam should be added to the list of languages to study.
>    I just added it. But there already are lots of languages to review.
> Yow. There's a lot of work. Perhaps you could send me your reviewing ;) ?

I've just asked Byte Brasil permission to publish my articles
"Why Objects?" and "What is the Best Language?" on the net. When
that is done you can just point to them :-)

> > My current idea is to give users "accounts" with a certain credit flow.
> > You can spawn more processes, but they will share the same account and
> > won't be able to hog all of the CPUs in the system.
>    To me, the system shall not provide any finite system of resources.
> There should be a generic way to multiplex and share resources. Users may
> then be able to multiplex and share their own share, etc, recursively,
> indefinitely. Else, there will always be problems, because if you can't
> multiplex, it means you've got a security hole. This is why POSIX is bullshix:
> no generic multiplexing, only specific, finite one.

I am not sure I understand. Computer resources are not continuous. How
can you multiplex indefinately? This is very obvious with things like
a modem+a single phone line, for example, but is valid even for disk
space and CPu time. How do you achieve fairness among the users?

>    Yes we should be able to share objects. That's one of the basic concepts
> in publishing. We sure shall allow users to publish things, shouldn't we ?
>    Now, perhaps you are suggesting that linear programming (not sharing
> anything) is an efficient way to implement programs. Then, I'll say that
> high-level objects should be shared, whereas the system may compile them
> into linear programming if it can, when it does compile...

I am for sharing too. I was just asking to understand what "cells"
mean. I am not convinced linear programming helps at all.

> > If you do object composition by "enclosing", how do you share things?
> > Or am I missing something here?
>    I'm not sure what you (Jecel) mean...
> What's the problem with sharing particularly denoted to what Chris is saying ?
> Sure, sharing is a problem, but I think it's orthogonal to what Chris was
> saying.

I understood "enclosing" to mean that a cell's memory is the sum of
the memories of its subcells - that a cell directly contains its
subcells rather than just pointing to them. This makes sharing
impossible. Again, it was just a matter of me trying to clear up
terminology.

> > I have done so in Merlin: one object = one process ( except when
> > they are not :-). This model is close to the real world where each
> > component works in parallel with all of the rest. I have to allow
> > some exceptions for performance ( immutable objects can have many
> > processes ) and for compatibility with sequential code ( recursion
> > would always deadlock otherwise ).
>    Recursion would not deadlock if you distinguish internal message send
> and external message send, the first one having priority. The functional
> and continuation passing view also clarifies many things as compared to
> the fashionable OO view that gets confused about object identity: you're
> not sending the message to the *same* object, but to another one, as you
> must take the state into account as for object identity...

This is the actor model, isn't it? It doesn't avoid the performance and
deadlock problems directly, but makes you state things explicitly so
you can see the problems and solve them manually.