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
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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe