Bug in "Haskell for C programmers" tutorial?
Hi all, I'm working through the "Haskell for C programmers" tutorial and in this section": http://www.haskell.org/~pairwise/intro/section2.html#part3 it has: fib :: Num a, Num b => a -> b fib n = fibGen 0 1 n fibGen :: Num a, Num b => b -> b -> a -> b fibGen a b n = case n of 0 -> a n -> fibGen b (a + b) (n - 1) which doesn't work with GHC, but it does if I add parentheses around both instances of "Num a, Num b". Is this a bug in the tutorial or is there another explanation? Cheers, Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin." - John Von Neumann (1951)
Erik de Castro Lopo wrote:
Hi all,
I'm working through the "Haskell for C programmers" tutorial and in this section":
Now : http://www.haskell.org/~pairwise/intro/section3.html#part3 has the following: showLen :: [a] -> String showLen lst = (show (theLen)) ++ (if theLen == 1 then " item" else " items") where theLen = len lst Shouldn't "len" in the last line be "length"? Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Indeed, I am impressed that Google runs an 8,000 node Linux cluster, 5 data centers, an extensive network, and a rapidly evolving application all with a staff of 12." -- http://research.microsoft.com/~gray/papers/FAAMs_HPTS.doc
Yes, it's a bug in the tutorial, on both accounts. Hopefully Eric is
reading this list :)
- Cale
On 31/12/05, Erik de Castro Lopo
Erik de Castro Lopo wrote:
Hi all,
I'm working through the "Haskell for C programmers" tutorial and in this section":
Now :
http://www.haskell.org/~pairwise/intro/section3.html#part3
has the following:
showLen :: [a] -> String showLen lst = (show (theLen)) ++ (if theLen == 1 then " item" else " items") where theLen = len lst
Shouldn't "len" in the last line be "length"?
Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Indeed, I am impressed that Google runs an 8,000 node Linux cluster, 5 data centers, an extensive network, and a rapidly evolving application all with a staff of 12." -- http://research.microsoft.com/~gray/papers/FAAMs_HPTS.doc _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Erik de Castro Lopo wrote:
Hi all,
I'm working through the "Haskell for C programmers" tutorial and in this section":
http://www.haskell.org/~pairwise/intro/section3.html#part7 has: main = do putStr "prompt 1" a <- getLine putStr "prompt 2" b <- getLine putStrLn (show (someFunc (read a) (read b))) which I believe needs a: hFlush stdout after each "putStr" line and an "import System.IO" at the top of the file. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Ever since GNOME development began, I have urged people to aim to make it as good as the Macintosh. To try to be like Windows is to try for second-best." - Richard Stallman
You shouldn't have to flush output manually. Which implementation are
you using? Try importing System.IO and doing:
hGetBuffering stdout >>= print
and see what gets printed. It should be "NoBuffering". If for whatever
reason it's not, you can set it to that at the start of your programs
with
hSetBuffering stdout NoBuffering
If it's still NoBuffering, check that your terminal isn't doing
something strange.
hope this helps,
- Cale
On 31/12/05, Erik de Castro Lopo
Erik de Castro Lopo wrote:
Hi all,
I'm working through the "Haskell for C programmers" tutorial and in this section":
http://www.haskell.org/~pairwise/intro/section3.html#part7
has:
main = do putStr "prompt 1" a <- getLine putStr "prompt 2" b <- getLine putStrLn (show (someFunc (read a) (read b)))
which I believe needs a:
hFlush stdout
after each "putStr" line and an "import System.IO" at the top of the file.
Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Ever since GNOME development began, I have urged people to aim to make it as good as the Macintosh. To try to be like Windows is to try for second-best." - Richard Stallman _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Cale Gibbard wrote:
You shouldn't have to flush output manually. Which implementation are you using?
I'm using GHC.
Try importing System.IO and doing: hGetBuffering stdout >>= print and see what gets printed. It should be "NoBuffering".
Nope, it says "LineBuffering".
If for whatever reason it's not, you can set it to that at the start of your programs with hSetBuffering stdout NoBuffering
Ok, using that I can drop the hFlush and it works as expected. Thanks, Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "The lusers I know are so clueless, that if they were dipped in clue musk and dropped in the middle of pack of horny clues, on clue prom night during clue happy hour, they still couldn't get a clue." --Michael Girdwood, in the monastery -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Gambling(n): A discretionary tax on those asleep during high school maths.
Cale Gibbard wrote:
You shouldn't have to flush output manually. Which implementation are you using? Try importing System.IO and doing: hGetBuffering stdout >>= print and see what gets printed. It should be "NoBuffering".
The buffering for stdout should be LineBuffering if stdout is a terminal and BlockBuffering otherwise. The buffering for stderr should always be NoBuffering.
If for whatever reason it's not, you can set it to that at the start of your programs with hSetBuffering stdout NoBuffering
I would suggest using an explit hFlush after each putStr rather than
disabling buffering altogether, as disabling buffering will result in
putStr etc calling write() once per character, which is very
inefficient.
--
Glynn Clements
On 01/01/06, Glynn Clements
Cale Gibbard wrote:
You shouldn't have to flush output manually. Which implementation are you using? Try importing System.IO and doing: hGetBuffering stdout >>= print and see what gets printed. It should be "NoBuffering".
The buffering for stdout should be LineBuffering if stdout is a terminal and BlockBuffering otherwise. The buffering for stderr should always be NoBuffering.
It's actually not, if you're starting your program from ghci, which is what confused me. From GHCi, you get NoBuffering on stdout, and LineBuffering on stdin, which is sane for interactive programs. Why anyone would want LineBuffering as default on stdout is somewhat mysterious to me. - Cale
Cale Gibbard wrote:
You shouldn't have to flush output manually. Which implementation are you using? Try importing System.IO and doing: hGetBuffering stdout >>= print and see what gets printed. It should be "NoBuffering".
The buffering for stdout should be LineBuffering if stdout is a terminal and BlockBuffering otherwise. The buffering for stderr should always be NoBuffering.
It's actually not, if you're starting your program from ghci, which is what confused me. From GHCi, you get NoBuffering on stdout, and LineBuffering on stdin, which is sane for interactive programs. Why anyone would want LineBuffering as default on stdout is somewhat mysterious to me.
Because most programs output entire lines, and the implementation of
Haskell's putStr etc sucks when using NoBuffering (one write() per
character).
C follows the same rules (stdin/stdout use line buffering for
terminals, block buffering otherwise, stderr is always unbuffered),
even though C's puts(), printf() etc behave a lot better with
unbuffered streams (they pass either whole strings or large chunks to
write() rather than individual characters).
--
Glynn Clements
Erik de Castro Lopo wrote:
Hi all,
I'm working through the "Haskell for C programmers" tutorial and in this section":
http://www.haskell.org/~pairwise/intro/section3.html#part8 has a broken links to: http://www.haskell.org/ghc/docs/latest/html/libraries/base/System.IO.html#20 Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "I'm not proud .... We really haven't done everything we could to protect our customers ... Our products just aren't engineered for security." -- Brian Valentine, Senior Vice President of Microsoft's Windows development team
Erik de Castro Lopo wrote:
Hi all,
I'm working through the "Haskell for C programmers" tutorial and in this section":
This section http://www.haskell.org/~pairwise/intro/section4.html#part1 doing the calcMassesOverDists could also do with some work. The code listed does not seem to work under GHC. It would be kinda nice is all of the examples were complete working examples. I must admit however that I'm learning more fixing stuff that doesn't work than I would have learnt if everything just worked first time :-). Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "An older MS internal whitepaper from August 2000 on switching Hotmail, which MS acquired in 1997, from front-end servers running FreeBSD and back-end database servers running Solaris to a whole farm running Win2K, reads like a veritable sales brochure for UNIX" -- http://www.theregister.co.uk/content/4/28226.html
Hello Erik, Sunday, January 01, 2006, 7:23:02 AM, you wrote: EdCL> It would be kinda nice is all of the examples were complete EdCL> working examples. I must admit however that I'm learning more EdCL> fixing stuff that doesn't work than I would have learnt if EdCL> everything just worked first time :-). may be author of this tutorial is ingenious teacher? ;) -- Best regards, Bulat mailto:bulatz@HotPOP.com
participants (4)
-
Bulat Ziganshin -
Cale Gibbard -
Erik de Castro Lopo -
Glynn Clements