Back to Questions
2.2k
views14
comments
F# does not support same function name?
f#

hi, group

In C#, i can declare two functions whose function signatures are different. For exmaple

public void A(int a) and public void A(string a) are good.

i tried to define

let FunctionA x = ....

let FunctionA (x:BigInt) = .

Compiler gives me an error saying duplicated FunctionA. Is that possible to do this? Or I have to some tricks?

Thanks

.

hi, group

In C#, i can declare two functions whose function signatures are different. For exmaple

public void A(int a) and public void A(string a) are good.

i tried to define

let FunctionA x = ....

let FunctionA (x:BigInt) = .

Compiler gives me an error saying duplicated FunctionA. Is that possible to do this? Or I have to some tricks?

Thanks

Hello,

In addition to the technical "how to" answer, I would like to point out the point of using F# is precisely that it is not C#. Functional programming languages are completely different from imperative/procedural ones. I like the analogy used in Tomas Petricek's book:

"Run the first command for every customer for which the second command returns true." (C#)
"Show customer details of every customer living in UK." (F#)

You have two fundamentally different ways of looking at the same problem. If (like most of us) you are used to thinking of programming in terms of defining objects and incrementally changing the state of those objects in order to arrive at a desired outcome, then functional programming may be daunting. But then, if it was easy -- why do it? ;-)

It seems likely, therefore, that by "overloading" functions in F#, you may be trying to apply C# methodology in the wrong place. You may want to look at this: Functional Programming in the Real World.

Thanks.

mp

By on 5/20/2009 4:19 AM ()

There's nothing intrinsically "unfunctional" about overloading, at least not by my definition of functional.

And by the way: F# is not a purely functional language -- for good reasons.

By on 5/20/2009 4:34 AM ()

Hi!

>> There's nothing intrinsically "unfunctional" about
>> overloading, at least not by my definition of functional.

I'd certaingly agree with that. Just to clarify why (IMHO) overloading doesn't work that well in F# is another important aspect - the use of type inference (including of course overloaded methods, which means that you often need type annotations when working with existing .NET classes). For example:

1
2
3

let download(url) = 
  let req = HttpWebRequest.Create(url)
  // ...

... will complain because there are multiple overloads of the "Create" method and the type inference doesn't know which one to choose. Alternatively, you can use named & optional parameters (As far as I know currently supported only for members):

1
2
3
4
5
6
7
8
9

 
type Test() =
    member self.Foo(x, ?y) = 
      printfn "%d %d" x (match y with None -> 0 | Some(d) -> d)

let t = new Test()
t.Foo(10)
t.Foo(10, 20)
t.Foo(10, y=20);;

.. but this will of course work only when overloading using the number of parameters.

By on 5/20/2009 5:25 AM ()

This is possible by using the OverloadID attribute. Your example would look like this:

[<OverloadID("function SomeType")>]
let FunctionA x = ....

[<OverloadID("function BigInt")>]
let FunctionA (x:BigInt) = ....

-Chris

By on 5/18/2009 10:19 AM ()

Thanks, Chris.

This is not very nice though. From a person from C# side, we would treat this like a standard behavior.

By on 5/18/2009 10:41 AM ()

Thanks, Chris.

This is not very nice though. From a person from C# side, we would treat this like a standard behavior.

What you're talking about is formally known as ad-hoc polymorphism, more commonly known as "overloading". What you need to understand is implementing ad-hoc polymorphism is non-trivial with type inference (maybe even undecidable in some cases, i'm not a type theorist) without some mechnism to make ad-hoc polymorphism less ad-hoc.

F# is a fully type inferred language, languages such as C# do not support full (or even any form of) type inference only limited form of local inference/deduction.

There are methods of taming ad-hoc polymorphism while still supporting (almost) full type inference (even inferring type constraints of parametric polymorphism) but they are all pretty much a more explicit method than languages that don't have to deal with the issue.

Haskell supports overloading using something called type classes. If i remember correctly Don Syme is investigating other methods that would give us type inferred overloading support but without the full power of type-classes (they are used for more than overloading).

Since dotnet libraries tend to have overloaded methods F# must support method overloading hence this less than ideal method for now.

