Decompiler Bug: precedence of constructor call and other tupled calls not strong enough

[GoogleCodeExporter]

Example 1:

> source <@ String([|'h';'i'|]).Length @>;;
val it : string = "(String([|'h'; 'i'|])).Length"

Example 2:

> source <@ "asdf".Substring(1,2).Length @>;;
val it : string = "("asdf".Substring(1, 2)).Length"

Original issue reported on code.google.com by stephen....@gmail.com on 17 Feb 2011 at 8:30

[GoogleCodeExporter]

Blocked: can't reconcile precedence of tupled arg applications from only 
available reference (the precedence table: 
http://msdn.microsoft.com/en-us/library/dd233228.aspx): applications of tupled 
calls need to be parenthesized, yet dot member calls on tupled calls need not.

Original comment by stephen....@gmail.com on 18 Feb 2011 at 5:34

[GoogleCodeExporter]

I think I remember reading somewhere, that the F# teams actually went out of 
their way to make tupled calls bind less strongly in the presence of a lambda 
application.

Original comment by stephen....@gmail.com on 18 Jul 2011 at 5:52

[GoogleCodeExporter]

Previous comment is true, was able to refactor precedence to take into account 
special cases like this.

Original comment by stephen....@gmail.com on 7 Aug 2011 at 6:46

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by stephen....@gmail.com on 18 Aug 2011 at 9:53

• Added labels: Milestone-Release2.1.0