Dan Piponi wrote: > I must be missing the point of something. What's wrong with > > > diff f x = let AD y dy = f (AD x 1) in dy > > ? > > In ghci we get > > *Main> :t diff (\x -> 2*x) (2::Int) > diff (\x -> 2*x) (2::Int) :: Int > *Main> :t diff (\x -> 2*x) (2::Float) > diff (\x -> 2*x) (2::Float) :: Float > > I've used almost exactly that line of code myself a few times.
Yep, that does what I want. Thank you (and Stefan, and ghci's :t) for pointing it out. If this were a practical thing, I'd certainly decide that's the best option and move on. But since this is me trying to figure out the Right Answer (tm), that still doesn't look like it. (Though I suspect if there were a Right Answer, it would have been pointed out by now.) >From my perspective, what's wrong with it what Stefan mentioned when he suggested it: it breaks abstraction. Even if I don't expose the type AD (i.e., it's an implementation detail and the user of a library shouldn't care that it even exists), the inferred type signature for diff depends on it. Prelude AD> :t diff diff :: forall a t. (Num a) => (AD.AD a -> AD.AD t) -> a -> t But what's AD? If it's exported, then at least it will show up in Haddock with a list of its instances, so the type is merely misleading. but if it's not exported, then the type is just plain not useful. So I want the parameter to be more restricted. No one is going to write a function that *only* works on AD types. Instead, the parameter to diff ought to be required to be polymorphic. The rank n type does that, but it loses the ability to get the most general possible result type. -- Chris Smith _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe