February 2005 - Glasgow-haskell-users

Help with a Shootout program
by Alson Kemp 24 Feb '05

24 Feb '05

All, In order to teach myself Haskell, I've been tinkering with some of the Shootout (http://shootout.alioth.debian.org/great/) programs. Substantially improved the Mandelbrot program. Then started to work on the Spellcheck program, since Haskell seemed to do quite poorly at it. However, my revision appears to be slower than the original. I was hoping that I could get some help from y'all. Original program: import Data.Set main = do d <- readFile "Usr.Dict.Words" let misspelled x = not $ x `elementOf` (mkSet (lines d)) interact $ unlines . filter misspelled . Lines The original program is nice and short, but uses Set to hold the 80,000 word dictionary. The Input file is 80,000 words, too, so I figured that searching the Set dictionary would be an O(n^2) task (80,000 spellchecks x linear search on 80,000 word dictionary Set). All of the other languages used hash tables for this task (O(n) (80,000 spellchecks x hash search on dictionary), so I revised the program to do the same. ---------------------------------------- Revised program: import Data.HashTable import IO import GHC.Int buildHash :: (String -> Int32) -> String -> IO (HashTable String Bool) buildHash hash_fn list = do table <- new (==) hash_fn sequence_ [ insert table k True | k <- lines list ] return table spellcheck :: HashTable String Bool -> String -> String -> IO String spellcheck ds "" accum = return accum spellcheck ds xs accum = let (x, xs') = break (== '\n') xs in do r <- Data.HashTable.lookup ds x case r of Just b -> spellcheck ds (tail xs') accum _ -> spellcheck ds (tail xs') (x ++ accum) main = do ds <- readFile "Usr.Dict.Words" >>= buildHash hashString hGetContents stdin >>= (\xs -> spellcheck ds xs "") >>= print ---------------------------------------- The Revised program is 33% faster than the Original program using the original dataset. However, if I boost the Input to 1.4M words while keeping the dictionary the same, then the two programs are equal in speed. This suggests that loading the dictionary and building the Hash/Set is faster in the Revised program, but that _lookups_ are _slower_ in the Revised program. Is Hashtable.lookup really slower than Set.elementOf? I'm missing something and I don't know what it is. Frustrating. - Alson

2 1

Kinds in ghc
by Johan Glimming 24 Feb '05

24 Feb '05

Hi I can report success on compiling latest CVS on Mac OS X including stage 2 with ghci support. (greencard does not compile, but that's not a problem for ghc to be compiled it seems.) Now that I have the compiler up, I notice that types are not reported as before. Instead of nice t,t', etc, I get random strings: Kind error: Expecting kind `k_a1JA -> k_a1JE -> k_a1JI -> *', but `DUnit t' has kind `k_a1JA -> k_a1JE -> *' Is this a mere debug mode I have enabled by accident (no parameter passed to make or configure though), or is this something else? P.S. infix type synonyms seems to work well so far! Johan Glimming.

1 0

new ghc under solaris
by Christian Maeder 24 Feb '05

24 Feb '05

Hi Simon and solaris GHC users, I've made progress with ghc HEAD under solaris 8. In fact I could successfully install a ghc-6.5 compiler that was able to compile a couple of files (including "Hello World") But on one file (by chance HughesPJ.hs with an unqualified module name) I got a "Bus Error" (see below) I'll try now if "gmake bootstrap3" fails, too. During "gmake" also the _FILE_OFFSET_BITS warning was not entirely gone: In file included from ../includes/ghcconfig.h:4, from ../includes/Stg.h:42, from ../includes/Rts.h:19, from RetainerSet.c:14: ../includes/ghcautoconf.h:364: warning: `_FILE_OFFSET_BITS' redefined /usr/include/sys/feature_tests.h:96: warning: this is the location of the previous definition. (There were numerous other warnings, too many to post here.) I assume there's not much difference between ghc-6.5 und ghc-6.4 prerelease. Is someone else on the list interested in a solaris distribution and could contribute? Cheers Christian maeder@leo -> ghc -v HughesPJ.hs Glasgow Haskell Compiler, Version 6.5, for Haskell 98, compiled by GHC version 6.2.2 Reading package config file: /home/maeder/leo-ghc-head/lib/ghc-6.5/package.conf Hsc static flags: -static *** Checking old interface for HughesPJ: *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 2602 *** Simplify: Result size = 3233 Result size = 2618 Result size = 2345 Result size = 2345 *** Tidy Core: Result size = 2345 *** CorePrep: Result size = 2877 *** Stg2Stg: *** CodeGen: *** CodeOutput: Bus Error

1 0

Getting ghci to work (Mac OS X & ghc-6.5 from CVS)
by Johan Glimming 23 Feb '05

23 Feb '05

Hi I got ghc-6.5 prerelease from the CVS and managed to get it up and running, *except* for ghci, the interactive part. Is there something in particular that I need to think about to make ghci support get compiled into ghc? Johan Glimming.

2 1

RE: Configuring in directories with spaces fails in ghc6.4
by Simon Marlow 23 Feb '05

23 Feb '05

On 22 February 2005 14:35, Malcolm Wallace wrote: > However, it could be worthwhile halting with an error message. > > case `pwd` in > *' '*) > echo "Error: nhc98 will not build in a directory with spaces > anywhere" echo " in the full pathname." > echo "Suggestion: move the build tree somewhere else." > exit 1 ;; > esac Good idea, done. Simon

1 0

RE: GHC-problem with parsing infix type synonyms - bug?
by Simon Peyton-Jones 23 Feb '05

23 Feb '05

OK, done. I've documented infix classes too. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Johan Glimming | Sent: 17 February 2005 10:04 | To: <glasgow-haskell-users(a)haskell.org> <glasgow-haskell-users(a)haskell.org>; Simon Marlow | Subject: Re: GHC-problem with parsing infix type synonyms - bug? | | > I think the syntax used in your type synonym declaration isn't | > supported | > at the moment. For consistency it probably should be. | | Is there any chance to fix this in the next 6.4 release, or can I patch | 6.4 myself? (I'd need hints though.) I have some code in a project for | which I want to use type synonyms for instead of data type definitions, | to save on all the constructor names hanging around. | | Johan Glimming. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RFC: hyperlinks in Haddock docs
by Simon Marlow 22 Feb '05

22 Feb '05

I'm making some changes to the way Haddock creates links, and I'd like to solicit comments on possible alternatives. The existing approach is for each non-locally-defined identifier in the current module, we hyperlink to a module that it was imported from, and that (a) actually documents the identifer, and (b) isn't hidden. There are some problems with the existing approach. It doesn't cope well with instances: instances might refer to types/classes not below the current module in the hierarchy. Also you might import an entity from a "hidden" module, but actually want to hyperlink to another module in the hierarchy, not below the current one. Hyperlinking in the documentation doesn't follow the module import hierarchy, and nor should it. So the new approach is to try to build up a global table of the "best" destinations to link to for each entity. The question is how to determine "best". Here's my first stab: - A is better than B if A directly or indirectly imports B But this isn't quite good enough: for example the Prelude re-exports a lot of stuff, but when linking Maybe for example, we probably want to link to Data.Maybe.Maybe rather than Prelude.Maybe. But the Prelude is the right place to get Int and String from. I don't particularly want the programmer to have to say for each entity where the best place to get it from is, much better would be to have a per-module flag that says "this module is a good/bad link destination". Perhaps we actually want to give an integer priority in each module. Thoughts? Better ideas? Cheers, Simon

5 6

RE: Configuring in directories with spaces fails in ghc6.4
by Simon Marlow 22 Feb '05

22 Feb '05

On 22 February 2005 12:05, Anders Höckersten wrote: > It seems the ghc 6.4 release candidates' configure scripts fail if you > run them in a directory structure containing a space. In my case, > being in /home/chucky/My Downloads fails with: > configure: creating ./config.status > config.status: creating ghc.spec > config.status: creating VERSION > config.status: creating docs/users_guide/ug-book.xml > config.status: creating mk/config.mk > config.status: creating mk/version.mk > ./configure: line 20341: cd: /home/chucky/My: No such file or > directory Quite possibly. No doubt we'd have to add a million quotes to the build system to fix this; it's not going to happen any time soon. "don't do that" Cheers, Simon

2 1

RE: compiling GHC with a custom path to GCC
by Simon Marlow 22 Feb '05

22 Feb '05

On 18 February 2005 09:42, Simon Marlow wrote: > On 18 February 2005 01:02, Donald Bruce Stewart wrote: > >> This is a known problem with gcc-2.95. >> We came across it back in September. >> >> It was noticed in the nightly builds: >> >> http://www.haskell.org/pipermail/cvs-all/2004-September/035116.html >> >> And then we chased it up: >> >> http://www.haskell.org/pipermail/cvs-all/2004-September/035122.html >> http://www.haskell.org/pipermail/cvs-all/2004-September/035134.html >> http://www.haskell.org/pipermail/cvs-all/2004-September/035259.html >> http://www.haskell.org/pipermail/cvs-all/2004-September/035268.html >> http://www.haskell.org/pipermail/cvs-all/2004-September/035293.html > > Don, thanks for the pointer, I'd completely forgotten about that. > > I think I'll be able to install a workaround for 6.4 based on the gcc > version. I need it at least because FreeBSD 4.x still uses gcc 2.95, > and AFAIK quite a few folks are still using that platform. I've put in a workaround for this problem, which will show up in tonight's STABLE snapshot. It works for me on FreeBSD 4.11 with gcc 2.95.4. Cheers, Simon

1 0

Configuring in directories with spaces fails in ghc6.4
by Anders Höckersten 22 Feb '05

22 Feb '05

Hi, It seems the ghc 6.4 release candidates' configure scripts fail if you run them in a directory structure containing a space. In my case, being in /home/chucky/My Downloads fails with: configure: creating ./config.status config.status: creating ghc.spec config.status: creating VERSION config.status: creating docs/users_guide/ug-book.xml config.status: creating mk/config.mk config.status: creating mk/version.mk ./configure: line 20341: cd: /home/chucky/My: No such file or directory This is on amd64 linux. Cheers, Anders

1 0