Hi, I'm going thru RWH [Real World Haskell] too... I'm finding it to be an excellent way to learn Haskell. I prefer it to the Computer Scientist geared books that I'm also reading... I also found "Learn You a Haskell for Great Good!" to be very worthwhile - I've ordered a copy of it and it should be availble at the end of April, see link: http://book.realworldhaskell.org/read/code-case-study-parsing-a-binary-data-... I found a link for RWH too - it is: http://fldit-www.cs.uni-dortmund.de/~peter/RealWorldHaskell.pdf BTW: I'm also an independent software consultant -- been doing it for 30+ years... As for your question, I'm not, as yet, prepared to answer it...but it seems to me that 'Sections' and 'Currying' are very important in the study of Haskell...but I'm still in 'newbie' status... I tried to install TK on my Windows Vista PC but was unable to do so...I will try it again, using RWH - if you're heading there too, please let me know - perhaps we can work this together... I also took a look at Category Theory books but so far I'm stumped with it - it's starting to make a bit of sense but I don't know if I'll be able to link it to Haskell... Good luck to both of us... Pat ----- Original Message ----- From: "Mike Meyer" To: "Haskell Beginners List" Sent: Wednesday, March 23, 2011 4:17 PM Subject: [Haskell-beginners] Does haskell have to have values?

I'm working my way through Real World haskell, and so far have found the experience quite pleasant (though the harder exercises seem to require things net yet covered).

Among the comments in the IO chapter was a discussion of whether or not some monad was or was not a function, which got me thinking.

Values in haskell aren't evaluated until they're needed. They're implemented as thunks, meaning they're roughly zeroadic functions that will return the value when called.

The syntax of the language seems to make treating values as zeroadic functions that return the value in question a reasonable interpretation as a degenerate case:

(+) accepts two arguments and returns their sum. (+ 5) accepts one argument and returns that plus 5. (3 + 5) accepts zero arguments and returns 8.

or (more pedantically):

(+) accepts one argument and returns a function that accepts one argument and returns a zeroadic function that returns the value of the sum of the two arguments. (+ 5) accepts one argument and returns a zeroadic function that ... (3 + 5) a zeroadic function that returns 8

So the question is - is there any advantage or harm in this way of looking at values?

Thanks, http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

Mike Meyer wrote:

So the question is - is there any advantage or harm in this way of looking at values?

One harm is that you are mixing two concepts, which Haskell specifically tries to keep separate: functions and procedures. A function maps a value to another value. A "zeroadic function" hence is not a function. It is indeed a value and the thunk concept is just a technical detail, about which you shouldn't bother. You can write proper Haskell programs without ever knowing, what a thunk is or how lazy evaluation is /implemented/. Now in most strict languages there are no real functions, and procedures are just named "functions" for some reason. In my opinion the "zeroadic function" view is going to hurt you much more than it is going to help you. Brent makes a good point that it may help you, when coming from a strict language, but on the other hand understanding lazy evaluation, non-strictness and forcing will make Haskell much more natural to you. With zeroadic "functions" you may end up not writing natural Haskell programs, but just trying to fit your strict view into the non-strict, lazily evaluated world. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/