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

Andreas Rossberg rossberg at google.com
Fri Apr 26 02:43:35 PDT 2013

On 26 April 2013 10:54, David Bruant <bruant.d at gmail.com> wrote:
> The Priority of Constituencies [1] asks us to be remain careful about
> theoretical standpoints. How does the theoretical part translates into
> helping users? authors (more than what I described at [2] which is derived
> from my own experience)? implementors? specifiers?
> I'm not saying the theoretical benefits don't exist, but I'd like to see how
> they translate in concretely improving my life as a developer using
> promises. I've explained the benefits I see for flattening from the dev
> point of view, I'd like to see the equivalent.

The argument is for regularity. On a global scale, regularity helps
the user, while exceptions, at best, are useful only locally -- an
observation that, unfortunately, is difficult to demonstrate with toy
examples. In particular, irregularity and exceptions become a pain
when you start building abstractions, or plug together abstractions.
In other words, regularity is a prerequisite for what some people
(including me) like to call "compositionality".

Flattening for futures/promises is irregular because it means that
certain behaviour reliably exists in all cases _except_ when the input
is itself a future/promise. This may not seem like a big deal if you
use them directly. But now imagine somebody built a bigger generic
abstraction that uses futures/promises only internally. You find that
abstraction useful, and for whatever reason, need to funnel in a value
that happens to be a future. And for no reason apparent to you the
nice abstraction misbehaves in weird ways.

The nasty thing about lack of compositionality is that it typically
only starts to harm after a while, when people start building more and
more complex systems on top of a feature. But at that point, it's
already too late, and you cannot fix the mistake anymore. Instead what
happens is that more and more exceptions get introduced on top, to
work around the problems created by the first one.

The functional programming community has a lot of experience with
building compositional abstractions. And they have learned to value
regularity very high. (And not entirely coincidentally, that also is
the reason why they value type systems, because those force language
and library designers to stay honest about regularity.)


More information about the es-discuss mailing list