Error: No match in _dropJust

When I compile frown with the brand-new 1.10 I get ... LR/Frown> hmake -nhc98 -98 -ILib -PLib Main.lhs WARNING: hmake built with hbc-0.9999.5b gets timestamps wrong. nhc98 -98 -ILib -PLib -c -o Lib/Prettier.o Lib/Prettier.lhs nhc98 -98 -ILib -PLib -c -o Atom.o Atom.lhs nhc98 -98 -ILib -PLib -c -o Base.o Base.lhs nhc98 -98 -ILib -PLib -c -o Lib/GetOpt.o Lib/GetOpt.lhs nhc98 -98 -ILib -PLib -c -o Options.o Options.lhs nhc98 -98 -ILib -PLib -c -o Lexer2.o Lexer2.lhs nhc98 -98 -ILib -PLib -c -o Haskell.o Haskell.lhs nhc98 -98 -ILib -PLib -c -o Grammar.o Grammar.lhs nhc98 -98 -ILib -PLib -c -o GParser2.o GParser2.hs /home/ralf/Lang//lib/nhc98/ix86-Linux/nhc98comp: Error: No match in _dropJust I can send you the bundle if you want me to. Cheers, Ralf

Ralf,
When I compile frown with the brand-new 1.10 I get ...
nhc98 -98 -ILib -PLib -c -o GParser2.o GParser2.hs /home/ralf/Lang//lib/nhc98/ix86-Linux/nhc98comp: Error: No match in _dropJust
It turns out that this is a long-standing bug in the type checker - it is not specific to version 1.10. The problem is with higher kinds in type synonyms - nhc98 requires that synonyms be fully applied, even at the point of definition. Specifically, if you change the line type Result = Lex Base.Result to type Result a = Lex Base.Result a then your example compiles just fine. I'm afraid we are unlikely to have time to fix the many shortcomings of the type checker in the near future, so you will need to use this workaround. [ You may be interested to know that we tracked down this bug using Hat. The function 'dropJust' is used in 96 different places in the compiler, so it would otherwise be difficult to guess which use was at fault. By building the compiler itself with tracing switched on, hat-stack was immediately able to identify a particular site in TypeCtx.hs, and exploration with hat-trail showed that the list of free type variables in the type synonym was empty where at least one member was expected. I think this is probably the largest program Hat has ever traced, at 29000 lines of code, generating a trace file of 750Mb. ] Regards, Malcolm

Ralf,
When I compile frown with the brand-new 1.10 I get ...
nhc98 -98 -ILib -PLib -c -o GParser2.o GParser2.hs /home/ralf/Lang//lib/nhc98/ix86-Linux/nhc98comp: Error: No match in _dropJust
It turns out that this is a long-standing bug in the type checker - it is not specific to version 1.10. The problem is with higher kinds in type synonyms - nhc98 requires that synonyms be fully applied, even at the point of definition. Specifically, if you change the line
type Result = Lex Base.Result
to
type Result a = Lex Base.Result a
then your example compiles just fine. I'm afraid we are unlikely to have time to fix the many shortcomings of the type checker in the near future, so you will need to use this workaround.
[ You may be interested to know that we tracked down this bug using Hat. The function 'dropJust' is used in 96 different places in the compiler, so it would otherwise be difficult to guess which use was at fault. By building the compiler itself with tracing switched on, hat-stack was immediately able to identify a particular site in TypeCtx.hs, and exploration with hat-trail showed that the list of free type variables in the type synonym was empty where at least one member was expected.
I think this is probably the largest program Hat has ever traced, at 29000 lines of code, generating a trace file of 750Mb. ]
Regards, Malcolm
Hi Malcolm, thanks for tracing this down. Great, I am now able to compile Frown. BTW, did you also look at the second bug ... < Actually, I think there is another bug lurking around. I had to < hide an identifier to get Grammar.lhs through (the original file < called Grammar.lhs-orig is included). Let me know if you need < further information. 1) Here is the story: we have a module `Haskell' that imports both `Atom' and `Prettier' both of which define `string'.
module Haskell ( module Haskell, module Atom ) where import Atom hiding ( string ) import qualified Atom import Prettier
Now, does `Haskell' export the identifier `string'? GHC says no, nhc98 says yes. Honestly, I don't know whether GHC or nhc98 is wrong as I did not follow all the postings concerning the module system. 2) Furthermore, to get Frown compiled I had to change an import import OrdUniqListSet ( Set, MinView(..) ) to import OrdUniqListSet ( Set, MinView(Empty, Min) ) 3) Finally, nhc98 does not like spurious commas in export lists. GHC is non-Haskell 98 compliant here.
module Case ( nexts, Branch(..), -- caseAnalysis, , reportConflicts, BranchTable, branchLogic )
Cheers, Ralf

| < Actually, I think there is another bug lurking around. I had to | < hide an identifier to get Grammar.lhs through (the original file | < called Grammar.lhs-orig is included). Let me know if you need | < further information. | | 1) Here is the story: we have a module `Haskell' that imports both | `Atom' and `Prettier' both of which define `string'. | | > module Haskell ( module Haskell, module Atom ) | > where | > import Atom hiding ( string ) | > import qualified Atom | > import Prettier | | Now, does `Haskell' export the identifier `string'? GHC says no, | nhc98 says yes. Honestly, I don't know whether GHC or nhc98 is | wrong as I did not follow all the postings concerning the module system. I believe GHC is right and nhc98 is wrong here. I am testing a fix right now. | 2) Furthermore, to get Frown compiled I had to change an import | import OrdUniqListSet ( Set, MinView(..) ) | to | import OrdUniqListSet ( Set, MinView(Empty, Min) ) I'll look into this. | 3) Finally, nhc98 does not like spurious commas in export lists. | GHC is non-Haskell 98 compliant here. | | > module Case ( nexts, Branch(..), -- caseAnalysis, | > , reportConflicts, BranchTable, branchLogic ) Yes, nhc98 is right and GHC is wrong here. In Haskell'98, an extra comma is permitted at the end of the list of identifiers, but not in the middle. Regards, Malcolm

1) Here is the story: we have a module `Haskell' that imports both `Atom' and `Prettier' both of which define `string'.
module Haskell ( module Haskell, module Atom ) where import Atom hiding ( string ) import qualified Atom import Prettier
Now, does `Haskell' export the identifier `string'? GHC says no, nhc98 says yes. Honestly, I don't know whether GHC or nhc98 is wrong as I did not follow all the postings concerning the module system.
Here is a patch for this bug. Regards, Malcolm Index: src/compiler98/PreImport.hs =================================================================== RCS file: /usr/src/master/nhc/src/compiler98/PreImport.hs,v retrieving revision 1.15 diff -u -r1.15 PreImport.hs --- src/compiler98/PreImport.hs 2001/10/18 16:53:52 1.15 +++ src/compiler98/PreImport.hs 2001/11/01 13:40:19 @@ -414,5 +414,9 @@ [] -> st postidanots -> -} - iextractVarsType reExport q postidanots ctxs typ () st + iextractVarsType (\q tid idkind -> + if imported tid && not (q tid) + then reExport q tid idkind + else IEnone) + q postidanots ctxs typ () st
participants (2)
-
Malcolm Wallace
-
Ralf Hinze