[darcs-users] DrHaskell report for darcs

[Neil Mitchell]

Hi

>>> Whether "Eta reduce" makes sense or not varies on a case-by-case basis,
>>> IMO. The question is mostly, "which is easiest to read and understand?".
>>
>> I particularly agree about this one, I'm still trying to see if there
>> is a general rule behind it or not...
>
> My intuition has always been, if it reduces parentheses, it's probably
> good. That is, 'foo a = baz (bar a)' would be reduced down to 'foo =
> baz . bar', which has fewer parentheses, and so is clearer. But
> something like 'f x y = z (x y)' turns 'f = (z .)' with the same
> number of parentheses, but is worse. (And some expressions can lead to
> horrifying pointless versions, needless to say.)

It will only ever suggest eta reducing for the last argument, i.e. it
will reduce:

f x y = z (x y) ==> f x = z . x

but no further. However, it tries to not break obvious symetry, i.e.:

f x y = f (g x) (g y)

will NOT suggest f (g x) . g

>>> "Use a list comprehension" I'm not convinced isn't an obfuscation.
>>> Again, the tool has added redundant parentheses.
>>
>> Colin does it, I think it looks cool :-) I find it a cool pattern, but
>> others can sensibly disagree.
>
> Just to chip in: I found most of those list comprehensions less clear as well.

I guess what is needed is some way to disable certain options for
certain people/

> One thing I wonder. Is the general approach of using '$' to get rid of
> parentheses subsumed under the eta-reduction advice?

That isn't used, it will never suggest the use of $ over brackets. It
will suggest replacing $ with . where you can eta reduce. I considered
this too much personal choice/local style.

> And does Dr. Haskell handle imports? There are a number of things
> which could be done there ('You always prefix a function from this
> module with its full name - perhaps you should import it qualified as
> well'; 'You only use two functions from this import. Explicitly
> importing them would make your module more future-proof and the module
> clearer'; 'you hide more functions/things than you allow in, so an
> explicit import would save you space' etc.)

It doesn't handle imports yet. Of course, patches are welcome :-) It
doesn't have any notion of linkage, so it doesn't know which
identifiers come from which modules, so the "you only use two" thing
is probably not possible.

Thanks

Neil