Thinking with Lazy Evaluation
begriffs.com
Thinking with Lazy Evaluation
1–10 of 25 posts
Re: Thinking with Lazy Evaluation
#2FTA: Control flow can be manipulated as data.
That's an interesting perspective, I've never seen it that way before. I would love to learn more about this, as a non-Haskeller.
Re: Thinking with Lazy Evaluation
#3FTA: Control flow can be manipulated as data. That's an interesting perspective, I've never seen it that way before. I would love to learn more about this, as a non-Haskeller.
I see functions as tiny stepping gears and composition as the mental act of assembling these mathematical pieces of geometry.
Re: Thinking with Lazy Evaluation
#4FTA: Control flow can be manipulated as data. That's an interesting perspective, I've never seen it that way before. I would love to learn more about this, as a non-Haskeller.
I see functions as tiny stepping gears and composition as the mental act of assembling these mathematical pieces of geometry.
As far as that goes, you can do it in Lisp or ML, too. But Haskell's lazy evaluation adds a nontrivial twist to it that I haven't fully grokked yet.
Re: Thinking with Lazy Evaluation
#5Nice. But Laziness with I/O is not trivial at all.
Re: Thinking with Lazy Evaluation
#6FTA: Control flow can be manipulated as data. That's an interesting perspective, I've never seen it that way before. I would love to learn more about this, as a non-Haskeller.
“Monads turn control flow into data flow, where it can be constrained by the type system.” Oleg Kiselyov
quoted in the paper "Monads are Trees with Grafting" by Dan Piponi
Re: Thinking with Lazy Evaluation
#7Earlier quoted context omitted.
I see functions as tiny stepping gears and composition as the mental act of assembling these mathematical pieces of geometry.
As far as that goes, you can do it in Lisp or ML, too. But Haskell's lazy evaluation adds a nontrivial twist to it that I haven't fully grokked yet.
I understood Haskell once I internalized the actual purpose of non-strict semantics.
Abstractly your program is a tree rooted at main. In a language like C you concentrate on building trees knowing that you are going to touch every node. So you are trying to design small trees that have good execution semantics as well as being correct in the problem solving domain. You have to address the problem at 2 levels. Because C is strict every function you call will be evaluated before it can return some result.
Haskell is different you can build any tree you like because a node will only be evaluated if its result is required for the current context. You are free to work with models of data like "the integers" or "all possible game states".
Concretely in C if you wanted to find the smallest positive integer that satisfies some property P you would write something like
for (int i=1; ; i++) if (P(i)) return i;
In contrast in Haskell you might do something like
find P [1..]
Applying this simple example, in Haskell you aren't concern with limiting the shape of your program's tree. You build the correct model for your program regardless of constraints like infinite lists or terminating searches early. You just allow non-strict evaluation to process your input data because you will never have to strictly generate an infinite integer list before scanning it.
At root non-strict semantics is just a reversal of the order of reduction of expressions.
Re: Thinking with Lazy Evaluation
#8Earlier quoted context omitted.
As far as that goes, you can do it in Lisp or ML, too. But Haskell's lazy evaluation adds a nontrivial twist to it that I haven't fully grokked yet.
I understood Haskell once I internalized the actual purpose of non-strict semantics. Abstractly your program is a tree rooted at main. In a language like C you concentrate on building trees knowing that you are going to touch every node. So you are trying to design small trees that have good execution semantics as well as being correct in the problem solving domain. You have to address the problem at 2 levels. Becaus…
Am I misguided to think that strict / lazy has some relation between push / pull effects in other systems (GUI, parsing) ?
Beautiful comment btw.
Re: Thinking with Lazy Evaluation
#9Earlier quoted context omitted.
I understood Haskell once I internalized the actual purpose of non-strict semantics. Abstractly your program is a tree rooted at main. In a language like C you concentrate on building trees knowing that you are going to touch every node. So you are trying to design small trees that have good execution semantics as well as being correct in the problem solving domain. You have to address the problem at 2 levels. Becaus…
Am I misguided to think that strict / lazy has some relation between push / pull effects in other systems (GUI, parsing) ? Beautiful comment btw.
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.
Re: Thinking with Lazy Evaluation
#10Earlier quoted context omitted.
Am I misguided to think that strict / lazy has some relation between push / pull effects in other systems (GUI, parsing) ? Beautiful comment btw.
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.