Re: [Haskell-cafe] help understanding lazy evaluation

2007-08-23 Thread Ronald Guida
I'm trying to understand lazy evaluation as well. I created an example for myself and I'm wondering if I've got it right. > let adder n = \x -> n + x in (map (adder 12) [1,2,3]) !! 1 So the first thing I did is draw a graph to represent my expression. (map (adder 12) [1,2,3]) !! 1 =

Re: [Haskell-cafe] help understanding lazy evaluation

2007-08-23 Thread Malte Milatz
Stefan O'Rear wrote: > As is usual for mathematical things, there are many equivalent > definitions. My two favorites are: > > 1. Normal order reduction > > In the λ-calculus, lazy evaluation can be defined as the (unique up to > always giving the same answer) evaluation method, which, if *any*

Re: [Haskell-cafe] help understanding lazy evaluation

2007-08-23 Thread Bulat Ziganshin
Hello Xavier, Thursday, August 23, 2007, 3:08:25 AM, you wrote: > I am learning Haskell with "Programming in Haskell" (an excellent > book BTW). scheme of lazy evaluation called "graph reduction" you may consider it as repetitive replacing right parts of function definitions with their left p

Re: [Haskell-cafe] help understanding lazy evaluation

2007-08-23 Thread Stefan O'Rear
On Thu, Aug 23, 2007 at 10:00:00AM +0200, Xavier Noria wrote: > You people rock. Responses were really helpful and I understand how the > computation goes now. > > I see I need to reprogram my eyes to expect lazy evaluation in places where > I am used to one-shot results. I see lazy evaluation is

Re: [Haskell-cafe] help understanding lazy evaluation

2007-08-23 Thread Xavier Noria
You people rock. Responses were really helpful and I understand how the computation goes now. I see I need to reprogram my eyes to expect lazy evaluation in places where I am used to one-shot results. I see lazy evaluation is all around in Haskell builtins. From a formal point of view how

Re: [Haskell-cafe] help understanding lazy evaluation

2007-08-22 Thread Ryan Ingram
The insight is that the functions called can be lazy internally; the computation doesn't proceed by either fully evaluating something or not, but rather by rewriting parts of the computation graph. Here is a trace of the evaluation of "prime" for integers n > 1: prime n => factors n == [1,n] => f

Re: [Haskell-cafe] help understanding lazy evaluation

2007-08-22 Thread Derek Elkins
> > > [*] Which notation do you use for functions in text? is f() ok? > > Sure, although a little unusual for Haskell where f() means f applied > to the empty tuple. Some people use |f| (generally those who use > latex), but generally it can be inferred from the context what is a > function Nei

Re: [Haskell-cafe] help understanding lazy evaluation

2007-08-22 Thread Michael Vanier
Xavier, First off, we don't put the () after function names in Haskell. What's happening is this (experts please correct any mistakes here): 1) You call prime on a number (e.g. 42). 2) In order to evaluate this further, (factors 42) must be evaluated at least partially to give input to == in p

Re: [Haskell-cafe] help understanding lazy evaluation

2007-08-22 Thread Neil Mitchell
Hi >factors :: Int -> [Int] >factors n = [x | x <- [1..n], n `mod` x == 0] > >prime :: Int -> Bool >prime n = factors n == [1, n] > > My vague intuition said "we either need factors or we don't, we do > because we need to perform the test, so we compute it". That's wrong, > so a po

[Haskell-cafe] help understanding lazy evaluation

2007-08-22 Thread Xavier Noria
I am learning Haskell with "Programming in Haskell" (an excellent book BTW). I have background in several languages but none of them has lazy evaluation. By now I am getting along with the intuitive idea that things are not evaluated until needed, but there's an example I don't understand