The current entangling of the concepts of Mode and infinitesimal mean that every user of the AD library has to dispatch virtually everything that want to do with an AD variable via a dictionary. While this provides unusually strong guarantees, that only the properties that AD s a inherits from Mode s and the underlying numeric type a can be used, it means that the resulting code can be considerably slower than would be otherwise possible.
We could adjust AD to have separate mode and infinitesimal attributes, and adjust UU, UF, FU, FF to have MUU MUF MFU MFF variants that accept a mode, so that most of the combinators do the right thing. The cost of this is that we need to be more careful about all the extraneous instances that our Modes have picked up, and which properties we allow AD to inherit.
To obtain something approximating the current level of safety, we'll have to remove a lot of current instances and hide the AD data constructor.
Split Mode and infinitessimal into 2 different parameters
This might just be me not quite understanding some of this, but does the past days pull request also address the safety issue alluded to in this ticket? The Types have all been generalized/modified, but I don't see any changes in whats exported. Is the api safety matter superfluous?
We still need to go through and make sure most of the more egregious out-of-scope behavior is managed correctly. I haven't done a sanity check pass yet, which is why it hasn't been released to hackage.