[Haskell-cafe] Hoogle? [Stacking monads]

Mitchell, Neil 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 
> 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

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 mailing list