Edward Kmett
Edward Kmett
this is very high on my wishlist
I don't see this issue ever going away with Haskell's notion of `(*) :: Num a => a -> a -> a` requiring both sides to have the same type....
`(*^)` multiplies whatever the 'scalar' type is for the mode, treating the ad type as an algebra over the basic scalar. It already exists inside Numeric.AD.Mode (or Jacobian). basically it...
I frankly don't see a plausible way to do unify these things. Yes, types get in the way some times, and in this case they force a distinction. You could...
The only way this is going to change is if we adopt something like #2, which would have pretty far reaching consequences on the API. I'll leave this issue open...
Losing access to AD over arbitrary Num types isn't really an option. A number of the users of this library use it at some pretty exotic types! You can avoid...
The "brand" can't float in the constraint without actually showing up in a type somewhere. You could almost kind of fake it with implicit parameters, but then they'd yield totally...
We don't have any plans at present. If you'd like to toss one our way I'm wholly on board.
I anticipate that this package would not be the best initial guinea pig for such a practice.
I'm pretty negative on this one. From a practical standpoint, this would cause a pretty awful upheaval in terms of where everything gets hosted. `FunctorWithIndex` lives in `lens` of all...