- Glasgow-haskell-users

GHC on Mac OS X 10.2 (Jaguar)
by Wolfgang Thaller 30 Aug '02

30 Aug '02

The new Mac OS X 10.2 has arrived, and GHC has stopped working. I've compiled a new GHC binary that runs on 10.2 (but not anymore on 10.1). It is available at: http://www.uni-graz.at/imawww/haskell/JaguarGHC.tar.gz This archive contains just a new GHC binary, the rest of the binary release already has to be already installed. What happened: With Mac OS X 10.1, Apple had included a 'curses' library in it's main 'libSystem.dylib' library. For 10.2, they removed that, and instead added a separate ncurses library (which wasn't included in 10.1.). GHC relies on one of those libraries (via readline), but readline has to be recompiled to use the other library. GHC-compiled programs that don't explicitly link against readline are not affected by this problem. Cheers, Wolfgang

1 0

RE: weird (bug?) in linear implicit parameters
by Simon Peyton-Jones 30 Aug '02

30 Aug '02

Yes, this is odd behaviour. Here's what is is happening. Consider foo :: %x::T => Int -> [Int] foo 0 = [] foo n = %x : foo (n-1) where T is some type in class Splittable, Do you get a list of all the same T's or all different T's? (assuming that split gives two distinct T's back) If you supply the type signature, taking advantage of polymorphic recursion, you get what you'd probably expect. Here's the translated term, where the implicit param is made explicit: foo x 0 = [] foo x n = let (x1,x2) = split x in x1 : foo x2 (n-1) But if you don't supply a type signature, GHC uses the Hindley Milner trick of using a single monomorphic instance of the function for the recursive calls. That is what makes Hindley Milner type inference work. So the translation becomes foo x = let foom 0 = [] foom n = x : foom (n-1) in foom Result: 'x' is not split, and you get a list of identical T's. That's why adding the type sig changes the behaviour. You may say that this is a good reason to dislike linear implicit parameters and you'd be right. That is why they are an experimental feature. Unlike many other features in GHC I am far from sure that it's a good one. I'll dump this message into the user manual. Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 23 July 2002 18:56 | To: GHC Users Mailing List | Subject: weird (bug?) in linear implicit parameters | | | (guess who finally decided to learn about imp params :P) | | this looks like a bug to me, but of course i may be wrong. | | consider these definitions: | | > data BLSupply = BLSupply [Bool] | > | > instance Splittable BLSupply where | > split (BLSupply l) = (BLSupply (True:l), BLSupply (False:l)) | > | > newBL (BLSupply bl) = bl | | basically we can name things by lists of bools | | we name lists using this function: | | > number :: (%ns :: BLSupply) => [a] -> [(a,[Bool])] | > number [] = [] | > number (x:xs) = (x,n) : number xs | > where n = newBL %ns | | which works fine. in ghci: | | *ImpParam> let %ns = BLSupply [] in number "hello" | [('h',[False]),('e',[False,True]),('l',[False,True,True]),('l' | ,[False,True,True,True]),('o',[False,True,True,True,True])] | | Whee. now here's the wierd thing. suppose we remove the | type signature | from the number function. then, in ghci: | | *ImpParam> :t number | forall a. (%ns :: BLSupply) => [a] -> [(a, [Bool])] | *ImpParam> let %ns = BLSupply [] in number "hello" | [('h',[]),('e',[]),('l',[]),('l',[]),('o',[])] | | what gives? why did it suddenly break even though it gets | the type right? | | - hal | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

1 0

RE: constructor names in generic classes
by Simon Peyton-Jones 30 Aug '02

30 Aug '02

Not very likely. I'm much more enthusisatic about Template Haskell just now, which lets you do similar things in a different way, and much more besides. See my home page http://research.microsoft.com/~simonpj I'm getting on with the implementation. If you are interested, check out the meta-haskell-branch of the CVS tree. It'll become the HEAD as soon as I'm sure I haven't broken anything badly, and thence get into a release. Meanwhile, constructor and field names for Derivable Type Classes languish, I fear. Simon | -----Original Message----- | From: Duncan Coutts [mailto:duncan@coutts.uklinux.net] | Sent: 30 August 2002 13:32 | To: glasgow-haskell-users(a)haskell.org | Subject: constructor names in generic classes | | | | Is it likely that the ability to access data constructor / | field names as described in the "Derivable type classes" | paper will be implemented any time soon? | | I was playing with a ShowXML / ReadXML library. It would be | much easier for users if they could just write | | instance ShowXML MyData | instance ReadXML MyData | | rather than having to use DrIFT. | | Just wondering. | | Duncan | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

constructor names in generic classes
by Duncan Coutts 30 Aug '02

30 Aug '02

Is it likely that the ability to access data constructor / field names as described in the "Derivable type classes" paper will be implemented any time soon? I was playing with a ShowXML / ReadXML library. It would be much easier for users if they could just write instance ShowXML MyData instance ReadXML MyData rather than having to use DrIFT. Just wondering. Duncan

