[Haskell-cafe] testing if values can be applied to polymorphic functions
mgsloan at gmail.com
Thu Oct 25 01:32:10 CEST 2012
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:
Apparently this was unnecessary because the GhcLive stuff for diagrams
doesn't need to do this - and instead makes clever usage of
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
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.
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:
> 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
> 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
> 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
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe