develooper Front page | perl.perl5.porters | Postings from December 2017

Re: Request For Context - about the 5.22->5.24 context stack rework

Thread Previous | Thread Next
From:
Paul "LeoNerd" Evans
Date:
December 13, 2017 15:30
Subject:
Re: Request For Context - about the 5.22->5.24 context stack rework
Message ID:
20171213153046.0bdd7793@shy.leonerd.org.uk
On Wed, 13 Dec 2017 09:14:54 -0600
David Nicol <davidnicol@gmail.com> wrote:

> this "Future" stuff looks like "promises."

Exactly that, just under a different name. The idea was co-invented in a
number of different contexts, and has different naming between them.
The ideas are equivalent.

> "promises" are still an ascending pattern; Perl, being deeply
> singlethreaded, seems an awkward fit for the pattern outside of an
> explicit concurrency system like POE or such, with its event loop.

Which is why IO::Async, Mojo, POE, (and even AnyEvent) all have support
for Future by way of additional CPAN modules.

> Promises are fundamentally a way to organize a more maintainable
> event-driven control flow.

Supporting the syntax and control flow, is quite separate from being
able to implement the actual concurrency of their semantics. Even
without any form of event-handling layer beneath,
Futures/Promises/whatever can still be very useful in a number of
cases. For example, they can allow a unit test script to implement the
"inside" of a middleware function by playing the role of both caller
and callee to that middleware-under-test. That is quite apart from any
sort of event-driven programming at the OS level.

> Towards supporting promises in core, it seems like "Futures in core"
> could get added on to the threading wish-list.

I had no intention of putting Futures/Promises/whatever into core
itself. That's quite a large subject - much greater than I had in mind
here. All that core would be asked for here, is some help in
implementing the suspend-and-resume deferral semantics around a single
pureperl function, as currently implemented by lots of
internals-gutwrenching code in Future/AsyncAwait.xs

For reference, see the entire top half of this file, up until line 474:

  https://metacpan.org/source/PEVANS/Future-AsyncAwait-0.10/lib/Future/AsyncAwait.xs

most notably, the two functions with signatures

  static void MY_suspendedstate_suspend(pTHX_ SuspendedState *state, CV *cv);
  static void MY_suspendedstate_resume(pTHX_ SuspendedState *state, CV *cv);

Were core perl to provide something of that shape (and I'm not at this
stage requesting that it does - simply illustrating the point here),
then my entire CPAN module becomes just another syntax hook using only
documented APIs and features, and adds the entire concept of
async/await coroutine-style future handling to Perl.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About