1 0

RE: Recent GUMs?
by Simon Peyton-Jones 30 Aug '02

30 Aug '02

There's a GPH mailing list, which is the best place for GUMish questions. I don't know if they read the GHC users list. Check out http://www.cee.hw.ac.uk/~dsg/gph/ Simon | -----Original Message----- | From: Ketil Z. Malde [mailto:ketil@ii.uib.no] | Sent: 29 August 2002 14:43 | To: glasgow-haskell-users(a)haskell.org | Subject: Recent GUMs? | | | | Hi, | | I'm trying to get my hands dirty with parallel programming, | and apparently, GUM and PVM is the safest way to go. I'm | only able to find references to gum-4.06, but I couldn't | quite get the snapshot to work. | | Anyway, I just wanted to ask if I'm on the right track here. | Perhaps I'd be better off compiling GHC and GUM from the | source distribution? Is there a newer GUM than 4.06 (almost | two years old by now) available? | | Are other people using GPH out there, and if so, what tools | are you using? | | While I'm at it, is there an updated MPI port, btw? | | -kzm | -- | If I haven't seen further, it is by standing in the | footprints of giants _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

2 1

Say�n glasgow-haskell-users ,
by Green Card 29 Aug '02

29 Aug '02

1 0

Recent GUMs?
by ketil＠ii.uib.no 29 Aug '02

29 Aug '02

Hi, I'm trying to get my hands dirty with parallel programming, and apparently, GUM and PVM is the safest way to go. I'm only able to find references to gum-4.06, but I couldn't quite get the snapshot to work. Anyway, I just wanted to ask if I'm on the right track here. Perhaps I'd be better off compiling GHC and GUM from the source distribution? Is there a newer GUM than 4.06 (almost two years old by now) available? Are other people using GPH out there, and if so, what tools are you using? While I'm at it, is there an updated MPI port, btw? -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

RE: RFC: ghc's dynamic linker
by Simon Marlow 28 Aug '02

28 Aug '02

> There is another option too, which I find quite attractive. To the > interface that Simon mentioned: > > | loadLibrary :: FilePath -> IO () > | lookupEntity :: String -> IO a > > add one more call: > > addEntity :: String -> a -> IO () > > The effect is to extend GHCi's dynamic linker's symbol table with > an extra binding. So that 'lookupEntity' of the same string would > return the value you stuffed in with addEntity. True, but that doesn't address the problem of having to load another copy of the base package. And I don't think you want to take this approach for the base package: there will be a huge number of strange-looking symbols that need to be added due to cross-module inlining. On the other hand, this is a pretty short path to getting something working. Cheers, Simon

1 0

RE: RFC: ghc's dynamic linker
by Simon Peyton-Jones 28 Aug '02

28 Aug '02

| Going the final step and allowing linkage to the current | binary is possible, it just means the linker has to know how | to read the symbol table out of the binary, and you have to | avoid running 'strip'. I believe reading the symbol table is | quite straightforward, the main problem being that on Unix | you don't actually know where the binary lives, so you have | to wire it in or search the PATH. | | Another problem is that you don't normally link a *complete* | copy of the base package into your binary, you only link the | bits you need. Linking the whole lot would mean every binary | would be about 10M; but doing this on the basis of a flag | which you turn on when you want to do dynamic linking maybe | isn't so bad. There is another option too, which I find quite attractive. To the interface that Simon mentioned: | loadLibrary :: FilePath -> IO () | lookupEntity :: String -> IO a add one more call: addEntity :: String -> a -> IO () The effect is to extend GHCi's dynamic linker's symbol table with an extra binding. So that 'lookupEntity' of the same string would return the value you stuffed in with addEntity. Why is this useful? Because it enables the 'main Haskell program' to populate the symbol table with the symbols that the plugins need. I'm guessing that the dynamically loaded plugins will not need very many entry points to the main program, so the 'populate symbol table' code would look like do { addEntity "foo" foo ; addEntity "baz" baz; ..etc.. One nice feature is that this automatically makes sure that the main program mentions 'foo', 'baz' etc, even if only the plugin is meant to call them. So that makes sure that when linking the main program, all the relevant bits are linked in. (Simon mentioned this problem in his message.) This approach is v simple, it would satisfy Duncan's need (I believe), it could be made more secure using dynamic types (addEntity and lookupEntity are good moments to typecheck), and it doesn't suffer from the disadvantages that Simon M mentioned. Simon PS: I'm working on an upgrade to GHC which, among other things, happens to eliminate the need for initLinker

2 1

RE: addFinalizer & ThreadId
by Simon Marlow 28 Aug '02

28 Aug '02

> I remember that addFinalizer never did work quite the way people > expected it to. A current instantiation of this problem: adding > a finalizer to a ThreadId. Could somebody please give me a short > explanation why the following never prints "Finalize"? > [ghc is 5.04-cvs] Your finalizer runs right at the end of the program, after the stdout Handle has been closed, so it can't print anything :-) Cheers, Simon

1 0