programatica package compilation fails

[maeder]

cabal install http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/src-distribution/programatica-1.0.0.2.tar.gz

fails for ghc-7.2.1 with:

 [201 of 223] Compiling PropPlogic       ( property/parse2/Parser/PropPlogic.hs, dist/build/PropPlogic.o )

property/parse2/Parser/PropPlogic.hs:36:25:
    Couldn't match type `PosName.HsName' with `HsName'
    When using functional dependencies to combine
      HasPropStruct
        (PropSyntaxRec.AssertionI i) (PropSyntaxRec.PropPA i),
        arising from the dependency `rec -> prop'
        in the instance declaration at property/syntax/PropSyntaxRec.hs:38:10
      HasPropStruct
        Assertion
        (HsPropStruct.PA
           HsName
           (PropSyntaxRec.HsExpI PosName.HsName)
           HsQualType
           Assertion
           (PropSyntaxRec.PredicateI PosName.HsName)),
        arising from a use of `quant'
        at property/parse2/Parser/PropPlogic.hs:36:25-29
    In the first argument of `(#)', namely `quant q n optt'
    In the expression: quant q n optt # prop p
...

but succeeds for ghc-7.0.4 and ghc-7.2.0.20110728

[simonpj]

Nice catch thank you. Am fixing.

[simonpj@…]

commit faadd61ef05e8f84a2ad7e0fb6b6d873a7b8c232

Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Fri Sep 2 09:20:45 2011 +0100

    Two bugs in rnExports (fixes Trac #5445)
    
    When constructing export lists, data families pose an awkward problem,
    documented in Note [Exports of data families] in RnNames.  Consider
    
    	   module M where
                 import X( D )
                 data instance D Int = M1 | M2
    
    Here M exports M1 and M2, obviously, but does it export D?  It would
    not usually do so, but if we don't then no one can import M selectively
    like this:
               import M( D(M1,M2) )
    
    So we compromise and export D too.  But I made two mistakes
    
    a) Didn't check for conflicts between the extra export of X.D
       and any other exports called "D"
    
    b) Did the extra export for imported things too, not just ones defined
       in this module (ie made the compromise apply much more widely than
       necessary)
    
    This made Programatica (a complex project) break in an obscure
    way; (b) caused an export conflict, (a) meant that the conflict
    was not spotted, which in turn caused later chaos.
    
    Anyway the fix is easy, and is documented in the Note.

 compiler/rename/RnNames.lhs |   73 ++++++++++++++++++++++++++----------------
 1 files changed, 45 insertions(+), 28 deletions(-)

[simonpj]

I backtracked! Anyway, the bug is fixed. Thank you for identifying it for me.

commit f5c0851a72f7a9cb8a7349eec7a6d4262be7295d
Author: Simon Peyton Jones <simonpj@microsoft.com>
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.

[maeder]

I get the same failure with ghc-7.2.1.20111103. Wasn't the patch merged?

[simonmar]

Replying to maeder:

I get the same failure with ghc-7.2.1.20111103. Wasn't the patch merged?

No - we're only fixing critical bugs with no workarounds in 7.2.2, and as I understand it this one has workarounds (moreover the fix isn't small).

[maeder]

I tried to qualify names, but did not find a workaround.

[simonmar]

I think the workaround is to use explicit export lists (see Simon's commits above).

[maeder]

I've managed to change the code  http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/src-distribution/programatica-1.0.0.3.tar.gz