[darcs-users] Fwd: darcs patch: fix type witness compile errors specific to ghc 6.8

[David Roundy]

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 <dagit at codersbase.com>
> 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: darcs-users at darcs.net
> 
> 
> 
> 
> 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

-- 
David Roundy
Department of Physics
Oregon State University