Hello Sebastian, Friday, November 18, 2005, 6:35:13 PM, you wrote:
groupLen mapper combinator tester = length . takeWhile tester . scanl1 combinator . map mapper
SS> This is a border line example of what I would consider being abuse of SS> the (.) operator. SS> First of all, that line is 96 characters long. A bit much if you ask SS> me. my 15" CRT holds entire 100, even 102 chars in line and i don't want to lose even one of them! :) especially when comment to this function occupies another 7 lines :) SS> groupLen' mapper combinator tester xs SS> = length $ takeWhile tester $ scanl1 combinator $ map mapper xs SS> The difference is minimal, if anything I think that writing out the SS> list argument is actually clearer in this case (although there are SS> cases when you want to work on functions, and writing out the SS> parameters makes things less clear). ... including this one. i'm work with functions, when possible: build them from values and other functions, hold them in datastructures, pass and return them to/from functions. if function definition can be written w/o part of its arguments, i do it in most cases moreover, in some cases this leads to dramatic changes in speed. see: -- |Test whether `filepath` meet one of filemasks `filespecs` match_filespecs filespecs {-filepath-} = any_function (map match_FP filespecs) function `match_FP` thranslates regexps to functions checking that given filename match this regular expression: match_FP :: RegExp -> (String->Bool) when definition of `match_filespecs` contained `filepath`, this testing works very slow for large filelists. imho, for each filename list of filespecs was retranslated to testing functions, each function applied to filename and then results was combined by `any_function`. it's a pity, especially cosidering that most common case for regexps list was just ["*"], which must render to (const True) testing function. so, in this case it was absolutely necessary to write all this regexp machinery in point-free style, so that it returns data-independent functions, which then "optimized" (reduced) by Haskell evaluator before applying them to filenames on the Wiki page RunTimeCompilation there is another examples of building functions from datastructures before applying to input data it is very possible that this point-free `groupLen` definition, together with other point-free definitions, makes filelist processing in my program faster - i just dont't checked it SS> I'm not saying it's impossible to make good use of (.), I'm saying SS> that it's not crucial enough to warrant giving it the dot, which in my SS> opinion is one of the best symbols (and I'd hand it over to record SS> selection any day of the week!). SS> I'm also saying that people tend to abuse the (.) operator when they SS> start out because they think that "less verbose == better", whereas SS> most people, in my experience, tend to stop using (.) for all but the SS> simplest cases (such as "filte (not . null)") after a while to promote SS> readability. I prefer adding a few lines with named sub-expressions to SS> make things clearer. "readability" is not some constant factor for all people. it depends on your experience. for you it is natural to work with data values. for me, it's the same natural to work with function values, partially apply and combine them. and in those definitions the variables containing actual data is just looks as "garbage" for me -- Best regards, Bulat mailto:bulatz@HotPOP.com