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