Automatic wrapping of specialized methods, solve many ambiguities

[manuelbb-upb]

This is a WIP/proposal to solve some ambiguity issues, like #575 or #635.
These arise, because the methods defined with the @wraped macro compete with very specialized methods, possibly from sub-modules.

In contrast to #811, this approach does not need a dedicated dispatch context.
Instead, the function specialize_methods looks up all methods currently available for a specified function and iteratively defines methods for the corresponding symbolically wrapped types.
Thus, the behavior of specialize_methods is load order dependent.
We could call it ourselves or leave it up to the user.

In this first draft:

• specialize_methods only creates definitions for matrix-vector and matrix-matrix products and delegates the work to _matvec and _matmul, respectively. The examples from the issues above seem to work now.
• ExprTools.jl is used to parse method information. I started using ExprTools because of convenience and to leverage the existing code for @wrapped, which is only slightly modified.
• However, the current approach does not allow for incremental precompilation. I am also not sure if that is feasible, but I think we could try to work with the method signatures directly, to access argument types and avoid the hacky evaluation I currently use, which requires evaluation into sub-modules. This would require a bit of re-writing.
• specialize_methods() is executed in the modules __init__ function and the tests appear to pass locally.

[shashi]

What happens if methods are added by a third party package after @warpped has executed?

[manuelbb-upb]

Then specialize_methods would have to be called again. This sort of load-order dependence is also observed in Hyperspecialize, and the only way around it seems the Cassette approach.
Actually, the code in this pull request is not too different from what Hyperspecialize can do, except that some of the Matrix or Vector types occurring in method definitions can be super special, so I had to either traverse the whole type tree and gather every possible subtype for Hyperspecialize's @concretize or inspect the method signatures (what is done now).

However, there are a few things we can do with respect to the points in your other comment:

All relevant types in Base/stdlib should be made to work with the wrapped types defined in this package

specialize_methods accepts a list of modules with argument mods. When calling it in __init__() we can restrict ourselves to LinearAlgebra and other relevant standard modules.

Taking this further if a new package wants to use its array or number types with Symbolics, wherever necessary, it should return the specializations manually or using a different macro.

What happens if methods are added by a third party package after @Warpped has executed?

Whenever a user has custom array types defined in a module, or there is a package with custom array types, specialize_methods can be called with mods set accordingly to automatically “widen”/wrap the relevant definitions to have a generic fallback. This way, the developer does not have to know that Base.:(*)(::AbstractMatrix, ::AbstractVector) should redirect to _matmul most of the time.
If, for example, I get a StaticMatrix somewhere in my computations, then I cannot use it with symbolic arrays:

using Symbolics
using StaticArrays
A = @SMatrix(rand(2,2)) # imagine this is obtained somewhere else
@variables (x::Real)[1:2]
A * x # ERROR: MethodError: *(::SMatrix{2, 2, Float64, 4}, ::Symbolics.Arr{Num, 1}) is ambiguous.

But after
Symbolics.specialize_methods(StaticArrays)
it just works.

For some widely used packages (such as StaticArrays) we could even do this ourselves with @require. Conversely, a package author could opt to place Symbolics.specialize_methods(@__MODULE__) in their __init__, though I have to think about scopes and export statements a bit more.

Going forward, I can try to benchmark the impact of specialize_methods in __init__ (for different values of mods) and maybe devise some tests.

[manuelbb-upb]

Quick update for anyone following/reading: There are pre-compilation issues. I'll try to work them out, and maybe try avoiding working with eval/@eval so much.