Mitchell, Neil wrote:
>> 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.
>
And I had just "assumed" this would work. If I ask for a function x -> y
Hoogle manages to offer my functions like k -> x -> y which can be
curried to give me the thing I want, I just assumed that an equivilent
type wouldn't phase it. Ah well.
>> 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/>
I had a look at your slides. Looks like interesting stuff!
Irritating as it is that Hoogle didn't help me find the function I
wanted on this occasion, I still think it's really neat that a program
like Hoogle can actually exist in the first place. And considering that
with parametric polymorphism, the type signature "almost" tells you what
the function does... very useful stuff.
For my current troubles, it would be really useful if there were some
program that you could feed some source code to, and it would tell you
what the inferred types of each subexpression are. (Ideally it would be
nice if you could use this on fragments that don't typecheck; being able
to see what types are being inferred where could help explain why the
type checker is unhappy, and ultimately where you went wrong. But I'm
not sure how you could present the internal state in a digestible way.)
I don't know if anybody has ever attempted such a tool...?