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
bug/feature/? of ghci with concurrency
Maybe this is by design, but in case it isn't: I was a little suprprised when I came across this behavior of ghci: ghci ... GHC Interactive, version 5.04.1, for Haskell 98. ... Prelude :m Concurrent Prelude Concurrent let loop c = putChar c loop c in forkIO (loop 'a') (loop 'z') zazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazaza zazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazaza zazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazazaza Interrupted. aPrelude Concurrent sum [1..100] a5050 aPrelude Concurrent 1+2 3 Obviously, loop 'a' has never been terminated and starts running anytime execution is in progress. I might expect that either interrupting the execution would kill *all* processes or that after interrupting loop 'z' that I would still see the loop 'a' executing. This is on 386 Linux. - Mark ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: bug/feature/? of ghci with concurrency
Maybe this is by design, but in case it isn't: I was a little suprprised when I came across this behavior of ghci: ghci ... GHC Interactive, version 5.04.1, for Haskell 98. ... Prelude :m Concurrent Prelude Concurrent let loop c = putChar c loop c in forkIO (loop 'a') (loop 'z') zazazazazazazazazazazazazazazazazazazazazazazazazazazazazazaza zazazazazazaza zazazazazazazazazazazazazazazazazazazazazazazazazazazazazazaza zazazazazazaza zazazazazazazazazazazazazazazazazazazazazazazazazazazazazazaza zazazazazazaza Interrupted. aPrelude Concurrent sum [1..100] a5050 aPrelude Concurrent 1+2 3 This is really a design choice: there is no inter-thread structure other than what you program yourself, there are no process groups, and pressing ^C sends an exception to the main thread only. We don't currently have a way for a Haskell program to get access to *all* the current threads running, so there's no easy way for GHCi to stop extraneous threads when ^C is received. It's really a bug that the other threads are suspended when the prompt appears (but it might also be called a feature: terminating GHCi after your example might be difficult otherwise!). Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-617082 ] ghc -O generates faulty c code
Bugs item #617082, was opened at 2002-10-01 08:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=617082group_id=8032 Category: Compiler Group: 5.04 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ghc -O generates faulty c code Initial Comment: I have the following file: Bug.hs -- module Bug where foo :: Double - Double foo x = x - (-1.0) -- ghc -c -O Bug.hs /tmp/ghc25320.hc: In function `s3Ny_ret': /tmp/ghc25320.hc:14: invalid lvalue in decrement /tmp/ghc25320.hc:14: parse error before `1.0' Cause - The problem is the following generated c snippet _s3Nx_=PK_DBL((W_*)(R1.p+1))--1.0; The two consecutive minuses should be separated by a space. Ulf Norell [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=617082group_id=8032 ___ 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
