String representation of an actor

[Christopher Lemmer Webber]

Hello,

I'm recently refactoring my Goblins actor model library for Racket to
borrow many of the good ideas from E. One of the things I've done is
add something like E's "miranda rights", including the printed
representation, but one thing that I've been wondering about is... does
E make an exception for non-blocking or something in its representation
of strings?

For example, if I wanted to do:

printLn("This actor's name: " + thisActor)

This looks weirdly synchronous to me, given that this should work for
even remote actors. What if that actor is being unresponsive? Wouldn't
that block the whole vat? Is there something I'm missing?

Thanks,
- Chris

[Mark Miller]

Hi Christopher,

I just tried it in E for a local unresolved promise and it prints

    This actor's name: <Promise>

There's no special case for strings, and E never blocks waiting for a remote interaction. Rather, any synchronous interaction with an unresolved or a remote reference is an interaction only with the reference, not what it is a reference for. If the interaction is not one supported by such a reference, then it still synchronously concludes using only immediately available information, but concluding with an error. All immediate calls to the reference (r.foo()), even of a Miranda method, conclude immediately with an error, since an immediate call is *about* the object designated by the reference which is not synchronously available. Rather, the string protocol expression above bottom out in methods that operate on the reference from the outside, to talk about the ref rather than the object it designates.

http://www.erights.org/javadoc/org/erights/e/elib/ref/Ref.html#state(java.lang.Object)

http://www.erights.org/javadoc/org/erights/e/elib/prim/E.html#toString(java.lang.Object)

http://www.erights.org/javadoc/org/erights/e/elib/oldeio/TextWriter.html#print(java.lang.Object)

The exception I regret, that E got wrong but Midori got right, is that E's Miranda __whenMoreResolved and __whenBroken should only be about references, never about the objects those references designate. However, in E, the designated object will receive these messages and has the freedom to respond inappropriately.

By contrast, E got right the Miranda __reactToListClient, even though it is about references, not about objects. In this case, it is a message sent from the reference system to the designated object. It is never a request to the reference, and therefore has no such ambiguity.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To post to this group, send email to cap-...@googlegroups.com.
Visit this group at https://groups.google.com/group/cap-talk.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87bm8d21kd.fsf%40dustycloud.org.
For more options, visit https://groups.google.com/d/optout.

[Kevin Reid]

On Mon, Oct 1, 2018 at 8:00 AM Mark Miller <ma...@agoric.com> wrote:

I just tried it in E for a local unresolved promise and it prints

    This actor's name: <Promise>

There's no special case for strings, and E never blocks waiting for a remote interaction. … Rather, the string protocol expression above bottom out in methods that operate on the reference from the outside, to talk about the ref rather than the object it designates.

In my E development experience, I concluded that it would be good to have, as an option, a way to print structures containing far references (rather than having to dig out the reference and do <- __printOn directly). I believe this is feasible, given attention to how the output stream works, but keeping the ability to break cycles, while not revealing actual access to every reference to the caller, is a problem I did not think up a complete well-defined solution to.

[Mark Miller]

What does Monte do?

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To post to this group, send email to cap-...@googlegroups.com.
Visit this group at https://groups.google.com/group/cap-talk.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANkSj9VuB3X8fxX%2BxZcdvNLbo5ATUgnWfCKzjL_e_ZZ9eeCoLA%40mail.gmail.com.

[Allen Short]

On Mon, Oct 1, 2018 at 3:18 PM Mark Miller <ma...@agoric.com> wrote:

What does Monte do?

Exactly the same as E, currently. We haven't finished our network layer so this hasn't come up in practice.

I should note that we've adopted E's reference mechanics and would be interested in exploring an improved version -- do you have any thoughts on what a replacement for whenMoreResolved/whenBroken would look like in the context of an E-like language?

[Christopher Lemmer Webber]

Aha, this is really useful, thank you!