By on 5/18/2009 11:11 AM ()

AFAIK, you can only overload methods with the OverloadID attribute, not free functions, or am I missing something?

I'm curious too why one has to manually annotate overloaded methods with the OverloadID attribute. Why can't the compiler simply give each overload a unique id as soon as more than one with the same arity is defined? Do the language designers want to discourage users from using overloaded methods?

By on 5/18/2009 11:30 AM ()

AFAIK, you can only overload methods with the OverloadID attribute, not free functions, or am I missing something?

I'm curious too why one has to manually annotate overloaded methods with the OverloadID attribute. Why can't the compiler simply give each overload a unique id as soon as more than one with the same arity is defined? Do the language designers want to discourage users from using overloaded methods?

@Stephan - My bad on this one, I forgot that the OverloadID attribute can't be used on let bound functions.

By on 5/18/2009 9:56 PM ()

@snk_kid: that might mean that we have to provide

explicit type annotations to overloaded methods and functions, but it

seems providing the overloadId really should be the compiler's

job.

The F# specification states you can't use the OverloadID

attribute without a type signature or explicit type of parameters

anyways.

Without some form of explicit "annotation" and/or some form of explicit type signature how do you expect to infer types without dis-ambiguity? if you don't have a type signature for each overload it's going to make the "compiler's job" very difficult to unify to the correct type(s) and actually compile, maybe even impossible to unify.

Try it yourself, see if you can infer the types of overloaded function names without type signatures, both monomorphic and polymorphic functions.

As far I can see just "enumerating" each definition you see and/or based off of contextual usage (function definition) isn't enough

It looks like without the OverloadID

or some other method you're back to the same problem you originally started with.

I'm not a compiler writer or type theorist anyways I'm sure Don can make light of it all.

AFAIK, you can only overload methods with the OverloadID attribute, not free functions, or am I missing something?

Yes it's only for methods not let bound functions.

Do the language designers want to discourage users from using overloaded methods?

I don't think so, it's ad-hoc polymorphism in the presence of polymorphic type inference which is the problem as I mentioned earlier.

By on 5/18/2009 11:56 AM ()

Hi all,

The need for OverloadID is a purely cosmetic thing and it will be removed in a future version of the language. We've actually done the work internally, but it didn't make the cut for the upcoming Beta1 release (which will be out very soon!), but the thing will be gone in the release after that. We promise :-)

Kind regards

don

By on 5/18/2009 12:10 PM ()

Hi all,

The need for OverloadID is a purely cosmetic thing and it will be removed in a future version of the language. We've actually done the work internally, but it didn't make the cut for the upcoming Beta1 release (which will be out very soon!), but the thing will be gone in the release after that. We promise :-)

Kind regards

don

Hi don, could you tell us is this still just for method overloads and not let bound functions? do you need to give explicit type signatures to make this work? did you guys come up with a method of some kind of lightweight type classes?

By on 5/18/2009 12:13 PM ()

Hi don, could you tell us is this still just for method overloads and not let bound functions? do you need to give explicit type signatures to make this work? did you guys come up with a method of some kind of lightweight type classes?

Yes, this is just for members - let-bound functions may not be overloaded.

The mechanics of overload resolution remain as they are today and as they will be in the Beta1 release, so there's nothing high tech here. The OverloadID is only needed in CTP and Beta1 as a unique internal name in the compiler - it is just engineering work to remove that limitation.

Kind regards

don

By on 5/19/2009 1:41 AM ()

Without some form of explicit "annotation" and/or some form of explicit type signature how do you expect to infer types without dis-ambiguity? if you don't have a type signature for each overload it's going to make the "compiler's job" very difficult to unify to the correct type(s) and actually compile, maybe even impossible to unify.

I understand the type inference problem, but my (and I think Stephan's) question is: can't the compiler generate the ID for the various overloaded methods automatically, relieving the programmer of inventing a few  random strings.

By on 5/18/2009 12:08 PM ()

@snk_kid: that might mean that we have to provide explicit type annotations to overloaded methods and functions, but it seems providing the overloadId really should be the compiler's job.

By on 5/18/2009 11:24 AM ()

    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