Actually, I was thinking more along the lines of Data.Traversable.sequence, which has
sequence :: (Traversable t, Monad m) => t (m a) -> m (t a)
Are you expecting c1 (:: * -> * -> *) to unify with [] (:: * -> *)? That seems kind incorrect at the very last. Additionally, those types don't look all that close.
Well, as I said, replacing one term with another transforms one signature into the other. I guess you can't curry type constructors as easily as functions - or at least, Hoogle currently doesn't like it.
Yes, currying of type constructors is much less common, and entirely unsupported by Hoogle. Is there a general need for Hoogle to deal with curried type constructors? I'd not really considered it significantly.
But, let's briefly consider unification (and why Hoogle doesn't used it). Consider the search:
Eq a => [(a,b)] -> a -> b
What the user wants is lookup, which sadly doesn't unify. However, undefined unifies perfectly.
I see...
I notice that x -> y doesn't unify with y -> x in any way, shape or form, but Hoogle has absolutely no problem with that.
Hoogle has a problem with it, but not a severe problem. If you use the command line version you can type --verbose to get a list of the penalty points Hoogle has applied to a match.
What *does* Hoogle actually use for matching? Just a set of huristics and a metric for how "similar" two signatures are so it can order by approximate similarity? Or is it something more scientific than that?
It's more scientific than that, see http://www.wellquite.org/anglohaskell2008/ There will be a paper on Hoogle type matching at some point! Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================