Re: Question about E's history.

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.

Kind regards,
Tom

2011/6/12 Constantine Plotnikov <[email protected]>

> This actually leads to question about origins of another idea that I
> learned from E.
>
> In E, several asynchronous components could share single event loop.
> Because of this, the components are relatively cheap. In most other actor
> model implementations, each component has own inbox and messages in it could
> be retrieved in actor dependent order (for example priority messages could
> be dispatched first).
>
> When implementing AsyncScala and other implementations of E ideas, I have
> noticed that it would be almost impossible to implement sane asynchronous
> operation composition DSL without transparent sharing local event loop like
> it was done in E. Local event loop provides context where memory could be
> safely shared. In fact, the entire E Vat corresponds to classical actor.
>  The E objects are in fact some kind of sub-actor. And this makes
> designating event handler trivial.
>
> This idea is not uncommon to computer science. The GUI event loop
> implements this idea to compose handlers for incoming events. Just imagine
> how GUI event loop looked, if it was a single Erlang actor. Actually many
> Java programs that I have seen use AWT event loop to organize safe
> interactions of components (for example, IntelliJ IDEA uses GUI event loop
> to coordinate writes to file system through its virtual file system layer).
> When something should be done with shared component either inovkeLater or
> invokeAndWait is called.
>
> It would be interesting to know how this idea of Vat comes to E. I'm also
> interested whether there are other Actor model implementations (that declare
> that they such) where asynchronous components could share single event loop.
>
> Thanks,
> Constantine
>
> On Sun, Jun 12, 2011 at 1:38 PM, Dean Tribble <[email protected]> wrote:
>
>> Some E promise history:
>>
>> E promises derive primarily from Joule channels, by way of the Xanadu
>> promise system. Joule was a massively concurrent programming language that
>> was a deliberate cross between actors and concurrent logic programming
>> languages.  The Xanadu promise system was created by applying Joule channels
>> to a sequential language for pipe-lined, client-server communication. It was
>> contemporary with and independent of the Argus promises system. The E
>> language generalized that to "islands of sequential programming
>> communicating with promises".
>>
>> On Sat, Jun 11, 2011 at 7:47 PM, Jonathan Rees <[email protected]> wrote:
>>
>>>  Is this relevant as precedent? It was pretty well developed by 1984
>>> http://en.wikipedia.org/wiki/MultiLisp
>>> but I don't know how well developed it was regarding pipelining. I
>>> suspect they got the 'promise' idea from Hewitt.
>>>
>>> <http://en.wikipedia.org/wiki/MultiLisp>Jonathan
>>>  <http://en.wikipedia.org/wiki/MultiLisp>
>>> On Jun 11, 2011, at 4:23 PM, Mark S. Miller wrote:
>>>
>>> On Sat, Jun 11, 2011 at 12:01 PM, Tom Van Cutsem <[email protected]>wrote:
>>>
>>>> Hi Constantine,
>>>>
>>>> Having looked at various actor languages, I have not previously
>>>> encountered the type of asynchronous composability that when-expressions
>>>> provide. So E may be the first language to have introduced this feature.
>>>>
>>>> About E's origins: in the paper "Concurrency among strangers", there is
>>>> a section titled "From objects to actors and back again" (section 11) which
>>>> I feel is a good reference to work that inspired E: <
>>>> http://www.erights.org/talks/promises/index.html>
>>>>
>>>> In general, I believe the actor model served as the greatest source of
>>>> inspiration for E: <http://en.wikipedia.org/wiki/Actor_model>
>>>>
>>>> I know from Mark that promises in Liskov's Argus language were also a
>>>> source of inspiration for promises in E.
>>>>
>>>
>>> Not inspiration, but precedence and therefore credit. In 1989, Dean, I,
>>> and others independently came up with a promise pipelining model similar to
>>> Liskov and Shrira's promises as part of the Xanadu (aka Udanax Gold) work <
>>> http://web.archive.org/web/20071023111712/http://www.sunless-sea.net/Transcripts/promise.html>.
>>> Afterwards, we found out about their 1988 paper <
>>> http://portal.acm.org/citation.cfm?idT016>, and so have consistently
>>> given them credit for inventing the idea first, as they did.
>>>
>>> ...
>>>
>>> _______________________________________________
>>> e-lang mailing list
>>> [email protected]
>>> http://www.eros-os.org/mailman/listinfo/e-lang
>>>
>>>
>>
>> _______________________________________________
>> e-lang mailing list
>> [email protected]
>> http://www.eros-os.org/mailman/listinfo/e-lang
>>
>>
>
> _______________________________________________
> e-lang mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/e-lang
>
>

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