5 ms·

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-stric

by tome 11y ago

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.

agumonkey 11y ago
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.
- jessaustin 11y ago
  ...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.
  - agumonkey 11y ago
    Right any streams. Also this https://github.com/dominictarr/pull-stream#transparent-backpressure--laziness https://github.com/dominictarr/pull-stream#transparent-backp... article says reducers are related too.
  - buttproblem 11y ago
    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 http://www.cse.chalmers.se/~rjmh/Papers/arrows.pdf [2] http://haskell.cs.yale.edu/?post_type=publication&p=112 http://haskell.cs.yale.edu/?post_type=publication&p=112
  - codygman 11y ago
    > 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 https://leanpub.com/purescript/read
- tome 11y ago
  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.
- dmytrish 11y ago
  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.
  - tome 11y ago
    > 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 https://wiki.haskell.org/Lazy_vs._non-strict

by tome 11y ago

agumonkey 11y ago

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.

jessaustin 11y ago
...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.
- agumonkey 11y ago
  Right any streams. Also this https://github.com/dominictarr/pull-stream#transparent-backpressure--laziness https://github.com/dominictarr/pull-stream#transparent-backp... article says reducers are related too.
- buttproblem 11y ago
  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 http://www.cse.chalmers.se/~rjmh/Papers/arrows.pdf [2] http://haskell.cs.yale.edu/?post_type=publication&p=112 http://haskell.cs.yale.edu/?post_type=publication&p=112
- codygman 11y ago
  > 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 https://leanpub.com/purescript/read
tome 11y ago
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.
dmytrish 11y ago
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.
- tome 11y ago
  > 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 https://wiki.haskell.org/Lazy_vs._non-strict