Redesign fullmaterialize

[dlfivefifty]

I'm in the process of simplifying LazyArrays.jl, and its a good opportunity to revisit fullmaterialize.

I was thinking the following design, which adds a flag to let us know if something is simplifiable:

simplify(A...) = _simplify(simplifiable(most(A)...), simplifiable(tail(A)...), A...)
_simplify(::Val{false}, ::Val{false}, A...) = A
_simplify(::Val{true}, _, A...) = simplify(simplify(most(A)...)..., last(A))
_simplify(::Val{false}, ::Val{true}, A...) = simplify(first(A), simplify(tail(A)...)...)

_or(::Val{true}, _) = Val(true)
_or(::Val{false}, ::Val{true}) = Val(true)
_or(_, _) = Val(false)
simplifiable() = Val(false)
simplifiable(A...) = _or(simplifiable(most(A)...), simplifiable(tail(A)...))

The @simplify macro then would define both simplifiable and simplify for the arguments. That is, @simplify *(D::Derivative, F::Fourier) = ... would produce the following:

*(D::Derivative, F::Fourier) = ...
simplifiable(::Derivative, ::Fourier) = Val(true)
simplify(D::Derivative, F::Fourier) = D*F

The end result is a much cleaner implementation, that will be type stable.

@jagot any opinions?

[jagot]

I think it looks nice! Is this also the place where we take care of restrictions leading to zero-padded coefficient vectors? E.g. JuliaApproximation/CompactBases.jl#3

How does this relate to my PR JuliaArrays/LazyArrays.jl#91? I.e. is there some common benefit we could leverage?