Re: new keyword: infixlr?

2010-09-10 Thread Brandon S Allbery KF8NH
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/10/10 14:13 , 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
 but I guess that wasn't something you were thinking about?

That strikes me as a trivial application of the proposal; in Haskell it's
not clear to me that there's a significant different between the two, thanks
to laziness.

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyKfvgACgkQIn7hlCsL25Xt7QCggYY7LvGcj+F8Or91931pPOQR
OlIAoM0BwQt+/+MqDXGhoeIjCoBCnEo6
=Nh7X
-END PGP SIGNATURE-
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: new keyword: infixlr?

2010-09-10 Thread S. Doaitse Swierstra

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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: new keyword: infixlr?

2010-09-10 Thread Wolfgang Jeltsch
Am Freitag, den 10.09.2010, 23:18 +0200 schrieb S. Doaitse Swierstra:
 On 10 sep 2010, at 20:13, Ian Lynagh wrote:
  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.

To me, it seems weird that optimization should be done at the level of
syntax. Note that optimization would only trigger if you write concrete
applications of the infix operator, not if you construct them
programmatically.

Best wishes,
Wolfgang

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