[Haskell-cafe] Why is $ right associative instead of
brianh at metamilk.com
Sat Feb 4 14:15:47 EST 2006
Brian Hulley wrote:
> Tomasz Zielonka wrote:
>> On Sat, Feb 04, 2006 at 02:52:20PM -0000, Brian Hulley wrote:
>>> Hi -
>>> In the Haskell98 report section 4.4.2 $ is specified as being right
>>> associative. This means that f $ a0 a1 $ b0 b1 would parse as f (a0
>>> a1 (b0 b1)) which seems rather strange to me. Surely it would be
>>> much more useful if $ were defined as left associative so that it
>>> could be used to separate the args to f?
>>> Does anyone know why this strange associativity was chosen?
>> Probably it was anticipated that right associative version will
>> be more useful. You can use it to create a chain of transformations,
>> similar to a chain of composed functions:
>> (f . g . h) x = f $ g $ h $ x
Actually I'm beginning to think this might be more useful after all.
>> map f $ group $ sort $ filter g $ l
>> But of course, left associative version can also be useful. Some
>> time ago I used a left associative version of the strict application
>> operator, which I named (!$).
I suppose I could use $$ for left associative application, and #$$ for
> I wonder if anyone has done empirical studies to determine
> scientifically which associativity would be more useful in practice
> eg by analysis of source code involving $ and comparing the number of
> parentheses that would be needed in each case, and perhaps also some
> studies involving the number of confused readers in each case...
> Even though both versions are useful, it seems to me that faced with
> the choice of choosing an associativity for an operator that does
> function application, and given that prefix application is left
> associative, there is one clear winner, but unfortunately the Haskell
> committee didn't see it this way, and perhaps it is too late to ever
> change this (just like :: and : which were mixed up for reasons
> unknown). Especially since chains can already be composed using "." .
It would be very useful if the Haskell report explained *why* decisions were
made, because there often seem to be good reasons that are not immediately
obvious and sometimes counter intuitive. I think the mystery surrounding ::
and : might have been that originally people thought type annotations would
hardly ever be needed whereas list cons is often needed, but now that it is
regarded as good practice to put a type annotation before every top level
value binding, and as the type system becomes more and more complex (eg with
GADTs etc), type annotations are now presumably far more common than list
cons so it would be good if Haskell Prime would swap these operators back to
their de facto universal inter-language standard of list cons and type
More information about the Haskell-Cafe