RE: External Core typechecker bug
Aha, this was more complicated. The trouble is that an External Core module may refer to some implicit things (in this case the type :TEq) that are automatically produced from a normal Haskell thing (in this case the class Eq). The dependency analyser wasn't seeing these implicit dependencies, and as a result we ended up compiling the declarations in the wrong order. The fix is easy, albeit tiresome. Done, anyway. Simon | -Original Message- | From: Kirsten Chevalier [mailto:[EMAIL PROTECTED]] | Sent: 19 February 2003 19:22 | To: [EMAIL PROTECTED] | Subject: External Core typechecker bug | | The external core file resulting from compiling the circsim nofib | benchmark won't compile with GHC 5.05 -- I get the following error message: | | tcLookup: `GHC.Base.:TEq' is not in scope | When checking kinds in `GHC.Base.:TEq a' | In the data type declaration for `Main.:TSignal' | | -- | Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
External Core typechecker bug
The external core file resulting from compiling the circsim nofib benchmark won't compile with GHC 5.05 -- I get the following error message: tcLookup: `GHC.Base.:TEq' is not in scope When checking kinds in `GHC.Base.:TEq a' In the data type declaration for `Main.:TSignal' -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: External Core typechecker
| There is a typechecker for Ext Core already, in | fptools/ghc/utils/ext-core. It would probably take some work to adapt it | to be used with GHC, and to change it so it doesn't have the module names and | primitives from GHC 4.08 wired into it, but would adapting it be the right | thing to do? If so, I might have time to do it sometime. That's true. Its architecture is rather different to the rest of GHC's type checker, and I'd been thinking that the obvious thing to do would be to use the same monad and style as the main type checker. For example, the utils/ext-core one reports only one error, and doesn't track line numbers. Still, it has the merit of existing! Presumably you can always use it stand-alone to check your core progs? I'm not sure what the best approach is. Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: External Core typechecker
On Tue, Oct 01, 2002 at 08:48:00AM +0100, Simon Peyton-Jones wrote: That's true. Its architecture is rather different to the rest of GHC's type checker, and I'd been thinking that the obvious thing to do would be to use the same monad and style as the main type checker. For example, the utils/ext-core one reports only one error, and doesn't track line numbers. Still, it has the merit of existing! Presumably you can always use it stand-alone to check your core progs? Not right now, though, because it doesn't handle code produced by GHC 5, since some of the primitive module names are different. (That would probably be easy to change, I just haven't done it.) I'm not sure what the best approach is. Perhaps writing a new typechecker in the style of the GHC typechecker, but using the Core typechecker as a guide to what the type rules actually are, would be best. I'll think about it more after I get back from ICFP. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: External Core typechecker
On Mon, Sep 30, 2002 at 11:09:23AM +0100, Simon Peyton-Jones wrote: Yes please! Lint was never intended to be a 100% type checker, more of a compiler debugging tool. The reason I'm using it for Ext Core is that it exists, and writing the type checker for Ext Core would take another morning. But in the end it's the Right Thing to do. Volunteers? There is a typechecker for Ext Core already, in fptools/ghc/utils/ext-core. It would probably take some work to adapt it to be used with GHC, and to change it so it doesn't have the module names and primitives from GHC 4.08 wired into it, but would adapting it be the right thing to do? If so, I might have time to do it sometime. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: External Core typechecker
On Fri, Sep 27, 2002 at 04:12:11PM +0100, Simon Peyton-Jones wrote: I allege that I have fixed this. You now get type checking of external core without saying -dcore-lint. Dude, now I have to rebuild GHC *again*? Even with -dcore-lint, though, the compiler still seems to panic on certain ill-typed Core programs (this is using GHC 5.04.1 installed from rpms); one of these days I'll find a minimal test case and submit a bug report. Kirsten, would you care to say how you are using External Core? I'm using it to test a program transformation I'm implementing (type-inference- based deforestation) without linking into or hacking GHC (since I got quite enough of that before the External Core feature existed). Since I'm still debugging my transformation, it sometimes produces ill-typed programs, which is how I've encountered all these bugs. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: External Core typechecker
I allege that I have fixed this. You now get type checking of external core without saying -dcore-lint. Kirsten, would you care to say how you are using External Core? Simon | -Original Message- | From: Sigbjorn Finne [mailto:[EMAIL PROTECTED]] | Sent: 05 September 2002 21:05 | To: Kirsten Chevalier | Cc: [EMAIL PROTECTED] | Subject: Re: External Core typechecker | | Kirsten Chevalier [EMAIL PROTECTED] writes: | On Thu, Sep 05, 2002 at 12:20:27PM -0700, Sigbjorn Finne wrote: | To enable type checking of Core, compile with -dcore-lint | | | Ah, thanks. You'd think it would do that by default when starting from | an external Core file (hint :-)) | | | It actually does, but the type checking code that that front-end (re-)uses | does just a limited amount of checking (e.g., function applications aren't | checked..), hence the suggestion of using the more thorough -dcore-lint | | --sigbjorn | | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
External Core typechecker
GHC doesn't seem to do much typechecking on external Core files; it happily compiles .hcr files with type errors that then segfault when you run the program. An example of such a program is attached (the type error is on line 19, where cons is applied to the Integer type and two integer lists). I'm using the latest version of GHC (built from CVS sources yesterday, using GHC 5.04 to bootstrap), on a RedHat Linux box with gcc 2.96. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
External Core typechecker
[ oops, forgot to include the attachment in the last message; it's also
copied here as text ]
%module Main
%rec
{main1 :: GHCziPrim.ZLzmzgZR
(GHCziPrim.Statezh GHCziPrim.RealWorld)
(GHCziPrim.Z2H
(GHCziPrim.Statezh GHCziPrim.RealWorld)
GHCziBase.Z0T) =
%let %rec
{x :: GHCziNum.Integer = lit;
x1 :: GHCziNum.Integer = x}
%in %let %rec
{y :: GHCziBase.ZMZN GHCziNum.Integer =
GHCziBase.zdwZC @ GHCziNum.Integer lit1
(GHCziBase.zdwZC @ GHCziNum.Integer lit2
(GHCziBase.zdwZC @ GHCziNum.Integer lit3
(GHCziBase.zdwZMZN @ GHCziNum.Integer)));
y1 :: GHCziBase.ZMZN GHCziNum.Integer = y}
%in SystemziIO.putStrLn
(show (GHCziBase.ZC @ GHCziNum.Integer y1 y1));
main :: GHCziPrim.ZLzmzgZR
(GHCziPrim.Statezh GHCziPrim.RealWorld)
(GHCziPrim.Z2H
(GHCziPrim.Statezh GHCziPrim.RealWorld)
GHCziBase.Z0T) =
main1;
lit :: GHCziNum.Integer =
fromInteger (GHCziNum.zdwSzh (5::GHCziPrim.Intzh));
fromInteger :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
GHCziNum.fromInteger @ GHCziNum.Integer zddNum;
lit1 :: GHCziNum.Integer =
fromInteger1 (GHCziNum.zdwSzh (1::GHCziPrim.Intzh));
fromInteger1 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
lit2 :: GHCziNum.Integer =
fromInteger2 (GHCziNum.zdwSzh (2::GHCziPrim.Intzh));
fromInteger2 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
lit3 :: GHCziNum.Integer =
fromInteger3 (GHCziNum.zdwSzh (3::GHCziPrim.Intzh));
fromInteger3 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
show :: GHCziPrim.ZLzmzgZR
(GHCziBase.ZMZN GHCziNum.Integer)
(GHCziBase.ZMZN GHCziBase.Char) =
GHCziShow.show @ (GHCziBase.ZMZN GHCziNum.Integer) zddShow;
zddShow :: GHCziShow.ZCTShow (GHCziBase.ZMZN GHCziNum.Integer) =
GHCziShow.zdfShowZMZN @ GHCziNum.Integer zddShow1;
zddShow1 :: GHCziShow.ZCTShow GHCziNum.Integer =
GHCziNum.zdp2Num @ GHCziNum.Integer zddNum;
zddNum :: GHCziNum.ZCTNum GHCziNum.Integer =
GHCziNum.zdfNumInteger;
Main.zdmain :: GHCziPrim.ZLzmzgZR
(GHCziPrim.Statezh GHCziPrim.RealWorld)
(GHCziPrim.Z2H
(GHCziPrim.Statezh GHCziPrim.RealWorld)
GHCziBase.Z0T) =
GHCziTopHandler.runIO @ GHCziBase.Z0T main};
--
Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt
%module Main
%rec
{main1 :: GHCziPrim.ZLzmzgZR
(GHCziPrim.Statezh GHCziPrim.RealWorld)
(GHCziPrim.Z2H
(GHCziPrim.Statezh GHCziPrim.RealWorld)
GHCziBase.Z0T) =
%let %rec
{x :: GHCziNum.Integer = lit;
x1 :: GHCziNum.Integer = x}
%in %let %rec
{y :: GHCziBase.ZMZN GHCziNum.Integer =
GHCziBase.zdwZC @ GHCziNum.Integer lit1
(GHCziBase.zdwZC @ GHCziNum.Integer lit2
(GHCziBase.zdwZC @ GHCziNum.Integer lit3
(GHCziBase.zdwZMZN @ GHCziNum.Integer)));
y1 :: GHCziBase.ZMZN GHCziNum.Integer = y}
%in SystemziIO.putStrLn
(show (GHCziBase.ZC @ GHCziNum.Integer y1 y1));
main :: GHCziPrim.ZLzmzgZR
(GHCziPrim.Statezh GHCziPrim.RealWorld)
(GHCziPrim.Z2H
(GHCziPrim.Statezh GHCziPrim.RealWorld)
GHCziBase.Z0T) =
main1;
lit :: GHCziNum.Integer =
fromInteger (GHCziNum.zdwSzh (5::GHCziPrim.Intzh));
fromInteger :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
GHCziNum.fromInteger @ GHCziNum.Integer zddNum;
lit1 :: GHCziNum.Integer =
fromInteger1 (GHCziNum.zdwSzh (1::GHCziPrim.Intzh));
fromInteger1 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
lit2 :: GHCziNum.Integer =
fromInteger2 (GHCziNum.zdwSzh (2::GHCziPrim.Intzh));
fromInteger2 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
lit3 :: GHCziNum.Integer =
fromInteger3 (GHCziNum.zdwSzh (3::GHCziPrim.Intzh));
fromInteger3 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
show :: GHCziPrim.ZLzmzgZR
(GHCziBase.ZMZN GHCziNum.Integer)
(GHCziBase.ZMZN GHCziBase.Char) =
GHCziShow.show @ (GHCziBase.ZMZN GHCziNum.Integer) zddShow;
zddShow :: GHCziShow.ZCTShow (GHCziBase.ZMZN GHCziNum.Integer) =
GHCziShow.zdfShowZMZN @ GHCziNum.Integer zddShow1;
zddShow1 ::
Re: External Core typechecker
To enable type checking of Core, compile with -dcore-lint --sigbjorn - Original Message - From: Kirsten Chevalier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 05, 2002 12:05 Subject: External Core typechecker GHC doesn't seem to do much typechecking on external Core files; it happily compiles .hcr files with type errors that then segfault when you run the program. An example of such a program is attached (the type error is on line 19, where cons is applied to the Integer type and two integer lists). I'm using the latest version of GHC (built from CVS sources yesterday, using GHC 5.04 to bootstrap), on a RedHat Linux box with gcc 2.96. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: External Core typechecker
On Thu, Sep 05, 2002 at 12:20:27PM -0700, Sigbjorn Finne wrote: To enable type checking of Core, compile with -dcore-lint Ah, thanks. You'd think it would do that by default when starting from an external Core file (hint :-)) -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: External Core typechecker
Kirsten Chevalier [EMAIL PROTECTED] writes: On Thu, Sep 05, 2002 at 12:20:27PM -0700, Sigbjorn Finne wrote: To enable type checking of Core, compile with -dcore-lint Ah, thanks. You'd think it would do that by default when starting from an external Core file (hint :-)) It actually does, but the type checking code that that front-end (re-)uses does just a limited amount of checking (e.g., function applications aren't checked..), hence the suggestion of using the more thorough -dcore-lint --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
