11–20 of 30 posts
Not tackling pattern matching is a pretty big deficiency. Otherwise, it seems interesting, and I wonder if :i-o would really be easier to type than IO for most use cases.
Shouldn't: def fib(n): if n Be: ... if n ? Or am I being stupid? EDIT: changed x to n.
Earlier quoted context omitted.
It's definitely wrong - just ran it in python to check in case I was missing something!
I don't think it's explicitly wrong; I've seen both fib(0) = 1 and fib(0) = 0 before. Wikipedia shows: By definition, the first two Fibonacci numbers are 0 and 1, and each subsequent number is the sum of the previous two. Some sources omit the initial 0, instead beginning the sequence with two 1s.
EDIT: Actually, I think you're right: it's just an index thing (do we start at 1 or 0) - I was confusing the index of 2 with the value of 2.
Earlier quoted context omitted.
works with both - try it on paper
I did - with 2: fib(2) = fib(2-1) + fib(2-2) fib(2) = fib(1) + fib(0) fib(2) = 1 + 1 (rather than 1 + 0) No?
Shouldn't: def fib(n): if n Be: ... if n ? Or am I being stupid? EDIT: changed x to n.
You must mean "return n", but I don't have an opinion on "correct" behvior. All that's happening is the index is shifted by 1.
However, it's certainly different to the other examples and I would expect fib(2) to be 1 + 0 not 1 + 1.
It's a very minor point though - I think I'll stop now ;)
Taking the authors example and moving some of the processing to a where clause makes the flow much easier to follow:
someFunction conn (Foo n) (K {x=zot}) plib = do
withTransaction conn $ \db ->
coconut (fromMaybe "" $ sausages >>= bacon)
One last thing, the author complains about the ambiguity of the indentation, but doesn't make any comment about the brace & semi-colon syntax. I personally don't like it, but it should be explained why it isn't an acceptable solution.
Python's is more restrictive: you must skip a line before starting a multi-line indented block; i.e., this is not legal:
if a == b: print "asdf"
print "a"
else:
print "a"
Not so in Haskell, because you are given the freedom to put the first line of a block in the same line as the block starter:
let x = 1
y = 2
do x That's just the simple case, because you are also allowed to put these block starters (let, do, case, etc) at arbitrary points in an expression:
f = let x = 1 in let y = x + 2 in
y + 1
It becomes very easy to get yourself into situations where you cannot use the Python rule. But you can also impose restrictions on yourself so you _can_ use that rule. Like always treating let, do, in, etc as "{"'s in C:
f = let
x = 1
in
let
y = x + 2
in
y + 1
f = let
x = 1 in let
y = x + 2 in
y + 1
While programming in Haskell I also struggled with Haskell's brand of whitespace indentation, even though I come from Python. The key difference in usability between Python's whitespace indentation system and Haskell's indentation system is that you cannot start the lines in a block on the same line as the block. Python's is more restrictive: you must skip a line before starting a multi-line indented block; i.e., thi…
let a = 3 in
f a
While programming in Haskell I also struggled with Haskell's brand of whitespace indentation, even though I come from Python. The key difference in usability between Python's whitespace indentation system and Haskell's indentation system is that you cannot start the lines in a block on the same line as the block. Python's is more restrictive: you must skip a line before starting a multi-line indented block; i.e., thi…
let x = y
in do something
something with
( lots
. of
. args
)
something else
And if you're getting those terribly long-expressions, break them up. They can always be broken out in a let expression to be simpler, and with let the precedence is obvious.
map (alpha . bravo) . filter charlie xray yankee >> zulu
let f1 = map (alpha . bravo) . filter charlee xray
f2 = yankee
result = f1 f2
in result >> zulu
Of course naming your variables descriptively helps a lot too. Examples with single-variable names are probably not the best.