[Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)

[Bulat Ziganshin]

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 at HotPOP.com