[Haskell-cafe] Why is $ right associative instead of leftassociative?

[Brian Hulley]

Tomasz Zielonka wrote:
> On Sun, Feb 05, 2006 at 04:36:44PM -0000, Brian Hulley wrote:
>> Just in case you are interested, in the "preprocessor" I'm writing,
>> I would write these examples as:
>>
>>        (.) #>
>>                   f x y
>>                   g x
>>                   h x y
>>        $ z
>>
>> and
>>         a = #[
>>                    first
>>                    second
>>                    third
>>
>> where exp #> {e0,e1,...} is sugar for let a = exp in a e0 (a e1 (a
>> ... ) ...)) and #[ {e0, e1, ... } is sugar for [e0, e1, ...]
>> (exp #> block and exp #< block are the right and left associative
>> versions respectively and the special # sugar allows a layout block
>> to be started if it occurs at the end of a line)
>
> Well... I care about change locality and the like, but I'm not sure
> I would use such syntax (as a means of communication between
> programmers). Perhaps that's because I am not used to it and it looks
> alien. But it's rather because I still put readability first.

It is true that it looks quite alien at first, but consider that it allows 
you to use longer identifiers for function names (because they now only need 
to be written once) which could actually enhance readability eg

           Prelude.compose #>
                  f x y
                  g x
                  h x y
           $ z

so perhaps people would start using more real words instead of obscure 
symbols like >=+=< etc. Also, the less use of infix notation the better, 
because every infix symbol requires the reader to search for the fixity 
declaration then try to simulate a precedence parser at the same time as 
grappling with the semantics of the code itself. The #>, #< notation solves 
this problem by making the sugared associativity immediately visible, and 
the use of layout further enhances the direct visual picture of what's 
happening.

Anyway it's just an idea I thought I'd share- I'm sure there's no danger of 
it ever ending up in a future Haskell... ;-)

Regards, Brian.