- Glasgow-haskell-users

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

03 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

Re: Bug in touchForeignPtr?
by Benjamin Franksen 30 Nov '04

30 Nov '04

[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. Ben

1 0

RE: -fno-monomorphism-restriction
by Simon Peyton-Jones 30 Nov '04

30 Nov '04

Christian This isn't a bug. See Section 4.5.5 of the Haskell Report, http://haskell.org/onlinereport/decls.html in the second bullet under the sub-heading "Motivation". Your (bi, las) binding is essentially the same as the (n,s) binding in that bullet. 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: 29 November 2004 16:31 | To: Simon Peyton-Jones | Cc: GHC Users Mailing List | Subject: Re: -fno-monomorphism-restriction | | I've found a much shorter example (without imports) that does not | compile. The error displayed is: | | Ambiguous type variable `a' in the top-level constraint: | `ATermConvertibleSML a' | arising from use of `las' at | /home/maeder/haskell/examples/NoMonoRestr.hs:29 | | (comenting out the initial "OPTIONS" line, will make it go through) | | Cheers Christian

2 1

-fallow-incoherent-instances
by Christian Maeder 30 Nov '04

30 Nov '04

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

3 4

CWString API
by Krasimir Angelov 30 Nov '04

30 Nov '04

Hello guys, I am working on updated version of HDirect and now I am going to use CWString API to marshal (wchar_t *) type to String. I found some inconsistencies in the API. - castCWcharToChar and castCharToCWchar functions are defined only for Posix systems and they aren't exported. In the same time castCCharToChar and castCharToCChar have the same meaning and they are defined and exported on all platforms. - CWchar type looks a little bit strange compared to CChar, CString and CWString types. In my opinion CWChar looks more consistent. Since the CWString API isn't released in previous GHC releases I think now is the time to fix that. Any opinions? Cheers, Krasimir __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

2 4