I've applied your patch, by the way... David
On Tue, Jul 29, 2008 at 12:09 PM, David Roundy <[EMAIL PROTECTED]> wrote: > Argh. This is a rather annoying regression. Too bad that SPJ doesn't > see it as such! :( But it seems that type inference in monads is > still safe, so I guess we haven't completely lost the ability to use > type inference with gadts... > > David > > On Tue, Jul 29, 2008 at 11:24:28AM -0700, Jason Dagit wrote: >> I think I didn't use the reply all correctly. >> >> Jason >> >> ---------- Forwarded message ---------- >> From: Jason Dagit <[EMAIL PROTECTED]> >> Date: Tue, Jul 29, 2008 at 11:12 AM >> Subject: Re: [darcs-users] darcs patch: fix type witness compile errors >> specific to ghc 6.8 >> To: [email protected] >> >> >> >> >> On Tue, Jul 29, 2008 at 10:24 AM, David Roundy <[EMAIL PROTECTED]> wrote: >> >> > Jason, >> > >> > I'm willing to accept this patch after you've tried one possible fix >> > that would avoid this ugliness. Could you try replacing the $ >> > operator with parentheses instead of defining new functions for these >> > fixes? e.g. >> > >> > > -mergeUnravelled ws = case reverseFL `fmap` mergeConflictingNons >> > > - (map sealed2non $ filter >> > notNullS ws) of >> > > +mergeUnravelled ws = case mergeUnravelled_private ws of >> > >> > would become >> > >> > mergeUnravelled ws = case reverseFL `fmap` mergeConflictingNons >> > (map sealed2non (filter >> > notNullS ws)) of >> > >> > and >> > >> > > - mcn [Sealed p] = case sort_coalesceFL $ effect p of -- this is >> > just a safety check, and could >> > > - NilFL -> Just p -- be >> > removed when we're sure of the code. >> > > + mcn [Sealed p] = case sort_coalesce_effects p of -- this is >> > just a safety check, and could >> > > + NilFL -> Just p -- be >> > >> > would become >> > >> > mcn [Sealed p] = case sort_coalesceFL (effect p) of -- this is ... >> > >> > I'm not sure that this will make things work with 6.8 (since I don't >> > have ghc 6.8), but it would address the only plausible problem I can >> > see with the current code (which is considerably prettier than your >> > fixes). >> > >> > If these fixes don't work (as I mentioned above), I'll apply this >> > patch. >> >> >> Unfortunately for [case ... of ...], in GHC 6.8, and newer, more type >> annotations are required. Simon had this to say about it: >> >> http://www.haskell.org/pipermail/glasgow-haskell-users/2008-July/015102.html >> >> I've read the paper that he linked, which is helpful, but since I'm not much >> of a type theorist I'm having trouble applying some of it. What I mean is >> that, there may be a prettier way to sneak in the rigid types (essentially >> type annotations), but this was the first one I found that works. I tried >> removing ($) but that definitely didn't work out. >> >> The good news is that 90% of the type witness code we have doesn't rely >> heavily on `case` and hasn't required any updates to work on GHC 6.8 and >> newer. Also, it seems that the way 6.6 did the type inference was "wrong" >> and we can count on the way 6.8 does things to be the new status quo. But, >> the downside is that (.) seems to be somewhat allergic to case expressions >> in the presence of GADTs. >> >> Adding new functions was just the quickest way to fix this. Given that >> sort_coalesce_effects shows up so much in that one module, maybe it's not >> such a bad thing to define. Sort of like having, for instance, the zip >> function that is really just an abbreviation for zipWith (,). >> >> I hope that helps, >> Jason > > -- > David Roundy > Department of Physics > Oregon State University > _______________________________________________ > darcs-users mailing list > [email protected] > http://lists.osuosl.org/mailman/listinfo/darcs-users > _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
