- Glasgow-haskell-users

Deprecate an instance
by Jon Fairbairn 20 May '05

20 May '05

Would it be possible to extend the DEPRECATED pragma to allow one to deprecate an instance of a class? I was thinking about the recent discussion of APIs on haskell-cafe, where Jérémy Bobbio complained about using Booleans as arguments to libaray functions, preferring instead sensibly named data constructors. It occurred to me that by defining a class one could allow both the old interface and a better one by using a class: module Main where -- suppose f used to be Bool -> Int -> Int, replace it -- with this: f :: Toggle t => t -> Int -> Int f t x = case enabled t of Invert -> -x DontInvert -> x data DoInvert = Invert | DontInvert class Toggle t where enabled :: t -> DoInvert instance Toggle DoInvert where enabled = id instance Toggle Bool where enabled True = Invert enabled False = DontInvert but for this to be any real use, we'd have to be able to deprecate the /instance/ Toggle Bool. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk

1 0

MPC with fundeps: ghc-6.2.2 vs ghc-6.4
by Christian Maeder 20 May '05

20 May '05

Hi, the following (reduced) example used to go through with ghc-6.2.2 but fails with ghc-6.4. Which behaviour is correct? I compile with: ghc -fglasgow-exts Context.hs module Context where class Language a class Language a => Logic a b | a -> b class (Language a, Logic b c, Logic d e) => Comorph a b c d e | a -> b, a -> d instance (Comorph a1 b1 c1 d1 e1, Comorph a2 b2 c2 d2 e2) => Language (a1, a2) instance (Comorph a1 b1 c1 d1 e1, Comorph a2 b2 c2 d2 e2) => Comorph (a1, a2) b1 c1 d2 e2 -- end of module ghc-6.4 (or ghc-6.4.1) complains with: Context.hs:11:0: Could not deduce (Comorph a2 b2 c21 d2 e21, Comorph a1 b1 c11 d1 e11) from the context (Comorph a1 b1 c1 d1 e1, Comorph a2 b2 c2 d2 e2) arising from the superclasses of an instance declaration at Context.hs:11:0 Probable fix: add (Comorph a2 b2 c21 d2 e21, Comorph a1 b1 c11 d1 e11) to the instance declaration superclass context In the instance declaration for `Comorph (a1, a2) b1 c1 d2 e2' If I replace the first instance with "instance (Language a1, Language a2) => Language (a1, a2)" then ghc-6.4 is happy. Cheers Christian

1 0

not.hDuplicate
by Bulat Ziganshin 20 May '05

20 May '05

Hello glasgow-haskell-users, my program contaions several forkOSed threads and at one moment one thread gives to another handle of open file. i need to read some data from this file. how can i accomplish this? if i use hDuplicate, then both handles will share the same file pointer, so threads will mess each other. are there some way to duplicate handle with creating separate file pointer, or to get filename from the Handle, or (preferable) to block another thread's on attempt to access the same handle until i done with it and return to old file pointer? -- Best regards, Bulat mailto:bulatz@HotPOP.com

3 7

RE: error in your article? about meaning of safe/unsafe in "forei gn import"
by Bayley, Alistair 20 May '05

20 May '05

> From: Bulat Ziganshin [mailto:bulatz@HotPOP.com] > > and one more question: is it possible to download sources of http > server mentioned in this article? i want to browse the code, it's no > matter how it compiles and works I believe the web-server mentioned became HWS: http://cvs.sf.net/viewcvs.py/haskell-libs/libs/hws-wp/hws-wp/src/ (I don't see any error/inconsistency in the two quotes; they just seem to be talking about different things. SPJ's quote is about declaring "pure" FFI functions, while the FFI quote is about enabling callbacks into Haskell code. Can you elaborate?) Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

2 1

Why the instance declaration , passing on Hug but failing on GHC 6.2.1?
by wkc03＠mails.tsinghua.edu.cn 19 May '05

19 May '05

I am a novice from China. All the coeds are very simple as below: data People = A | B | C | D | E | F deriving (Show, Eq, Ord, Enum) data Pair a = Pair a a deriving Eq instance Show (Pair People) where show (Pair x y) = "<" ++ show x ++ ", " ++ show y ++ ">" And the error in GHCi: Compiling Main ( Main.hs, interpreted ) Main.hs:5: Illegal instance declaration for `Show (Pair People)' (The instance type must be of form (T a b c) where T is not a synonym, and a,b,c are distinct type variables) In the instance declaration for `Show (Pair People)' Failed, modules loaded: none. But it is puzzling that these code can pass on Hug! I thought that the syntaxn of instance declaration is right! Then, Why did it fail? Best regards, Wukaichen

2 1

RE: runInteractiveProcess is broken
by Simon Marlow 18 May '05

18 May '05

I can't repeat this, it works here: *Main> test1 ExitSuccess *Main> test2 Just ExitSuccess (after changing /usr/bin/sleep to /bin/sleep). The only thing I can think of is that you somehow have a SIGCHLD handler that calls wait(), but I don't see where that can be happening. GHC doesn't have any other mechanism for calling wait(), so I don't understand how the zombies are disappearing before waitForProcess is called. Maybe run it through strace and send us the output? Cheers, Simon On 26 October 2004 19:00, Peter Simons wrote: > Neither of these functions returns the return code of the > external process as promised: > > import System.IO hiding ( catch, try ) > import System.Process > import Control.Concurrent > > sleep :: Int -> IO () > sleep n = threadDelay (abs(n) * 1000000) > > test1 :: IO () > test1 = do > (_,_,_, pid) <- runInteractiveProcess "/usr/bin/sleep" ["1"] > Nothing Nothing sleep 5 > rc <- waitForProcess pid > print rc > > -- *Main> test1 > -- *** Exception: waitForProcess: does not exist (No child > processes) > > test2 :: IO () > test2 = do > (_,_,_, pid) <- runInteractiveProcess "/usr/bin/sleep" ["1"] > Nothing Nothing sleep 5 > rc <- getProcessExitCode pid > print rc > > -- *Main> test2 > -- Nothing > > I'm using the ghc from CVS-HEAD on Linux/x86. > > Peter > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2

