Opened 9 years ago

Closed 9 years ago

#4851 closed bug (fixed)

NoImplicitPrelude does not handle rec / mfix / ArrowLoop properly

Reported by: peteg Owned by:
Priority: normal Milestone: 7.4.1
Component: Compiler Version: 6.12.3
Keywords: Cc: peteg42@…, ross@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHC rejects valid program Test Case: rebindable/T4851
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Consider this program:

{-# LANGUAGE Arrows, NoImplicitPrelude #-}
module T where

import Prelude hiding ( id, (.) )

import Control.Category	( Category(..) )
import Control.Arrow

garbage =
  proc b ->
    do rec (c, d) <- undefined -< (b, d)
       returnA -< c

I think this is the new idiomatic way of writing Arrow code due to the use of Category, which clashes with the Prelude. I wish to avoid the explicit "import Prelude hiding..." stuff in all the other modules.

In GHC 6.12.3 this gives an error about mfix.

Removing NoImplicitPrelude yields an error about ArrowLoop, as expected.

Change History (6)

comment:1 Changed 9 years ago by simonpj

Cc: ross@… added

I'm not sure what you are asking here. With HEAD (and hence I think 7.0) we get

T4851.hs:10:4:
    Ambiguous type variable `a' in the constraint:
      (ArrowLoop a) arising from a proc expression
    Possible cause: the monomorphism restriction applied to the following:
      garbage :: forall t b. a t b (bound at T4851.hs:9:1)
    Probable fix: give these definition(s) an explicit type signature
                  or use -XNoMonomorphismRestriction
    In the expression:
      proc b -> do { rec {(c, d) <- undefined -< (b, d)};
                     returnA -< c }
    In an equation for `garbage':
        garbage
          = proc b -> do { rec {(c, d) <- undefined -< (b, d)};
                           returnA -< c }

But in HEAD, you need RebindableSyntax to get rebindable syntax. (NoImplicitPrelude alone now does only what it says.)

With HEAD and RebindableSyntax we get

T4851.hs:11:9: Not in scope: `mfix'

which is reasonable; I believe mfix is defined in Control.Monad.Fix. If we import that module too we get the ambiguous-variable error again.

Maybe you are asking a library question, like where is mfix defined? Anyway, GHC seems to be behaving ok

Simon

comment:2 Changed 9 years ago by igloo

Resolution: invalid
Status: newclosed

Sounds like this isn't a GHC bug; please reopen if that's not the case.

comment:3 Changed 9 years ago by peteg

Resolution: invalid
Status: closednew

I expected that in a proc context "rec" should ask for ArrowLoop, not mfix - i.e. Control.Arrow.ArrowLoop usually, and ArrowLoop with RebindableSyntax in the HEAD / NoImplicitPrelude in 6.12.3.

Putting it another way, why are you unsurprised that mfix enters this picture with RebindableSyntax?

Thanks for looking into this.

cheers peter

comment:4 Changed 9 years ago by simonpj

Oh yes, I see now. The 'rec' is looking up 'mfix', but it should not do so in an arrow context. It's a fiddly corner... Thanks for re-opening.

comment:5 Changed 9 years ago by igloo

Milestone: 7.2.1

comment:6 Changed 9 years ago by simonpj

Resolution: fixed
Status: newclosed
Test Case: rebindable/T4851

I managed to fix this as part of the monad-comprehension stuff #4370. The actual commit is

commit d4780d48bb8a665a2cdaa5e2c6e4bfbc87298fd0
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Wed May 4 23:09:53 2011 +0100

    Do-notation in an arrow context is not rebindable
    
    Fixes Trac #4851

 compiler/rename/RnExpr.lhs |   21 ++++++++++++++++++---
 1 files changed, 18 insertions(+), 3 deletions(-)

Simon

Note: See TracTickets for help on using tickets.