Why compiler can't choose between overload of fun, cloref and cloptr at call site

[Russoul]

Suppose we have "list0_map_fun, list0_map_cloref, list0_map_cloptr" higher order functions.

And then we overload "list0_map" with all those. Why compiler gives : "the symbol [list0_map] cannot be resolved due to too many matches" when used with one of [fun,cloref,clopth] function types ?

[gmhwxi]

Because this kind of information is not used to resolve overloading.

Imagine that you write

list0_map(xs, lam(x) => ...)

It is not clear whether 'lam(x) => ...' is a function, closure or linear closure.

[Russoul]

But one can specify the type like that : "lam(x) =<fun1> ...", no ?

вторник, 24 октября 2017 г., 18:17:16 UTC+3 пользователь gmhwxi написал:

[gmhwxi]

Yes, you can.

But this looks "unconventional". I remember that ATS did use function/cloref
information to resolve overloading at some point, but it did not do well in practice
as users were often confused when overloading did not work as they had expected.

For functional programming (with GC), one really just need list0_map_cloref.

For a setting where GC is not supported or desirable, one should probably use the
template version of list_map.

[Russoul]

Ok, then is there a way to cast 'fun' to 'cloref' ?

For example, in this scenario: "list0_map_cloref(xs, println)"

Only this way : "list0_map_cloref(xs, lam x => println x)" ?

The first line just looks more natural

вторник, 24 октября 2017 г., 19:05:16 UTC+3 пользователь gmhwxi написал:

[Russoul]

There should be 'foreach' in above example

вторник, 24 октября 2017 г., 19:19:22 UTC+3 пользователь Russoul написал:

[gmhwxi]

>>Only this way : "list0_map_cloref(xs, lam x => println x)" ?

Yes.