[darcs-users] darcs patch: fix type witness compile errors specific to ghc 6.8
Jason Dagit
dagit at codersbase.com
Tue Jul 29 18:12:40 UTC 2008
On Tue, Jul 29, 2008 at 10:24 AM, David Roundy <droundy at darcs.net> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osuosl.org/pipermail/darcs-users/attachments/20080729/714ef677/attachment.htm
More information about the darcs-users
mailing list