Duck type the function in map, reduce, etc.

[timholy]

Now that we have call-overloading, it would be nice to be able to use it in functions like map, reduce, etc. However, call-overloaded objects can be of any type, which makes it seem necessary to duck-type the "function" passed as an argument to map and friends.

The main design criterion in this PR was to avoid method ambiguities, particularly with packages that might overload either the "function type," the "container type," or both. For better or worse, I therefore decided to make it trivial to overload these by making the exported symbols basically not use any kind of typing, and to perform dispatch on the container through a non-exported family of functions with a c on the end.

[JeffBezanson]

I do agree with the duck typing part. Soon we will want to make Function an abstract type as well.
Beyond that, this solution is hard to love. You can still have ambiguities between packages if some overload map on the function and others on the container. I also think overloading map on the type of function should be quite unusual; clearly the container owns the operation more.

[timholy]

You can still have ambiguities between packages if some overload map on the function and others on the container.

Sure, but this doesn't change that---it's always been that way.

I also think overloading map on the type of function should be quite unusual; clearly the container owns the operation more.

It is, but existing constructs like filter(r::Regex, v) need to be dealt with. Have an alternative suggestion? I'd love it if we didn't need filterc to handle this.

[JeffBezanson]

My solution would be to leave it alone for now :)

I find the filter(::Regex, x) methods very odd. I don't know why there would be a built-in method for filtering the keys of a dictionary by a regex. That seems extremely special-case. Those methods certainly predate call overloading, so maybe we should instead overload call to make regexes act like predicates. Or maybe just remove those methods entirely.

My "textbook" answer to explain the ambiguity of filter(::Regex, ) is that the overloading is being done at the wrong level: this method doesn't exist to replace the code for filter, but to supply a meaning for "calling" a Regex.

[timholy]

My solution would be to leave it alone for now :)

If that means we can expect something soon, I'm all in favor :). But actually soon, not "someday" :).

[JeffBezanson]

Not promising anything amazing, I just don't think we should rush to add mapc and filterc. I also highly question those Regex methods.

[timholy]

Well, all that is fair---and I agree with you on the Regex method. How about I explore how many methods need to be deleted to avoid ambiguities without introducing mapc and friends.

[StefanKarpinski]

Not promising anything amazing, I just don't think we should rush to add mapc and filterc. I also highly question those Regex methods.

Jeff, everything you do is amazing.

[timholy]

Wow, I'm glad you balked. It turns out that Regex method was the only problem spot. See #10314.