August 2002 - Glasgow-haskell-users

RE: comparison of execution speed of array types
by Zdenek Dvorak 20 Jan '03

20 Jan '03

Hello, >DiffArray seems to be broken :). Either that or I'm using it >incorrectly. I've attached the relevant code, but when I don't reverse >the array everything works fine; when I reverse it the program doesn't >(seem to) halt. I've tried to use DiffArray recently and it is terribly slow. I was forced to write my own version (it is a bit faster, but still nothing great). My suspicion about the result of your measuring is that it does the updates in reversing the array one by one, thus leading to quadratic behavior. Zdenek Dvorak _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

2 1

mergesort. Reply
by Serge D. Mechveliani 21 Oct '02

21 Oct '02

Ketil Z. Malde <ketil(a)ii.uib.no> writes > I'll hereby argue for using a quicksort implementation akin to > >> sortBy' _ [] = [] >> sortBy' pc (x:xs) = let (l,e,g) = part3 (`pc` x) xs >> in sortBy' pc l ++ (x:e) ++ sortBy' pc g >> where >> part3 comp xs = p3 [] [] [] comp xs >> p3 ls es gs _ [] = (ls,es,gs) >> p3 ls es gs comp (x:xs) = case comp x of >> LT -> p3 (x:ls) es gs comp xs >> EQ -> p3 ls (x:es) gs comp xs >> GT -> p3 ls es (x:gs) comp xs > > (hopefully this is fairly bug-free) At least for my data (lots of > values, limited range), it appears to speed things up tremendously. I > haven't measured more general cases in any detail, though. And one > obvious drawback may be that it's not stable, which I think can be > alleviated by a few well placed 'reverse's. > > Comments welcome! But sortBy' (compare) [1 .. n] costs too much, even for n = 11000. It costs (on worst data) many times more than mergeSort. ----------------- Serge Mechveliani mechvel(a)botik.ru

8 11

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