Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

function overloading #5303

Closed
vicuna opened this issue Jun 28, 2011 · 7 comments
Closed

function overloading #5303

vicuna opened this issue Jun 28, 2011 · 7 comments

Comments

@vicuna
Copy link

vicuna commented Jun 28, 2011

Original bug ID: 5303
Reporter: 0x69
Status: closed (set by @xavierleroy on 2013-08-31T10:44:18Z)
Resolution: won't fix
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @protz

Bug description

It would be VERY useful for developers to have function overloading.
I know this has some big pressure for compiler - type inference could be confused with overloading, but... what if we force the user to specify function parameter types to let compiler infer types correctly ?
for example there could be OVERLOAD keyword:

let (overload +) (x:int) (y:int) = x+y
let (overload +) (x:float) (y:float) = x+.y

In this case compiler could generate two separate functions
+_int_int
+_float_float
and inline that function which is appropriate by it's parameter types...

Thanks.

@vicuna
Copy link
Author

vicuna commented Dec 29, 2011

Comment author: @damiendoligez

Thanks for the suggestion, but overloading is a bit more complex than it seems.

To begin with, what happens when I write:

let (overload +) (x:int) (y:int) = x+y
let (overload +) (x:float) (y:float) = x+.y
let f x y z = x + y + z

@vicuna
Copy link
Author

vicuna commented Dec 30, 2011

Comment author: pilki

@0x69 : basically, what Damien Doligez is saying is that the problem of type inference and overloading is not at the definition of the overloaded function, but where you use it. The type annotation you want to add at the definition of the function are useless: the compiler can find them easily:

<<<<

let ((overloaded)+) x y = x + y;;

val ( + ) : int -> int -> int =

let ((overloaded)+) x y = x +. y;;

val ( + ) : float -> float -> float =

The problem is to find which function to use when you call "+".

It is worth noting that some feature of the recent releases of OCaml remove some of the burden:

<<<
module Float = struct
let (+) x y = x +. y
let (-) x y = x -. y
let ( * ) x y = x *. y
let ( / ) x y = x /. y
end

module Int = struct
let (+) x y = x + y
let (-) x y = x - y
let ( * ) x y = x * y
let ( / ) x y = x / y
end

let foo x y = Float.(x + y * 3.)

let bar x y =
let open Float in
42.3 * y + x

<<<
val foo : float -> float -> float =
val bar : float -> float -> float =

What you may want to do is to add a feature request for a unified interface of numerical operations and the corresponding modules for float, int, int32, int64 and bignums. You could even probably provide the patch for it ;)

Cheers

@vicuna
Copy link
Author

vicuna commented Dec 30, 2011

Comment author: meyer

Hi,

For this I raised:

#5458

Thanks,
Wojciech

@vicuna
Copy link
Author

vicuna commented Dec 30, 2011

Comment author: 0x69

To begin with, what happens when I write:

let (overload +) (x:int) (y:int) = x+y
let (overload +) (x:float) (y:float) = x+.y
let f x y z = x + y + z

If compiler can't deduce what overloaded version of operator to use - it can through an error forcing user to write type annotations:

let f (x:float) (y:float) (z:float) = x + y + z

I think type annotation is good idea. Somethimes it also helps increase code readability. But of course as @pilki showed new module system for types-

"let foo x y = Float.(x + y * 3.)"

is also a good solution ...

(But still i would prefer type specialization over operator specialization, maybe because i came from F# world :-). But others preferences can be different of course...)

@vicuna
Copy link
Author

vicuna commented Dec 30, 2011

Comment author: meyer

The reason why F# needs to support overloading because of it tight integration with .NET where the overloading is ubiqious.

Overloading with type inference is best accomplished with type classes - like in Haskell world (it's worth to note that Coq has also typeclasses!) - where you define a common interface (type class) and then the instance of it for each abstract data type that implements it. Therefore, Haskell type system is able to infer (with some extra type annotations) that the type belongs to this type class and apply the right function from the instance.

However ad-hoc polymorphism comes with the cost of extra annotations, and is quite ortogonal to how the ML style (parametric polymorphism) module system works.

As you noted as Haskell needs some boilerplate and annotations where the typeclasses are defined, in contrast to ML, where you need these special "annotations" where you use the functions or operators.

@vicuna
Copy link
Author

vicuna commented Dec 30, 2011

Comment author: @protz

Just for the record, I think this is precisely what gcaml http://www.yl.is.s.u-tokyo.ac.jp/~furuse/gcaml/ tries to achieve.

@vicuna
Copy link
Author

vicuna commented Jan 2, 2012

Comment author: @Chris00

For the record: http://www.lexifi.com/blog/implicit-values

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant