Unimethod Functions

[ChrisRackauckas]

Julia's function have multiple methods. In many cases that is useful. In some cases, you really want to be able to talk about a function as though it has a single method. This an example of such questions from the Discourse:

https://discourse.julialang.org/t/classification-of-functions/4468

The issue is that "hacks" can be employed on the method table to make this "work", but it's generally not a feature which can be relied on in the language.

However, there are many cases where this kind of introspection on a function can be useful. Particularly the number of arguments. Scientific computing algorithms, like those in optimization and differential equations, try to use an in-place format when they can. However, that's not always possible. DifferentialEquations.jl does this by allowing two separate formats: an in-place and an out-of-place form for the function. The difference between these can be specified by the user, but DiffEq makes a guess by counting the maximum number of arguments for methods in the methods table. So far no one has complained because this kind of usage really is "a single function": you only make a single function to give to the optimizer or the diffeq solver.

Another case where this pops up is with FunctionWrappers, which is essentially such a unimethod function where the inputs and outputs are fully specified. Being able to use these types of functions can allow an optimization or diffeq routine not specialize on the function that is given to them, but without issues of inferability on the returned values (which comes up if it's placed in a type with no parameter. If it does have a parameter like struct{F}; f::F; end, then it specializes by function).

I think a nice syntax for handling this should be anonymous functions. Anonymous functions seem like unimethod functions, but they are not because call overloading lets you do silly stuff:

f = (x) -> 2
(::typeof(f))(x,y) = 3 # Adds a method

If this was disallowed, then the guarantees of a unimethod function can be placed on an anonymous function, making them more useful in certain cases (and can get their own abstract type?). Additionally, it seems that if one strictly typed a unimethod function, that can be similar to a FunctionWrapper, i.e. have its type defined just by the input and output types. This would make it not specialize though, so it might be weird for that to "randomly" occur, thus it could be more clear by making the FunctionWrapper version opt-in with some keyword.

[JeffBezanson]

I agree this would be a good feature. More generally, we could support "sealing" functions so no more methods can be added.

[yuyichao]

FunctionWrappers (and the proposed replacement in Base) will not need this at all. Sealing functions seems like a good feature but guessing what the function do by what method it supports sounds like a really bad idea.

[JeffBezanson]

guessing what the function do by what method it supports sounds like a really bad idea

Agreed.

And yes, we should consider function sealing, structural function typing (based on argument and return types), and other kinds of function introspection separately.