Hello,
On #807, one option that i did not see considered is the posibility of defining an available (if experimental) tagging API, with ForwardDiff.Tag as it's only available implementation in ForwardDiff, via an AbstractTag{F,V} supertype.
For example, one package implementing StaticTag{F,V} <: AbstractTag{F,V} (in particular, #807 (comment) without the fallback) could define their own static comparison mechanism, without compromising the current runtime capabilities that ForwardDiff already gives with their own Tag implementation, and erroring when there there is any ambiguity (closures of duals) instead of recurring to checking a global value.
Another example was an attempt done in #748. While the discussion on that PR was long and the PR was finally reverted, that PR inadvertly required following a currently private tagging API:
checktag≺- replacing most hardcoded Tag constructors by an overloadable
maketag method
While i agree that the current Tag mechanism is adequate for most automatic differentiation workloads, new use cases, like completely compiled evaluations, merit thinking about the current invariants baked in the package, in my opinion. In this context, the implementation of a tagging API just shifts the burden from the ForwardDiff developer to the developer of the tagging mechanism.
Hello,
On #807, one option that i did not see considered is the posibility of defining an available (if experimental) tagging API, with
ForwardDiff.Tagas it's only available implementation in ForwardDiff, via anAbstractTag{F,V}supertype.For example, one package implementing
StaticTag{F,V} <: AbstractTag{F,V}(in particular, #807 (comment) without the fallback) could define their own static comparison mechanism, without compromising the current runtime capabilities that ForwardDiff already gives with their ownTagimplementation, and erroring when there there is any ambiguity (closures of duals) instead of recurring to checking a global value.Another example was an attempt done in #748. While the discussion on that PR was long and the PR was finally reverted, that PR inadvertly required following a currently private tagging API:
checktag≺maketagmethodWhile i agree that the current
Tagmechanism is adequate for most automatic differentiation workloads, new use cases, like completely compiled evaluations, merit thinking about the current invariants baked in the package, in my opinion. In this context, the implementation of a tagging API just shifts the burden from the ForwardDiff developer to the developer of the tagging mechanism.