A Challenge Problem for Promise Designers (was: Re: Futures)

Mark Miller erights at gmail.com
Thu Apr 25 11:18:41 PDT 2013


That's a good point. Neither the E language nor the Q library allow
subclassing of promises. The motivating reason in both cases is the
security properties that promises must provide. But you're right -- this is
an additional benefit. Promises/A+, being a minimalistic codification of
broader agreement, neither prohibits nor demands subclassing.

Both the E language and the Q library instead provide extension mechanisms
other than subclassing[1] which are carefully designed so that such
extended promises cannot violate the promise security properties. These
extension mechanisms are sufficient to create lazy promises -- promises
that compute their resolution of demand, and of course remote objects. This
is how we keep the distributed object system out of the promise foundations
itself, and instead build it as a layer on top.


[1] <http://wiki.erights.org/wiki/Proxy#makeProxy>
the explanation of E's makeProxy on page 10 of <
http://research.google.com/pubs/pub36574.html>
<https://code.google.com/p/es-lab/source/browse/trunk/src/ses/makeQ.js#410>



On Thu, Apr 25, 2013 at 10:28 AM, Kevin Smith <zenparsing at gmail.com> wrote:

> I think flattening is also tied inextricably to the fact that promises are
> a featureless wrapper for values.  Nobody cares about promises-as-values
> because of this featureless-ness.  And because they are completely
> uninteresting as values, programmers can think "straight through" to the
> eventual value.
>
> This is highly simplifying for the programmer, especially in the context
> of complex asynchronous data flows.  It is a valuable property and in a
> sense resembles a pure, universal currency.
>
> This suggests a warning:  if we admit promise subclassing (in which
> subclasses have extra features, such as cancel-ability), then this useful
> property goes away, and with it flattening.
>
> { Kevin }
>



-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130425/31ef2a9d/attachment.html>


More information about the es-discuss mailing list