Didn't post this to the mailing list for the first time. Sorry for the mistake. —Alex
---------- Forwarded message ---------- From: Alexander Shpilkin <[email protected]> Date: Tue, Jul 26, 2011 at 5:04 PM Subject: Re: Fixing #186 (Non-exhaustive patterns in lambda) To: Ben Lippmeier <[email protected]> On Mon, Jul 25, 2011 at 7:57 AM, Ben Lippmeier <[email protected]> wrote: > > This is a correct error message, though I agree the explanation in the > message could be improved. > > Adding some parens to the offending line: > > println $ (("list " % list % " : ") $ show list) Aha, so ($) is right-associative (unlike Haskell), as it should be. Didn't notice this. > In the mergeClasses function of DDC.Solve.State.Merge, if we try to merge two > classes with differing classKind fields, we get a kind error. However, if > there are graph nodes containing type constructors (like String or (->)), or > type applications in the classTypeSources list, then we could also report > those. This would make the error messages easier to understand. > > Adding the following line to mergeClasses_kindMismatch gives: > liftIO $ putStrLn $ pprStrPlain $ map classTypeSources clss > > $ bin/ddc -c test/14-Desugar/15-Defix/T186-OperatorSourcePosition/Main.ds > [[((289 290), TSV (SVInst > ./test/14-Desugar/15-Defix/T186-OperatorSourcePosition/Main.ds:8:41 ($)))], > [(String, TSV (SVInst > ./test/14-Desugar/15-Defix/T186-OperatorSourcePosition/Main.ds:8:26 (%)))]] > > That shows the String constructor. Unfortunately we can't directly see the > (->) constructor because it's been applied to other types, eg (((((->) a1) > a2) e1) c1). However, given the classId of a class contributing to a kind > error, you could find the (->), or whatever by walking down the left spine of > type applications. There are utils in DDC.Solve.Walk for this. So, DDC.Solve.Walk.getClassDownLeftSpine really does find the constructor (after adjusting imports to eliminate the cyclic dependency). The two problems are that showing the constructor by itself may not be so helpful and that displaying a TypeSource in the general case requires quite a lot of code (cf. DDC.Solve.Location.dispTypeSource, which requires a Type value to be passed in too). However, at the same time dispFetterSource matches only a few constructors of TypeSource; I really don't understand which ones should be expected in the case of kindMismatch. I've also tried using DDC.Solve.Trace.traceTypeAsSquid to reconstruct the constraints, but this yielded a strange result: liftIO . putStrLn . pprStrPlain =<< traceTypeAsSquid (classId cls1) ==> *291 :- *232 = String %270, *287 = (->) *225, *289 = *287 *232, *291 = *289 !33 (which can be recovered to be something like (->) *225 (String %270) !33 :: $ -> *, though without any clues about *225, but is quite unusable as it is). Other possibilities I tried yield just (*289 !33) in one way or another. Is it possible to reconstruct the whole application at all? DDC seems to do quite a good job at displaying type signatures in type mismatch errors, but otherwise produces rather unusable type displays (see #181 or #161, for example). Regards, Alex -- Disciple-Cafe mailing list http://groups.google.com/group/disciple-cafe
