Back to Questions
3.4k
views5
comments
type extensions and method overloading
f#compiler

Since if found myself annotating parameters with Stack<_> a lot, I decided to add an extension method I could use so the compiler would infer the type for me.

1
2
3
4

module MyModule =
    type Stack<'T> with
        static member Pop (stack : Stack<'T>) = stack.Pop()
        static member Push (stack : Stack<'T>) elem = stack.Push(elem)

It seems reasonable enough. Was strange that using an _ instead of 'T in the initial type declaration would cause an some warnings when you attempt to use the method, but I'd figure I'd give it a type var 'T instead would make it work, and it did. That wasn't the big issue though, and as it stands, this code won't compile. The error points at the call of stack.Push(elem), telling me "One or more of the overloads of this method has curried arguments. Consider redesigning these members to take arguments in tupled form." The original Push takes generic 'a for an item. The only overload for Push that takes curried arguments is the one I'm currently trying to define.

After some thought, I though of many reasons as to probably why it gets confused, as well as many reasons why it shouldn't. I came up with a few simple fixes though, as simple as changing the name of the method, or just change the line to this:

1

static member Push (stack : Stack<'T>) = fun elem -> stack.Push(elem)

which I though odd because this was exactly what I wrote before but in short hand. Then I realized it would probably make more sense to put these functions in a Stack module instead, which is what I ultimately did.

I've been generally having problems with methods and their overloads. So what exactly is going on behind the scenes between these two very similar declarations for Push that makes them different, and the two different Push methods that's has the compiler all tripped up?

.

I was able to repro this - very strange that as you say, a rename will also work for the syntactic fn:

static member PPush (stack : Stack<'T>) elem = stack.Push(elem)

By on 2/2/2011 6:13 PM ()

As per the spec, 8.13.7 Overloading of methods:

[link:research.microsoft.com]

Methods that take curried arguments may not be overloaded.

see also Arity Inference in 14.10:

[link:research.microsoft.com]

for more to grok what's going on.

By on 2/2/2011 6:26 PM ()

I had a feeling something with the way the curried method was being compiled that would make it result with a signature exactly like the one already being defined, probably why curried methods shouldn't be overload to begin with. But in this case I still believed that it should still work, as the method I am defining is a static method, and the other is instance method, and you should be able to tell the difference between the two depending how the method is being called, also considering that "static void foo(int)" isn't exactly the same signature as just "void foo(int)". C# gets confused between the two as well though, which is sort of making me believe there's something more going on as to why you some how can't distinguish between the two... Or maybe you can and it's just not being done?

By on 2/3/2011 2:41 PM ()

you should be able to tell the difference between the two depending how the method is being called

At least for C# this isn't true - think of the body of an instance method. And I guess it's generally a bad idea for documentation reasons.

By on 2/4/2011 3:09 PM ()

It probably is a bad idea, but interesting to know that F# can tell the difference. This code compiles and runs just as expected:

1
2
3
4
5
6
7
8
9
10

type foo () =
    member x.bar () = 1
    static member public bar () = 2


let f = new foo()


f.bar() //returns 1
foo.bar() //returns 2

So there's another difference between the two. I still find it very restrictive that method overloads can't be curried the natural way, all because of the peculiarities of how methods get compiled, even when the interpretation doesn't conflict with other overloads. Granted, when working with types and objects in an OO manner, you'd probably wouldn't write methods like this, and there seem to be other ways to do what I sorta originally intended to do.Sort of a nice dissection into the language so far though. :)

By on 2/4/2011 10:58 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