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/a95136c7eae025b10507cb897f422c... 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 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe