The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

103210 (3) [Avatar] Offline
#1
Q3.2 says that the counter version with let will cause an error if you try to run it - when I try it (ghci 8.2.2) I don't get an error but it never returns - Ctrl-C breaks out of execution.

I assume there's some kind of infinite loop but can't find an explanation in the book about why the let version doesn't work but the lambda version does. What am I missing ?
449049 (17) [Avatar] Offline
#2
I have the same question. I also don't really understand what
counter
is supposed to be doing. Is it increasing
x
by 1?

So far, to increment by x by 1 in counter I have the following:


lamCounter x = (\x ->
                  (\x -> x + 1) x
                  ) x
103210 (3) [Avatar] Offline
#3
counter returns the original value incremented by 2. Each redefinition of x increments it by one.
The published answer for the lambda version has two nestings that each increment it by 1but the last lambda is simply the identity function ((\x->x) x)). The obvious question is why is this a function and not just the value x? It must have something to do with the way it is passed/evaluated, but it is hard to grok with it being so nested. Is that last one - I think it's innermost, the first to get evaluated? I've tried un-nesting it a layer - as I did with overwrite but failed to really grok that either. It's a pity the book doesn't go through the steps of evaluation substitution-wise. We just went through a discussion of scope so that may well be relevant. With the add* funcs it seemed relatively easy to see where the y's came from, and I thought I understood the x's, but I suspect I really don't. I keep looking at the nesting of the parens and think that should illuminate things, but the parens don't group lexically the same way they would e.g. in a Lisp program - You would expect the very first ( to match with the very last ) but they don't seem to, at least in an editor.
425544 (2) [Avatar] Offline
#4
It’s not producing an error for me as well. Can someone explain what happens when haskell tried to run te given example in the book that is sopposed to error?