[Haskell-cafe] Desugaring of infix operators is (always?) the wrong way round

Brian Hulley brianh at metamilk.com
Tue Sep 25 14:13:07 EDT 2007


I'm in the process of designing a little language inspired by Haskell 
but imperative, and have hit an issue regarding infix syntax which may 
be of interest also to anyone thinking about future revisions of Haskell 
or the problem of consistent parameter order in libraries.

I'm wondering if anyone can shed light on the reason why

    x # y

gets desugared to

   (#) x y

and not

   (#) y x

since the first desugaring always seems to lead to (#) having to be 
defined in a way that is unnatural for functional programming. This is 
why a lot of functions in the standard libraries have their arguments 
the wrong way round. For example in Data.Bits we have:

    shiftL :: a -> Int -> a

whereas the natural argument order for a functional language would be to 
make it so that in an application one has the verb first followed by the 
noun as in:

    shiftL' :: Int -> a -> a

so we could write (shiftL' 3) to denote the operation of shifting 
something left by 3 eg:

        shiftLeftByThree = shiftL' 3
       map shiftLeftByThree  [10, 78, 99, 102]

(This choice of argument order is explained at 
http://www.haskell.org/haskellwiki/Parameter_order )

Similarly, considering arithmetic, it would make a lot more sense to me 
to define:

    x - y === (-) y x

since the "action" here is "take away y" and the noun is "x" so the 
natural functional reading of (-) a b is "subtract a from b".

To be consistent this would also have to apply to the use of (->) in 
types to get:

    a -> b === (->) b a

Can anyone think of an example where the current desugaring of infix 
arguments gives the correct order when the function is used in a postfix 
application? (apart from commutative functions of course!)


More information about the Haskell-Cafe mailing list