[Haskell-cafe] Re: First time haskell - parse error!
Sebastian Fischer s...@informatik.uni-kiel.de wrote: (Choosing names that are misleading or flat out wrong is of course always a bad idea.) foo = f . g . h where f x = ... g x = ... h x = ... Sometimes laziness is just the clearest option. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: First time haskell - parse error!
From: Ketil Malde ke...@malde.org S. Doaitse Swierstra doai...@cs.uu.nl writes: then (s1 ++ s2 ++ s3 ++ s4) where s1 = Golds s2 = show (gold s g) s3 = , Silvers s4 = show (silver s g) If you want to keep the definitions local to the expression you should write ..but I think it is better style to avoid this kind of one-off named values. I much prefer: then Golds ++show (gold s g)++... For some reason, this is a style isse that doesn't get much attention, at least not in the non-functional language tradition, where temporary variables are scattered all over. So instead of doing: let ns y = not (isSpace y) f x = takeWhile ns x in map f We can use anonymous functions in place of the uninformatively named ones: map (\x - takeWhile (\y - not (isSpace y)) x) and use partial application toward point-free-ness: map (takeWhile (not . isSpace)) I agree, and also tend to this style. Although I sometimes use one-off named values to avoid line wraps. For the particular task of combining strings like this, how about using Text.Printf.printf? then printf Golds %s, Silvers %s (show (gold s g)) (show (silver s g)) It can be a little hard to understand the type at first, but IMHO it works as expected. Cheers, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: First time haskell - parse error!
Good names can help making comments less important. OTOH, comment can give you the best(?) of both worlds, both revealing the linear structure of the function, while still providing extra information: oddSquareSum :: Integer oddSquareSum = sum -- add together . takeWhile (1) -- until a value 10K is seen . filter odd -- all the odd . map (^2)-- squares of $ [1..] -- natural numbers -k Hmm. My 0.03$ (to whole thread): 1. I prefer the concept of pipeline. - It gives me feeling that I'm not interested in the order of computation (map all values to square, then filter the odds) but rather with semi-parallel computation (which is really what is happening). Let syntax, being much more flexible, may give semi-imperative approach (although much more mixed). - I read that average human remembers up to 7-10 things in short term memory - why garbage it with variables? On the other hand more complex computation may require let/where and/or arrows helper functions. For example: filter (\x - case x of Nil - False; _ - True) ... or filter (\x - case x of Nil - False _ - True) ... is less clear then filter (not . isNil) ... where isNil Nil = True isNil _ = False 2. The comments in the above example are too verbose for my taste. It is like (in imperative program): x = x + 1; // add 1 to x Anyone having minimal knowledge about syntax will be able to deduce the comment directly from the line so why repeat it. However: c = ~c | (c 0xFF00); // Invert the color in ARGB Is meaningful comment. There is little information what the line does and it may happen that the operation must be done efficiently (inner loop). 3. While name should be meaningful (oddSquereSum is not - however it IMHO is permissible in let/where) if project have documentation and function is exported it should have documentation. While name is part of documentation it cannot replace it. signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
