[Haskell-cafe] Point-free style (Was: Things to avoid)

[Matthew Roberts]

I have to agree (although I suspect few others will :))

matt

On 11/02/2005, at 1:23 AM, Jan-Willem Maessen wrote:

>
> On Feb 10, 2005, at 6:50 AM, Henning Thielemann wrote:
>> On Thu, 10 Feb 2005, [ISO-8859-1] Thomas Jäger wrote:
>>> Altogether, the spirit of the page seems to be "use as little
>>> syntactic sugar as possible" which maybe appropriate if it is aimed 
>>> at
>>> newbies, who often overuse syntactic sugar (do-notation).
>>
>> This overuse is what I observed and what I like to reduce. There are 
>> many
>> people advocating Haskell just because of the sugar, which let 
>> interested
>> people fail to see what's essential for Haskell. When someone says to 
>> me
>> that there is a new language which I should know of because it 
>> supports
>> definition of infix operators and list comprehension, I shake my head 
>> and
>> wonder why he don't simply stick to Perl, Python, C++ or whatever.
>
> If you're trying to avoid obscurity, why advocate point-free style?
>
> I ask this question to be deliberately provocative; I'm not trying to 
> single you out in particular.  So, to everybody: What's so great about 
> point-free style?
>
> Is it really clear or obvious what
>
> > map . (+)
>
> means?  Contrast this with
>
> > \n -> map (+n)
>
> or
>
> > \n xs -> map (+n) xs
>
> I submit that, while it is possible to develop a reading knowledge of 
> point-free style, non-trivial use of point-free 
> computations---compositions of functions with arity greater than 1, as 
> above, compositions of sections of composition or application, arrow 
> notation without the sugar, and so forth---will always be more 
> difficult to read and understand than the direct version.  I submit 
> that this is true even if one is familiar with point-free programming 
> and skilled in its use.
> Even something as simple as eta-reduction (as in the second and third 
> functions above) can seriously obscure the meaning of program code by 
> concealing the natural arity of a function.
>
> -Jan-Willem Maessen
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>