Back to Questions
864
views3
comments
Compiler bug (or I'm missing something)
f#compiler

open System.Diagnostics
let x = 1
let y = 1
Debug.Assert (x = y)

For some reason that simple code causes this error:

error FS0191: The member or object constructor 'Assert' does not take 0 argument(s). An overload was found taking 1 arguments.

However, if I add some parenthesis it works e.g.:

Debug.Assert ((x) = y)
Debug.Assert ((x) = (y))
Debug.Assert ((x = y))

In all cases the parenthesis seem pointless but they somehow make it compile.
This one doesn't though: Debug.Assert (x = (y))

Thanks!

Steven

.

From what I can tell, this is the named argument stuff not working as you expect.

Condier this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

type Test = 

  static member Assert (cond:bool) = ()

let x = 1

let y = 2

Test.Assert(x = y)

  Test.Assert(x = y);;

  ^^^^^^^^^^^^^^^^^^^

stdin(10,1): error FS0191: The member or object constructor 'Assert' has no argument or settable return property 'x'. The required signature is static member Test.Assert : cond:bool -> unit.

Sections 8.4.5 and 14.4 of the F# spec goes into more detail on the process. Particularly, wrapping it in another set of parens, as you've noted, no longer makes it a syntactic tuple and it works like you hope.

Why does it do this? I'm not quite sure, but consider this:

1
2
3
4

let condition = false

Debug.Assert(condition = false)

Are you trying to create a boolean? Or setting the named arg condition to false?

So, it's probably always assuming that = is specifying named args, and then failing to be safe. Maybe someone with more insight can clarify.

By on 3/5/2009 9:07 PM ()

This is unfortunate syntax, in my opinion. A good language doesn't throw curve-balls like this. I don't have a problem with giving one interpretation I to a given syntax in context A and a different interpretation J in context B, but only when I is nonsensical in B and J is nonsensical in A.

In this case, however, (x = y) generally has the interpretation "the equality operator applied to arguments x and y", and this interpretation still has meaning in the context of being passed into a function. Overriding this interpretation by making f(x = y) the syntax for argument labeling is a bad decision.

By on 3/6/2009 1:44 PM ()

This is some friction with the .NET/OO side of things.

I suggest you write to fsbugs@microsoft.com and let them know what you think. I agree, it is confusing, until you learn that syntactically calling .NET methods is special :). (After you turn them into normal functions, then the issue goes away, IIRC.)

By on 3/6/2009 3:35 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper