[Haskell-cafe] testing if values can be applied to polymorphic functions

[Michael Sloan]

Hey!

I was doing similar things with my project "haskellion" ( which I know
you've seen because you're the only one that's commented on it -
http://www.youtube.com/watch?v=gn_ZZiXVlNY&feature=plcp ).  I'm not
planning on getting back to work on it anytime soon (there's way too
much Haskell stuff I want to do and too little time!).  I'm glad
you're thinking about doing it - can't wait to see the results!

I found the code from ActiveHs to be nice for driving GHC / Hint.
Here's code from "diagrams-ghci" that asks GHC for the type, and
processes the type somewhat like defaulting:

https://github.com/mgsloan/diagrams-ghci/blob/a95136c7eae025b10507cb897f422cdbaf2f52bd/src/Interpret.hs

Apparently this was unnecessary because the GhcLive stuff for diagrams
doesn't need to do this - and instead makes clever usage of
defaulting.

Something to keep in mind is that when applying polymorphic things to
other things in this way, you'll actually succeed a lot of the time,
but get constraints that can't possibly be inhabited given your
current instances.  Getting a complete predicate for "isBogus ::
Constraint -> Bool" (figuring out if there exists a concrete type with
instances causing it to inhabit the constraint) seems like it would
require at least implementing typeclass instance resolution.  I
imagine some kind of search based on the same information that's
yielded by ":info" could fruitfully guide attempting to find a
datatype that fits the constraint (also, yielding this list could be
very useful!).

In most contexts, I don't think determining bogus constraints would be
that important - as long as you can assume that the "other" links
don't change - you can get a monomorphic type for the candidate link
even when building with polymorphic functions.  Forming the initial
links, however, would still be troublesome.

Hope my musings help a little!  I'd love to see more Haskell front-ends.

-Michael

On Mon, Oct 22, 2012 at 2:24 AM, alex <alex at slab.org> wrote:
> Hi all,
>
> A while ago I made an unusual visual front-end for Haskell:
>   http://www.youtube.com/watch?v=5KtFlGEVFGE
>   https://github.com/yaxu/texture
>
> It applies functions that are both proximal in Euclidean space, and
> type-compatible.  It 'compiles' to Haskell, piped into ghci, but I
> (probably unwisely) wrote it in C, and ended up having to implement
> some crazed version of the Haskell type system there to get it
> working.
>
> Now I have idea for making this more interesting and practical (for
> live music-making, if nothing else), and would like to re-write it all
> in Haskell.  Testing type compatibility of expressions is foxing me
> though.
>
> For example, say I have (++) and [1,2,3].  I then want to see if a
> value of type (Num a => [a]) can be applied to a function of type ([a]
> -> [a] -> [a]).  I've been looking at Data.Typeable.funResultTy to do
> this, e.g.:
>
> funResultTy (typeOf ((++) :: [a] -> [a] -> [a])) (typeOf ([1,2,3] ::
> Num a => [a]))
>
> But I get this:
> Ambiguous type variable `a0' in the constraint:
>       (Typeable a0) arising from a use of `typeOf'
>
> Being a bit more specific doesn't help:
>
> funResultTy (typeOf ((++) :: Typeable a => [a] -> [a] -> [a])) (typeOf
> ([1,2,3] :: (Typeable a, Num a) => [a]))
>
> I guess funResultTy doesn't work when polymorphism is involved..
>
> Perhaps I could just use the ghc-as-a-library stuff to parse and
> typecheck code - would that be the way forward?
>
> Any pointers much appreciated!
>
> Best wishes
>
> alex
>
> --
> http://yaxu.org/
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe