[cap-talk] Last Call for ref_send API 1.0

[Dean Tribble]

On 4/3/07, Tyler Close <tyler.close at gmail.com> wrote:
>
> On 4/2/07, Dean Tribble <tribble at e-dean.com> wrote:
> > I'm delighted that Facet does not apear in the API :-).
> The Struct name also came from you via MarkM, since you talked about
> using C# structs to do something similar.


What does "Struct" here refer to?

> Closure is a very common concept that is only loosely reflected it the
> > decalred interface.
> Errr.. "only loosely". Please explain.


Closures are not generally restricted to a one argument, and generally
contain a pair of a function and an environment.  This Closure reflects
neither the typical closure interface (in which different closurs have
different signatures) nor does it implement any typical closure behavior.
All it does is define a signature for a single-argument function (which may
or may not be implemented to close over anything).  The concepts are
related, but only loosely.  Delegates in C#, for example, are much closure
to traditional (e.g., Scheme) closures.  There's a fair bit of discussions
about adding closure support to Java, which would add to the confusion if it
ever happens.

>  I have a vague recollection that Java has an existing
> > variant of Runnable that might do.
> Nothing that I'm aware of.


I was remembering OneArgFunc from E.

> As for "Channel"...!  Just returning a struct of a Promise and a Resolver
> is
> > a pretty measly purpose for polluting the term "Channel"!


I should note that my objection is as much for entertainment value as
anything else.  It's plausible to refer to the Waterken communication
construct as a channel.  I think it is a waste and will lead to confusion to
apply it to a itiny struct that just carries a promise and resolver that
actually implement a channel.  When you refer to a channel in discussion,
how confusing will it be to refer to the Channel pair as opposed to the
channel with interesting communication semantics?


> Actually, I think this "Channel" corresponds well to a Joule channel.


Joule Channels are distinguished by their comunication semantics (partial
order, cdr on receiver, etc.).  In small kernel architectures, such
differences are significant.  Communications in Waterken has a fundamenally
different semantics.


> The defer() method happens to create a channel that can be resolved
> only once. I believe MarkM is working on an implementation that
> returns a channel that can be resolved more than once, like Joule's
> channel.


I'm not sure what point you are trying to make.  Linda tuple-spaces, FCP
logic variables, Erlang ports are all equally similar from that level of
abstraction. For such abstractions, what you cannot do is often more
important than what you can do.

As for polluting the term. Joule channels don't even rate a mention on
> the Wikipedia page about channels:


OK now you are just being mean! :)  I should it's true spend more time on
self-promotion....

The org.ref_send.promise.eventual.Channel corresponds well to the
asynchronous channel documented on that Wikipedia page.

The waterken channel concept might.  The class as defined, however, is just
a hack that Java needs because it doesn't support multiple return values.
In other languages it's entirely unecessary.  The "Channel" class provides
no semantics or implementation.  If you were to follow other Java practice
of having either an array or a mutable cell object representing an out arg,
you would not need a class representing the pair at all.

>  I think the
> primary reason for that is the lack of multiple return values.  If so,
then
> just defining Pair<T,U> would allow that pattern to appear in multiple
> places without needing to define a new term for every occurrence.

This would hurt code readability. Take a look at the async AND
implementation at:

http://waterken.sourceforge.net/javadoc/src-html/org/ref_send/test/Logic.html#line.50

...   answer.resolver.resolve(false);

Ah yes.  This reminds me that the pattern of having a container object has a
(possibly minor) GC issue: the closure on line 55 retains a pointer to the
resolver *and* the promise, even though it shouldn't need the promise.  This
pattern impedes detecting dropped promises, which for example could enable
various interesting optimizations in a comm system.

Resolvers are almost sufficient to make this problem go away.  They can be
set up to single-assign their promise.  That has occasionally turned out to
be convenient:

static public Promise<Boolean>
        and(final Eventual _, final Promise<Boolean>... condition) {
            if (0 == condition.length) { return ref(true); }
            final Resolver<Boolean> answerR = Resolver.make();
            final Promise<Boolean> answer = _.defer(answerR);
            final Slot<Integer> todo = var(condition.length);
            for (final Promise<Boolean> test : condition) {
                class AND extends Do<Boolean,Void> implements Serializable {
                    static private final long serialVersionUID = 1L;
                    public Void
                    resolve(final Boolean value) {
                        if (value) {
                            todo.put(todo.cast() - 1);
                            if (0 == todo.cast()) {
                                answerR.resolve(true);
                            }
                        } else {
                            answerR.resolve(false);
                        }
                        return null;
                    }
                    public Void
                    reject(final Exception e) {return answer.resolver.reject
(e);}
                }
                _.when(test, new AND());
            }
            return answer;
        }

I think the above is a better psatten than the other direction:

            final Resolver<Boolean> answerR = _.defer();
            final Promise<Boolean> answer = answerR.promise();

and than what is currently there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070404/8b5e2d88/attachment.html