Support function overloading in functions block

[yizhang-yiz]

Summary:

Currently overloading function in functions{} causes parsing error. Fixing this provides better UI.

Description:

This doesn't work

functions {
  real foo(real[] y0);
  real foo(real[,] y0);
}
...

The fix is to have a single functor for foo which overloads operator().

Current Output:

Parse Error.  Function already declared, name=foo

Expected Output:

Parse successfully.

Current Version:

v2.18.0

[VMatthijs]

I'm not sure I agree this is a good idea. Function overloading greatly complicates compiler design and might stall progress on other features we care about. There's a good reason a lot of strongly typed languages (e.g. OCaml) disallow this. There are principled solutions to allowing overloading, like type classes and modular implicits, but they are complicated. The current setup of only allowing library functions to be overloaded is already a bit tricky, but it's workable.

[bob-carpenter]

It was not a principled decision to disallow overloading, I just never got around to implementing it. I have a strong preference for supporting overloading. Users keep trying it and getting tripped up. Without overloading, users can't implement our library functions. Is the complication just due to type inference? We should be dealing with overloads the same way as C++, requiring a unique least-promoted match. So if you have foo(int, double) and foo(double, int) and try to pass foo(int, int), it's a mistake, because it's ambiguous.

…

On Dec 13, 2018, at 7:47 AM, Matthijs Vákár ***@***.***> wrote: I'm not sure I agree this is a good idea. Function overloading greatly complicates compiler design and might stall progress on other features we care about. There's a good reason a lot of strongly typed languages (e.g. OCaml) disallow this. There are principled solutions to allowing overloading, like type classes and modular implicits, but they are complicated. The current setup of only allowing library functions to be overloaded is already a bit tricky, but it's workable. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[VMatthijs]

Of course, it can be done. You'd have to carry around a set of possible types for each expression in the semantic check, rather than a single type. You might even want to use a lazy set, in case we have a combinatorial explosion of possible types. It'd probably be a decent amount of work to thread that through everywhere, especially as we also want subtyping int<real.

[bob-carpenter]

On Dec 13, 2018, at 9:46 AM, Matthijs Vákár ***@***.***> wrote: Of course, it can be done. You'd have to carry around a set of possible types for each expression in the semantic check, rather than a single type.

That's exactly what we do now. And it's what you must be doing with the built-in types already.

You might even want to use a lazy set, in case we have a combinatorial explosion of possible types. It'd probably be a decent amount of work to thread that through everywhere, especially as we also want subtyping int<real.

We not only want to subtype int < real, we also want int[] < real[], and so on up for all the array types. I never got fully covariant typing going, though it's been on my to-do list from the get-go.

[WardBrian]

Closed by stan-dev/stanc3#1027