On 10 sep 2010, at 20:13, Ian Lynagh wrote:

On Fri, Sep 10, 2010 at 07:51:10PM +0200, S. Doaitse Swierstra wrote:

...

Currently Haskell has infix, infixl and infixr operators. I see a use for infixlr as well. This indicates that the implemtation may assume the operator to be associative, and thus has the freedom to "balance" an expression containing several operator occurrences.

Would it be restricted to use with operators with types that are (a -> a -> a) (or more specific)?

This is what I would normally expect from an infix operator.

Otherwise e.g. let (+:) = (:) infixlr :+ in [] +: [] +: [] could have type [[a]] or [[[a]]].

...

The reason that I bring up this is that in a new combinator I have added to my parser library (the <||> in Text.ParserCombinators.UU.Derived) internally uses cartesian products, which are being constructed and updated. If the compiler had the right to interpret the expressions a <||> b <||>c <||> d as e.g. (a <||> b) <||> (c <||> d) then the updating time for would go down from O(n) to O(log n).

How would the compiler work out which parsing to prefer? Or would it assume that infixlr expressions are best balanced?

Yes, that is the idea.

When first reading the proposal, I thought the idea was to allow the compiler to more easily perform optimisations like a+b+c+2+3+d => a+b+c+5+d but I guess that wasn't something you were thinking about?

Indeed, but the behaviour would not be forbidden either. If you would expect this then I would probably also want to introduce "comm" for commutative operators, so a+2+b+c would get transformed into a+b+c+(2+4). The only suse for this is that after inlining some further optimisations might take place, which would be hard for a programmer to achieve otherwise. My intention was however not to make things very complicated at this point. Doaitse

Thanks Ian

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

On 2010-09-10 19:13 +0100, Ian Lynagh wrote:

When first reading the proposal, I thought the idea was to allow the compiler to more easily perform optimisations like a+b+c+2+3+d => a+b+c+5+d

Of course, since I don't think fixity can be specified per-instance of Num, one would not be able to use this proposal for this; not all Num instances have an associative (+). -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Oops, I mixed up associative with commutative. On Tue, Sep 14, 2010 at 1:27 PM, Bas van Dijk wrote:

On Mon, Sep 13, 2010 at 4:23 PM, Nick Bowler wrote:

...

... not all Num instances have an associative (+).

Indeed:

$ cabal install repr    # [1] ... $ ghci Prelude> :m Text.Repr Prelude Text.Repr> show (1 + 2 :: Repr Int) == show (2 + 1 :: Repr Int) False

because: show (1 + 2 :: Repr Int) == "1 + 2" show (2 + 1 :: Repr Int) == "2 + 1"

but note: Prelude Text.Repr> (1 + 2 :: Repr Int) == (2 + 1 :: Repr Int) True

Bas

[1] http://hackage.haskell.org/package/repr