December 2004 - Glasgow-haskell-users

RE: template haskell printf doesn't compile...
by Simon Peyton-Jones 04 Dec '04

04 Dec '04

Sorry Documentation out of date: consult the library documentation for up to date info. Change Expr to ExpQ change string to stringE | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of S. Alexander Jacobson | Sent: 02 December 2004 20:21 | To: GHC users | Subject: template haskell printf doesn't compile... | | Tried to use the printf TH example described in | the GHC docs | | http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell .html | | Got this error: | | Chasing modules from: PrintMain.hs | Compiling Printf ( ./Printf.hs, ./Printf.o ) | | ./Printf.hs:23: Type constructor or class not in scope: `Expr' | | ./Printf.hs:26: Variable not in scope: `string' | ./Printf.hs:30: Type constructor or class not in scope: `Expr' | | Any clues? | | -Alex- | | ______________________________________________________________ | S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2

RE: -fallow-incoherent-instances
by Simon Peyton-Jones 03 Dec '04

03 Dec '04

It is strange that adding -fallow-incoherent-instances should *stop* it compiling. This does not happen in the HEAD. I can see why it happens in 6.2 You are on very very very thin ice with this program. You have instance Confuse a => Typeable a f :: Typeable a => ... f x = ....stuff that needs Typeable .... At any time the compiler might use the instance decl to reduce the constraint Typeable a to Confuse a The only thing *stopping* it doing so is the desire to preserve coherence, which is why it does though before you add the flag. When you add the flag -fallow-incoherent-instances, the compiler feels free to reduce Typeable a to Confuse a... but then it finds that the type signature for f only provides Typeable. Sorry.. but if you have all of undecidable instances overlapping instances incoherent instances then life is pretty wild. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Christian Maeder | Sent: 30 November 2004 11:48 | To: GHC Users Mailing List | Subject: -fallow-incoherent-instances | | The attached module does not compile and yields the following error: | | InCoherentInst.hs:17: | Could not deduce (Confuse a) from the context (Typeable a) | arising from use of `breakFn' at InCoherentInst.hs:17 | Probable fix: | Add (Confuse a) to the type signature(s) for `addGeneralFallOut' | In the first argument of `GeneralBreakFn', namely `breakFn' | In the definition of `addGeneralFallOut': | addGeneralFallOut = let | breakFn a = throwDyn (GeneralFallOutExcep a) | in GeneralBreakFn breakFn | | | The same source compiles ok without -fallow-incoherent-instances (or | with -fno-allow-incoherent-instances). | | If, furthermore, the "confusing instance" is commented out, the source | even compiles without extensions. | | I don't know if this is a bug, possibly related to the import of | Typeable stuff. I don't need a fix. I only want to point out that | globally switching on the option -fallow-incoherent-instances is likely | to break existing code, currently (ghc 6.2.2). | | Cheers Christian

2 1

RE: -fno-monomorphism-restriction
by Simon Peyton-Jones 03 Dec '04

03 Dec '04

| > b) this is a feature request: you want a flag -fmonomorphism-restriction | > to restore the monomorphism restriction even if it's been turned | > off by an earlier flag? I've implemented this flag in the HEAD, as you requested. It'll be in 6.4 Simon

1 0

template haskell printf doesn't compile...
by S. Alexander Jacobson 02 Dec '04

02 Dec '04

Tried to use the printf TH example described in the GHC docs http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.ht… Got this error: Chasing modules from: PrintMain.hs Compiling Printf ( ./Printf.hs, ./Printf.o ) ./Printf.hs:23: Type constructor or class not in scope: `Expr' ./Printf.hs:26: Variable not in scope: `string' ./Printf.hs:30: Type constructor or class not in scope: `Expr' Any clues? -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

1 0

How do I call mmap() in Haskell?
by William Lee Irwin III 02 Dec '04

02 Dec '04

I've been wondering how to do mmap() in Haskell since I don't know how to get things to interact with the runtime system etc. Actually, similar questions apply to asynchronous IO. The foreign function interface is nice and all, but modelling the result with types and interoperating with the runtime system is the real question here. -- wli

3 3

RE: Bug in touchForeignPtr?
by Simon Marlow 01 Dec '04

01 Dec '04

On 30 November 2004 16:39, Benjamin Franksen wrote: > [re-sending because I got no response yet] > > On Tuesday 23 November 2004 13:06, Simon Marlow wrote: >> On 22 November 2004 17:28, Benjamin Franksen wrote: >>> However, what I don't understand is why touchForeignPtr is not >>> honored in my example program: Note that the output text lines from >>> the finalizers appear *before* the last action in the program (which >>> is a second getChar). The finalizers *are* called by the GC, and >>> still the order is wrong. >> >> Note that the GC only starts the finaliser thread. The program can >> still terminate before this thread has run to completion > > I repeat: the program is not yet even near termination when the > finalizers get executed (in teh wrng order). > > Here is the example program again (with 3 lines added to the end of > main to illustrate the point): > > import Foreign hiding (newForeignPtr) > import Foreign.Concurrent > import System.Mem (performGC) > > type A = ForeignPtr Int > > type B = ForeignPtr Bool > > newA :: IO A > newA = do > (pa::Ptr Int) <- malloc > newForeignPtr pa $ do > putStrLn "before finalizing A" > free pa > putStrLn "after finalizing A" > > newB :: A -> IO B > newB fpa = > withForeignPtr fpa $ \pa -> do > (pb::Ptr Bool) <- malloc > newForeignPtr pb $ do > putStrLn "before finalizing B" > free pb > putStrLn "after finalizing B" > touchForeignPtr fpa > > main = do > a <- newA > b <- newB a > getChar > performGC > getChar > putStrLn "Program still not terminated, please hit <enter> again!" > getChar > putStrLn "Program termination will now be initiated." > > And this is the output: > > franksen@linux: .../foreigntouchbug > ./a.out > <enter> > before finalizing A > after finalizing A > before finalizing B > after finalizing B > <enter> > Program still not terminated, please hit <enter> again! > <enter> > Program termination will now be initiated. The GC simply found that both objects were unreferenced and hence ran their finalizers, in no particular order. The fact that B referred to A has no effect, since both objects were unreachable from the roots. If B had been reachable, then A would not have been finalized - this is the only way in which the ordering would have shown up. This is just a manifestation of the lack of ordering between finalizers - sorry if I wasn't clear before. The documentation will be updated for the 6.4 release to more closely reflect the state of affairs. Cheers, Simon

1 0