Re: Question about E's history.

Agreed. The larger islands of sequential programming in E were quite a
benefit for many kinds of programming,and is probably the key insight in teh
E computational model. A straightforward interpretation of "coarse-grained
actor" would have multiple capabilities into the shared state of the
"actor". The important addition is that, in a vat, the set of
capabilities available from outside the vat to the state in the vat can
change dynamically. Thus, I think of is as a worthy alternative to
fine-grained actors models.

On Sun, Jun 12, 2011 at 6:17 AM, Tom Van Cutsem <[email protected]> wrote:

> Yes, the notion of a "vat" as a container of objects is definitely another
> one of E's distinguishing features. Your observation that a vat corresponds
> to a classical actor is correct, which is why we ended up calling vats
> "actors" in AmbientTalk (in hindsight, we probably should have sticked to E
> terminology).
>
> The notion of a "vat" as a container of objects is in itself not novel.
> This was also a feature of what I have come to call the school of "active
> object" languages. Denis Caromel's "ProActive" middleware for Java (and
> prior to that, his Eiffel// extension to Eiffel), and Varela and Agha's
> "Salsa" extension to Java are good examples of this. In active object
> models, one typically distinguishes "active" from regular, or "passive"
> objects: the active objects have their own message queue, and their behavior
> is typically composed of passive objects.
>
> What sets apart the E vat model from these models is that in E, one can
> individually designate the objects internal to a vat from outside the vat.
> In active object models, external objects can only designate the active
> object as a whole, never one of its internal objects (just like in Erlang,
> one can only ever reference a process Pid, never a data structure internal
> to a process).
>
> The beauty of the E vat model as opposed to e.g. the Erlang model, as I
> once heard Mark explain it, is that internally, each vat can use traditional
> imperative OOP to build more complex abstractions with ease, such that one
> only has to deal with asynchrony and distributed computing issues when it is
> strictly necessary to do so. By contrast, in Erlang, the notion of mutable
> state is intimately tied to concurrent processes (one typically encapsulates
> individual mutable data structures inside a single process), so that one
> necessarily must think about issues of concurrent programming even for what
> ought to be a simple, local data access. AFAICT, this is an important
> software engineering argument that has hitherto been insufficiently
> articulated by proponents of the vat/communicating event loops model.
>
>

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang