make `any` and `all` interface consistent with `map`

[bjarthur]

i'm not sure whether it's better to ask this on Discourse, but has it been discussed to have Function{N} where N is the number of input arguments?

my use case is that i'd like to make the interface to any and all consistent with that of map. currently, the predicate versions of the former can not take a variable number of iterables like the latter can. rather, you have to manually zip them up. no big deal, but consistency is nice.

the problem is that any and all have methods which specialize on Arrays and regions. and so a simple change of the signature to end with a var arg gets confused when there are exactly two. a conceptually simple fix to this would be to dispatch on how many input args the predicate took.

[tkelman]

or make dims a keyword argument for the array/region signatures...

[ararslan]

Functions have their own types, but any function can be defined to have arbitrarily many methods with any number of arguments. So saying that, for example, typeof(+) <: Function{2}, isn't really meaningful; + is intuitively binary but you can define +(a, b, c), at which point typeof(+) would no longer be a subtype of Function{2}. Perhaps I'm misunderstanding your request, but it seems to me that what you're describing would require a massive change to the type system.

[pkofod]

Functions have their own types, but any function can be defined to have arbitrarily many methods with any number of arguments.

I the suggestion in this issue might come from a misunderstanding of the differences between a function and a method.

[JeffBezanson]

This is basically #17168 and #16191.
If changing the behavior of any and all specifically is considered useful, we can make this issue about that.

[bjarthur]

great to see parameterizing Function has already been discussed.

using a dims keyword would make the interface inconsistent with mean and friends.

title of this issue changed to reflect the desire to make any and all consistent with map.

[tkelman]

using a dims keyword would make the interface inconsistent with mean and friends.

Not if we also switched to using a dims keyword for mean and friends at the same time.

[nalimilan]

Wouldn't a keyword argument incur too large a penatly for all and any?

[bjarthur]

changing mean and friends to use a keyword for the region would be hugely disruptive. i'd suggest doing that only if it is decided to not parameterize Function.

@nalimilan it's not clear to me from the performance tips whether or not there is a penalty for keyword args. it says there is not if you call a function that has them with only positional args, but what if you call that same function with them?

lastly, could someone please elaborate on why Function types and generic functions are like oil and water ?

[nalimilan]

The best way to find out whether the penalty is significant is to do some benchmarking.

[JeffBezanson]

could someone please elaborate on why Function types and generic functions are like oil and water ?

See section 4.6 of https://github.com/JeffBezanson/phdthesis/blob/master/main.pdf.