Parser for Glasgow Extensions?
by mcnster 18 May '05

18 May '05

Hello there, Has anyone written a version of libraries/haskell-src/Language/Haskell/Parser.ly (and friends) to parse the language plus Glasgow extensions? I have code with | <- guards that the current parser barfs on. - the mcnster -

2 1

RE: runghc, ".hs" suffix
by Simon Marlow 17 May '05

17 May '05

I'm working on this. It's not trivial because GHC assumes all over the place that the suffix on a file determines how it should be compiled, but I've now implemented something similar to gcc's -x flag. Cheers, Simon On 14 May 2005 20:04, Frederik Eaton wrote: > (moving to a separate thread) > > Also, how hard would it be to make it so that runghc doesn't require > script file names to end with ".hs"? Some people like to keep their > executable names language-neutral. > > Frederik > > On Wed, May 11, 2005 at 10:55:03AM +0100, Simon Marlow wrote: >> On 11 May 2005 07:37, Frederik Eaton wrote: >> >>> It looks like runghc is exiting with status 0 if there is a >>> problem. Shouldn't this be non-zero? >>> >>> $ runghc -V >>> The Glorious Glasgow Haskell Compilation System, version 6.4 $ >>> runghc /dev/null; echo $? Could not find module `/dev/null': >>> use -v to see a list of the files searched for >>> (one of the roots of the dependency analysis) >>> >>> <interactive>:1:76: >>> Failed to load interface for `Main': >>> Could not find module `Main': >>> it is not a module in the current program, or in any known >>> package. 0 >> >> It turns out I fixed this bug after 6.4, but later the fix was >> accidentally reverted. So thanks for reporting this again, it'll >> work properly in 6.4.1. >> >> Cheers, >> Simon >> > > _______________________________________________ > Glasgow-haskell-bugs mailing list > Glasgow-haskell-bugs(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

2 1

RE: Re[2]: Unicode source files
by Simon Marlow 17 May '05

17 May '05

On 13 May 2005 11:37, Bulat Ziganshin wrote: > Thursday, May 05, 2005, 1:56:12 PM, you wrote: > >>> it is true what to support unicode source files only StringBuffer >>> implementation must be changed? > >> It depends whether you want to support several different encodings, >> or just UTF-8. If we only want to support UTF-8, then we can keep >> the StringBuffer in UTF-8 and also FastStrings. (or you could >> re-encode the other encodings into UTF-8). > > srcParseErr contains call to "stepOnBy (-len)", and doing this will be > hard with UTF-8. although we can save pointer(s) to positions of > previous chars or even just reparse from scratch entire buffer - > printing source errors is not so frequent task. of course, it will be > great to just save this position for us :) I don't think that's a problem - instead of storing last_len in the lexer state we just store the actual number of bytes (or the StringBuffer). >> The question is what Alex should see for a unicode character: Alex >> currently assumes that characters are in the range 0-255 (you need a >> fixed range in order to generate the lexer tables). One possibility >> is to map all Unicode upper-case characters to a single character >> code for Alex, and similarly for the other classes of character. > > i don't know anything about Alex intrinsics, and can only say that any > solution is better to do INSIDE Alex, so other programs using it will > also get Unicode support The right thing to do as far as Alex is concerned is to collapse the full Char range onto a smaller number of character classes which are then lexed using the standard DFA lexer. Alex could figure out the required character classes automatically. However, a simpler solution for GHC would be to essentially do this by hand, since we already know what the character classes for Haskell are (upper case, lower case, digit etc.), and we already have some code that determines character classes for Unicode characters (GHC.Unicode). So for example you map upper-case unicode character onto 0xfe, lower-case onto 0xfd, and so on. > ... if this problem is just about changing charType in Ctype.lhs - we > can > use some sort of hack. for example, use current scheme until there is > some char greater than (chr 255). in this moment we create array for > classification of chars 256-65535. all chars greater than (chr 65535) > is > better to recognize with calls to appropriate functions, i think We could use a combination of Ctype and GHC.Unicode to find character classes. > btw, Ruby supports writing numbers in form 1_200_000. how about adding > this feature to GHC? ;) I'm not keen on that. We don't tend to introduce features that break Haskell 98 compatibility unless they're quite compelling - and this is only a small change. It would introduce another way that code written for GHC would gratuitously fail to compile with another compiler. This kind of change is best left until the next major revision of the language. Cheers, Simon

2 1

RE: ghc-6.4 fPIC compilation problem on amd64
by Simon Marlow 17 May '05

17 May '05

On 13 May 2005 23:11, ariep(a)xs4all.nl wrote: >> That's a new one on me. Does your 6.2.2 build otherwise work, i.e. >> can you build & run programs with it? > > ghc won't even compile a 'main = putStrLn "hello world"' program: > >> # ghc --make Main.hs >> Chasing modules from: Main.hs >> Compiling Main ( Main.hs, Main.o ) >> Linking ... >> > /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/b in/ld: > Main.o: relocation R_X86_64_32 against `__stginit_Main_' can not be > used when making a shared object; recompile with -fPIC >> Main.o: could not read symbols: Bad value >> collect2: ld returned 1 exit status > > :( Then it looks like your 6.2.2 is broken, or perhaps incompatible with some other tools you have locally. I suggest re-installing (I believe Gentoo has a ghc-bin package that you can install from scratch). Cheers, Simon

1 0