Lazy Futures

General APL language issues

Lazy Futures

Postby petermsiegel on Thu Aug 13, 2015 4:31 am

I've been going through the documentation related to futures and isolates. It would be really nice to have the ability to choose lazy futures (including those in the same namespace as the caller). This could allow a set of objects whose (time- or space-consuming) values are only calculated as needed, possibly never. I scoured the documentation in vain (it seems) for any flags or even tricks that might allow the (currently-defined) future to wait (or be held) until its value is needed. Of course a real lazy semantics would be useful for many purposes, such as lazy logic, whereby a in a OR b is only executed if b is false (where OR is appropriately defined). [Postscript: I wrote something related to this in 2013 before isolates/futures were implemented. One response was that APL already has the tools in DFNS to handle some of the (simple) cases of LAZY logic; the more complex uses of LAZY FUTURES (most not related to logic, but things like optimization) are clearly useful in other programming languages-- the goal is to demonstrate the point simply, but to argue the usefulness for those more complex cases.]

Any thoughts to considering such extensions? You already have the hooks into the interpreter to determine when a future value is or is NOT needed.

See Wikipedia:
The evaluation strategy of futures, which may be termed call by future, is non-deterministic: the value of a future will be evaluated at some time between when it is created and when the value is used. The computation may be started as soon as the future is created (eager evaluation <-- current Dyalog strategy), or only when the value is actually needed (lazy evaluation <-- very useful addition, but consider use of ISOLATES optional), and may be suspended at partway through, or executed in one go. Once the value of a future is assigned, it is not recomputed on future accesses; this is like the memoization used in call by need.

A lazy future is a future that deterministically has lazy evaluation semantics: the computation of the future's value starts when the value is first needed, as in call by need. Lazy futures are of use in languages whose evaluation strategy is by default not lazy. For example, in C++11 such lazy futures can be created by passing the std::launch::deferred launch policy to std::async, along with the function to compute the value.
petermsiegel
 
Posts: 98
Joined: Thu Nov 11, 2010 11:04 pm

Re: Lazy Futures

Postby Morten|Dyalog on Thu Aug 13, 2015 12:37 pm

Yes, we have thought about this. I have made a semi-serious proposal for a "Schrödinger Operator", denoted ⍰ ("what's in the box?"):

Code: Select all
      cats←{(?2)⊃'alive' 'dead'}⍰¨10⍴0
      ⍴cats   ⍝ an array of 10 lazy futures
10
      cats[2] ⍝ Only gets evaluated when you need the result
alive

Don't hold your breath (but on the other hand, as you point out, we have all the hooks already :-)).
User avatar
Morten|Dyalog
 
Posts: 409
Joined: Tue Sep 09, 2008 3:52 pm

Re: Lazy Futures

Postby petermsiegel on Thu Aug 13, 2015 3:32 pm

Very elegant, and simple. Would be very nice (IMHO) to integrate lazy and non-lazy futures or otherwise systematize the (current) isolate/future constructs, which may have the power, but not the elegance, required.

Might be worthwhile collecting examples where these constructs are useful, noting that most programming languages didn't have them until recently (except those whose raison d'etre is to provide them elegantly).

Thanks again.
petermsiegel
 
Posts: 98
Joined: Thu Nov 11, 2010 11:04 pm


Return to Language

Who is online

Users browsing this forum: No registered users and 1 guest