Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#5306 closed bug (fixed)

Data family constructor imports broken

Reported by: reinerp Owned by: simonpj
Priority: normal Milestone: 7.4.1
Component: Compiler Version: 7.0.3
Keywords: type families Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHC rejects valid program Test Case: rename/should_compile/T5306
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

The following does not compile, but according to http://www.haskell.org/haskellwiki/GHC/Type_families#Import_and_export it should.

A:

{-# LANGUAGE TypeFamilies #-}
module A where

data family F a
data instance F Int = FInt

B:

{-# LANGUAGE TypeFamilies #-}
module B where
import A

data instance F Bool = FBool

C:

{-# LANGUAGE TypeFamilies #-}
module C where

import B(F(FBool))  -- fails
import A(F(FInt))   -- succeeds

The error is:

C.hs:4:10: Module `B' does not export `F(FBool)'

Change History (5)

comment:1 Changed 4 years ago by igloo

  • Milestone set to 7.4.1
  • Owner set to simonpj

Thanks for the report.

comment:2 Changed 4 years ago by simonpj@…

commit fe44af73d58839e3010e1234cece0dd6c33f7eb5

Author: Simon Peyton Jones <[email protected]>
Date:   Tue Aug 2 10:43:57 2011 +0100

    Change the representation of export lists in .hi files
    
    Currently export list in .hi files are partitioned by module
      export M T(C1,C2)
             N f,g
    In each list we only have OccNames, all assumed to come from
    the parent module M or N resp.
    
    This patch changes the representatation so that export lists
    have full Names:
      export M.T(M.C1,M.C2), N.f, N.g
    
    Numerous advatages
      * AvailInfo no longer needs to be parameterised; it always
        contains Names
    
      * Fixes Trac #5306.  This was the main provocation
    
      * Less to-and-fro conversion when reading interface files
    
    It's all generally simpler.  Interface files should not get bigger,
    becuase they have a nice compact representation for Names.

 compiler/basicTypes/Name.lhs  |   22 +++++-
 compiler/iface/BinIface.hs    |    2 +-
 compiler/iface/IfaceEnv.lhs   |   20 +-----
 compiler/iface/LoadIface.lhs  |   21 ++---
 compiler/iface/MkIface.lhs    |   55 ++-----------
 compiler/main/HscTypes.lhs    |   50 +++++++-----
 compiler/prelude/PrelInfo.lhs |   23 +++---
 compiler/rename/RnEnv.lhs     |   12 +--
 compiler/rename/RnNames.lhs   |  174 +++++++++++++++++++----------------------
 compiler/rename/RnSource.lhs  |    2 +-
 10 files changed, 167 insertions(+), 214 deletions(-)

comment:3 Changed 4 years ago by simonpj

  • Status changed from new to merge
  • Test Case set to rename/should_compile/T5306

Thanks for pointing this out, and boiling it down to such a small test case. Now fixed!

comment:4 Changed 4 years ago by igloo

  • Resolution set to fixed
  • Status changed from merge to closed

comment:5 Changed 4 years ago by simonpj

I backtracked on a rather ad-hoc change I made in the above patch, but didn't draw attention to. Here's the patch that undoes the hack:

commit f5c0851a72f7a9cb8a7349eec7a6d4262be7295d
Author: Simon Peyton Jones <[email protected]>
Date:   Fri Sep 2 17:34:00 2011 +0100

    Backtrack on the wierd special case of data family exports
    
    I had second thoughts on the "data family export" question.
    Rather than add a wierd special case it seems better to be
    simple and consistent.  So this patch
    
     * Reverts to the simple behaviour:
         module M where { ... }
       exports only what is defined in M, ie NOT any
       imported data families.
       See Note [Exports of data families] in RnNames
    
    * Documents this behaviour in the user manual, and clarifies
      what was there before.

 compiler/rename/RnNames.lhs       |   41 +++++------
 docs/users_guide/glasgow_exts.xml |  142 +++++++++++++++++++++++--------------
 2 files changed, 105 insertions(+), 78 deletions(-)
Note: See TracTickets for help on using tickets.