Thinking with Lazy Evaluation • Hacker News Board

Re: Thinking with Lazy Evaluation

#11

Post by jessaustin » Thu, Jun 18, 2015, 3:07 PM UTC

agumonkey wrote: post #10

tome wrote: post #9

Earlier quoted context omitted.

That sounds like a good intuition to me. Strict is like push, because it gives you the result as soon as it's ready. Lazy (or perhaps more precisely non-strict) is like pull because you have to go and ask for the result.

Yes, and after years of struggling to find which should prevail, I recently heard the term of backpressure (used in reactive GUI IIRC) to be able to reason about things in both direction. Is there a middle ground for evaluation strategies ? Right now one can for strictness (in Haskell) or lazyness (in ml) but I never found a 'theory' about both.

...backpressure (used in reactive GUI IIRC)...

And unix pipes, and node.js streams...

Your intuition about a middle ground is interesting. Perhaps one of javascript's derivative languages could come up with some syntax to make using this more intuitive, because let's face it node.js streams would be easier to use if there were some way of plumbing them together that didn't look like Java from 1999.

Re: Thinking with Lazy Evaluation

#12

Post by dllthomas » Thu, Jun 18, 2015, 3:09 PM UTC

BlanketLogic wrote: post #5

Nice. But Laziness with I/O is not trivial at all.

That's true. An obvious solution is "keep IO out of your lazy computations", which hopefully you can get some language help with. There are some attempts at other approaches as well.

Re: Thinking with Lazy Evaluation

#13

Post by agumonkey » Thu, Jun 18, 2015, 3:18 PM UTC

jessaustin wrote: post #11

agumonkey wrote: post #10

Earlier quoted context omitted.

Yes, and after years of struggling to find which should prevail, I recently heard the term of backpressure (used in reactive GUI IIRC) to be able to reason about things in both direction. Is there a middle ground for evaluation strategies ? Right now one can for strictness (in Haskell) or lazyness (in ml) but I never found a 'theory' about both.

...backpressure (used in reactive GUI IIRC)... And unix pipes, and node.js streams... Your intuition about a middle ground is interesting. Perhaps one of javascript's derivative languages could come up with some syntax to make using this more intuitive, because let's face it node.js streams would be easier to use if there were some way of plumbing them together that didn't look like Java from 1999.

Right any streams. Also this https://github.com/dominictarr/pull-stream#transparent-backp... article says reducers are related too.

Re: Thinking with Lazy Evaluation

#14

Post by cpursley » Thu, Jun 18, 2015, 3:24 PM UTC

Neat. If you're a Ruby developer check out rlet - a rspec-like let for lazy evaluation:

http://github.com/hosh/rlet

Re: Thinking with Lazy Evaluation

#15

Post by buttproblem » Thu, Jun 18, 2015, 3:26 PM UTC

jessaustin wrote: post #11

agumonkey wrote: post #10

Earlier quoted context omitted.

Yes, and after years of struggling to find which should prevail, I recently heard the term of backpressure (used in reactive GUI IIRC) to be able to reason about things in both direction. Is there a middle ground for evaluation strategies ? Right now one can for strictness (in Haskell) or lazyness (in ml) but I never found a 'theory' about both.

...backpressure (used in reactive GUI IIRC)... And unix pipes, and node.js streams... Your intuition about a middle ground is interesting. Perhaps one of javascript's derivative languages could come up with some syntax to make using this more intuitive, because let's face it node.js streams would be easier to use if there were some way of plumbing them together that didn't look like Java from 1999.

I don't know node, but, conceptually, Arrows [1] map to the steam concept very well (as always in Haskell, they are more general). The sugar in Haskell to use them similar to do-notion is really a joy to use.

I was exposed to them in the Haskell music library Euterpea in the Haskell School of Music [2]. The signal processing API uses arrows.

[1] Generalizing Monads to Arrows. John Hughes. http://www.cse.chalmers.se/~rjmh/Papers/arrows.pdf

[2] http://haskell.cs.yale.edu/?post_type=publication&p=112

Re: Thinking with Lazy Evaluation

#16

Post by tome » Thu, Jun 18, 2015, 3:29 PM UTC

agumonkey wrote: post #10

tome wrote: post #9

Earlier quoted context omitted.

That sounds like a good intuition to me. Strict is like push, because it gives you the result as soon as it's ready. Lazy (or perhaps more precisely non-strict) is like pull because you have to go and ask for the result.

Yes, and after years of struggling to find which should prevail, I recently heard the term of backpressure (used in reactive GUI IIRC) to be able to reason about things in both direction. Is there a middle ground for evaluation strategies ? Right now one can for strictness (in Haskell) or lazyness (in ml) but I never found a 'theory' about both.

There have been some theoretical unifying attempts such as Paul Levy's "Call By Push Value" and more recently this

    http://arxiv.org/abs/1504.07680

But I haven't found anything particularly satisfying from the practical point of view.

Re: Thinking with Lazy Evaluation

#17

Post by LukeHoersten » Thu, Jun 18, 2015, 3:46 PM UTC

BlanketLogic wrote: post #5

Nice. But Laziness with I/O is not trivial at all.

Haskell has some great solutions for lazy IO: io-streams or pipes for example. Check them out! It's a great way to code IO.

Re: Thinking with Lazy Evaluation

#18

Post by jmount » Thu, Jun 18, 2015, 3:46 PM UTC

R has lazy evaluation (but only at function arguments). That makes it an easy place to play with some of the effects of lazy evaluation (but not get too bogged down with issues like IO).

Re: Thinking with Lazy Evaluation

#19

Post by dmytrish » Thu, Jun 18, 2015, 4:06 PM UTC

agumonkey wrote: post #10

tome wrote: post #9

Earlier quoted context omitted.

That sounds like a good intuition to me. Strict is like push, because it gives you the result as soon as it's ready. Lazy (or perhaps more precisely non-strict) is like pull because you have to go and ask for the result.

Yes, and after years of struggling to find which should prevail, I recently heard the term of backpressure (used in reactive GUI IIRC) to be able to reason about things in both direction. Is there a middle ground for evaluation strategies ? Right now one can for strictness (in Haskell) or lazyness (in ml) but I never found a 'theory' about both.

Actually, Haskell is not a completely lazy language. It is (literally) "non-strict" and that means that it intersperses both modes.

GHC tries to do its best with its strictness analyzer; it looks it works in many simple cases, still blowing up in non-trivial places, producing space leaks. Although I must say that space leaks may be very well produced by a redundant strictness and people who want strictness by default seem a bit luddistic to me.

My ideal language (or rather its compiler/runtime) would do complete analyses of what strategy suits each part of the program. By the way I'm a little surprised by Haskell insistence on static analysis, disregarding tracing VM and automatic run-time profiling.

Re: Thinking with Lazy Evaluation

#20

Post by BlanketLogic » Thu, Jun 18, 2015, 4:38 PM UTC

LukeHoersten wrote: post #17

BlanketLogic wrote: post #5

Nice. But Laziness with I/O is not trivial at all.

Haskell has some great solutions for lazy IO: io-streams or pipes for example. Check them out! It's a great way to code IO.

Yes. Conduits and iteratees too, for that matter. And I believe, there was some talk about "Machines", which I did not understand at all. Am not sure what is the current status of that approach.

I thought conduits and io-streams are preferred over pipes.