| 1 | = Proposal: make the $ operator left-associative = |
| 2 | |
| 3 | == Arguments in favour == |
| 4 | |
| 5 | 0) $ was introduced as a combinator for function application. |
| 6 | Therefore we might expect that whenever we have a function application |
| 7 | we can stick a $ in there. But this is not the case. Consider the |
| 8 | following expression: |
| 9 | {{{ |
| 10 | f x y |
| 11 | }}} |
| 12 | There are two applications here and if $ behaved like function |
| 13 | application we would be able to write: |
| 14 | {{{ |
| 15 | f $ x $ y |
| 16 | }}} |
| 17 | But as it is now this expression means something completely different. |
| 18 | |
| 19 | (these following points taken from [http://www.haskell.org/pipermail/haskell-prime/2008-April/002459.html Dan Doel's post on the haskell-prime mailing list]) |
| 20 | |
| 21 | 1) Anything of the form: |
| 22 | |
| 23 | {{{ |
| 24 | f $ g $ h $ x |
| 25 | }}} |
| 26 | |
| 27 | with right associative ($) can instead be written: |
| 28 | |
| 29 | {{{ |
| 30 | f . g . h $ x |
| 31 | }}} |
| 32 | where the associativity of ($) doesn't matter. It's not uncommon to want to |
| 33 | peel off the end of such a pipeline to eliminate a point. For the second |
| 34 | form, such a translation is: |
| 35 | {{{ |
| 36 | \x -> f . g . h $ x ==> f . g . h |
| 37 | }}} |
| 38 | However: |
| 39 | |
| 40 | {{{ |
| 41 | \x -> f $ g $ h $ x ==> f $ g $ h |
| 42 | }}} |
| 43 | |
| 44 | Is invalid, so one might argue that writing such pipelines with composition is |
| 45 | a better habit to get into, as it allows easier cleanup of code in this way |
| 46 | (if you like somewhat point-free code, that is). |
| 47 | |
| 48 | 2) Left associative ($) allows you to eliminate more parentheses. Per #1, any |
| 49 | parentheses eliminated by right associative ($) can be eliminated by (.) and |
| 50 | a single ($). However, left associative ($) allows, for instance: |
| 51 | |
| 52 | {{{ |
| 53 | f (g x) (h y) ==> f $ g x $ h y |
| 54 | }}} |
| 55 | |
| 56 | 3) Left associative ($) is consistent with left associative ($!). The right |
| 57 | associative version of the latter is inconvenient, because it only allows |
| 58 | things to be (easily) strictly applied to the last argument of a function. |
| 59 | Needing to strictly apply to other arguments gives rise to things like: |
| 60 | |
| 61 | {{{ |
| 62 | (f $! x) y z |
| 63 | ((f $! x) $! y) $! z |
| 64 | }}} |
| 65 | |
| 66 | Left associative, these are: |
| 67 | |
| 68 | {{{ |
| 69 | f $! x $ y $ z |
| 70 | f $! x $! y $! z |
| 71 | }}} |
| 72 | |
| 73 | There may be more arguments, but those are the ones I've heard that I can |
| 74 | think of at the moment. #3 strikes me as the most likely to bite people (the |
| 75 | other two are more stylistic issues), but I suppose I don't know the relative |
| 76 | frequency of strict pipelines (f $! g $! x) versus strict applications at |
| 77 | non-final arguments. |
| 78 | |
| 79 | == Arguments against == |
| 80 | |
| 81 | * This would break a ''lot'' of code. |