[Haskell-cafe] Hoogle? [Stacking monads]
neil.mitchell.2 at credit-suisse.com
Tue Oct 7 03:33:43 EDT 2008
> 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
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
There will be a paper on Hoogle type matching at some point!
Please access the attached hyperlink for an important electronic communications disclaimer:
More information about the Haskell-Cafe