Thinking with Lazy Evaluation • Hacker News Board

Re: Thinking with Lazy Evaluation

#21

Post by codygman » Thu, Jun 18, 2015, 9:00 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.

> Perhaps one of javascript's derivative languages could come up with some syntax to make using this more intuitive

You might want to checkout purescript, which I'm pretty sure uses Monads to make stream interaction intuitive. No time for an example, but I believe there is one somewhere in the Purescript book[0].

0: https://leanpub.com/purescript/read

Re: Thinking with Lazy Evaluation

#22

Post by codygman » Thu, Jun 18, 2015, 9:03 PM UTC

BlanketLogic wrote: post #20

LukeHoersten wrote: post #17

Earlier quoted context omitted.

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.

As I understand it in the Haskell community right now.

1. Pipes | Conduit

2. io-streams (perhaps not in 1 only because of a lack of popularity and it is new)

3. Iteratees (have some issue Pipes/Conduit do not which I can't recall)

Not sure where Machines comes in here.

Re: Thinking with Lazy Evaluation

#23

Post by tome » Fri, Jun 19, 2015, 2:06 PM UTC

dmytrish wrote: post #19

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.

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…

> It is (literally) "non-strict" and that means that it intersperses both modes.

That's not actually what "non-strict" means. https://wiki.haskell.org/Lazy_vs._non-strict

Re: Thinking with Lazy Evaluation

#24

Post by LukeHoersten » Sun, Jun 21, 2015, 5:38 PM UTC

codygman wrote: post #22

BlanketLogic wrote: post #20

Earlier quoted context omitted.

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.

As I understand it in the Haskell community right now. 1. Pipes | Conduit 2. io-streams (perhaps not in 1 only because of a lack of popularity and it is new) 3. Iteratees (have some issue Pipes/Conduit do not which I can't recall) Not sure where Machines comes in here.

io-streams is built specifically for IO and is in the IO monad. This allows for performance benefits as well as simplified API like using normal IO functions for error and resource handling (ex: `bracket` can be used)

Re: Thinking with Lazy Evaluation

#25

Post by anon4 » Wed, Jun 24, 2015, 10:24 AM UTC

One thing that bothers me is, can I rely on the compiler making those optimisations? Which ones are guaranteed for me? Those are sort of important considerations, because it can mean the difference between a linear fibs and a quadratic fibs, or an O(nlogn) sort and a O(n²) sort.