March 2004 - Glasgow-haskell-users

Bug report.
by MR K P SCHUPKE 25 Mar '04

25 Mar '04

Started getting: ghc-6.2.1.20040313: panic! (the `impossible' happened, GHC version 6.2.1.20040313): mkTyVar a1 {- tv a75q -} Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, or http://sourceforge.net/projects/ghc/. today... definitely a but to do with class inference, as it started appearing aftyer changing some instance constraints and fundeps on classes. Can't really be a lot more specific as code is big. Let me know if you want me to produce a small code extract which triggers it. Regards, Keean.

1 0

Data.Generics generic unification?
by John Knottenbelt 24 Mar '04

24 Mar '04

Hi Has anybody done generic unification algorithm (e.g. using Data.Generics)? The idea is to do the unifications in a state monad (like http://portal.acm.org/citation.cfm?id=507648&dl=ACM&coll=portal ), but without having to have two level types. It would be cool to have a data type, e.g. data Var a = Bound a | Unbound data STVar s a = STRef s (Var a) So then I could define my own data type, say person, with a mix of logical variables and constants: data Person :: Person s { ssn :: Int, name :: STVar s String, spouse :: STVar s (Person s) } So ssn would be a constant, while name and spouse would be logical variables. unify would need to be a generic function, bringing together basic functions like: unifyStringString :: String - > String -> ST s () unifyVarString :: STVar s String - > String -> ST s () (for basic types) and genericUnify :: a -> a -> ST s () genericVarActualUnify :: (STVar s a) -> a -> ST s () genericActualVarUnify :: a -> (STVar s a) -> ST s () genericVarVarUnify :: (STVar s a) -> (STVar s a) -> ST s () Cheers John

2 1

GHC-Head does not compile...
by MR K P SCHUPKE 24 Mar '04

24 Mar '04

I need the fixes that were (fairly) recently applied to class inference. Things are playing merry havoc with my code, and I want to make sure I am not jumpinmg through hoops because of a compiler fault. (And I also want to make sure any errors in inference I report are not already fixed). There are 2 solutions: 1) Can all fixes to class inference and instance overlapping be put into the 6.2.1 pre-release (a new version if necessary) 2) Could someone fix: (I corrected the import: GlaExts -> GHC.Exts) But the Addr type seems to have vanished. GenericTemplate.hs:121:19: Not in scope: data constructor `A#' Language/Haskell/Parser.hs:810:19: Not in scope: type constructor or class `Addr' Language/Haskell/Parser.hs:811:18: Not in scope: data constructor `A#' (error repeats at other line numbers). Regards, Keean.

1 0

RE: imports with --make?
by Simon Marlow 24 Mar '04

24 Mar '04

> Is there any way to use --make but provide paths to search > for .hi files, > *not* .hs files? For example, if a library doesn't use ghc's package > system, and is distributed in precompiled form, there doesn't seem to > currently be a way to point ghc at the import files when > using --make - it > always complains that it can't find the modules, and -v shows > that it is only looking for .hs files. No, there's no way to do this. Packages are GHC's mechanism for supporting precompiled libraries with --make or GHCi. We don't want to add another way, because things are complicated enough already. Cheers, Simon

2 1

imports with --make?
by Abraham Egnor 23 Mar '04

23 Mar '04

Is there any way to use --make but provide paths to search for .hi files, *not* .hs files? For example, if a library doesn't use ghc's package system, and is distributed in precompiled form, there doesn't seem to currently be a way to point ghc at the import files when using --make - it always complains that it can't find the modules, and -v shows that it is only looking for .hs files. Abe

1 0

[ ghc-Feature Requests-668303 ] Cygwin binaries
by SourceForge.net 23 Mar '04

23 Mar '04

Feature Requests item #668303, was opened at 2003-01-15 04:46 Message generated for change (Comment added) made by hafnert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=668303&group_i… Category: None Group: None Status: Open Priority: 5 Submitted By: Marcus Lindblom (fizzgig) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin binaries Initial Comment: A complete set of binaries for ghc and ghci under cygwin would be really nice. Using the win32-version works, but is far from satisfying. GHCI does not recognize the arrow keys, thus no command history (annoying errors instead) and I've heard others complain about problem with linking, since win32-ghc uses it's own gcc. I tried to compile ghc myself, but gave up after a few hours. Please compile it and include it in cygwin's auto-update system. ---------------------------------------------------------------------- Comment By: Thomas Hafner (hafnert) Date: 2004-03-23 15:06 Message: Logged In: YES user_id=573630 That would be really great! I tried to cross compile on a Linux box for Cygwin, but didn't succeed either. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=668303&group_i…

1 0

RE: [Haskell] ANNOUNCE: GHC version 6.2.1
by Simon Marlow 23 Mar '04

23 Mar '04

> On Monday 22 March 2004 16:40, Simon Marlow wrote: > > > > - The "threaded runtime system" is included by default. To link > > a program with this variant of the RTS, add the -threaded option > > when linking. > > After downloaded the sources i found that ./configure --help > still lists the > -threaded-rts option. Should i ignore this option or do i > have to set it? > (I'm asking because building ghc from source really takes a > *lot* of time, so > i'd rather know how to configure it before starting the build.) Ignore the option - you'll get a threaded RTS by default now. The option is left for backwards compatibiliy (I should really note that in ./configure --help). Cheers, Simon

1 0

RE: Data.HashTable bug
by Simon Marlow 19 Mar '04

19 Mar '04

Yup, that's it. It does indeed go nice and fast with GHC 5.04.3, but slows down with 6.2. This is because 6.2 is using the new Data.PackedString library, which is unoptimised. (the code also needs a fix to hashPS for 6.2: indexPS is 0-based rather than 1-based). Cheers, Simon > Does the code below look familiar? > > /Josef > > \begin{code} > -- compile with: ghc -O -package lang > -- run with: ./a.out +RTS -H10m -K4m <Input.txt > > import MArray > import PackedString > import IOExts > import IO > import Char > import Monad > > arr_size = 20000 > > main = do > h <- openFile "Usr.Dict.Words" ReadMode > sz <- hFileSize h > ps <- hGetPS h (fromIntegral sz) > > tbl <- newArray (0,arr_size) [] > mapM (addToHashTable tbl) (linesPS ps) > > h <- openFile "Input.txt" ReadMode > sz <- hFileSize h > ps <- hGetPS h (fromIntegral sz) > > let test s = do b <- elemHashTable s tbl > when (not b) (putStrLn (unpackPS s)) > mapM test (linesPS ps) > > type HashTable = IOArray Int [PackedString] > > -- Looks bad, but GHC does a great job of optimising it: > hashPS :: PackedString -> Int > hashPS ps = foldr f 0 (map (ord.indexPS ps) [1..lengthPS ps]) > where f n m = n + m * 128 `mod` 1048583 > > addToHashTable :: HashTable -> PackedString -> IO () > addToHashTable tbl s = do > let h = hashPS s > index = h `mod` arr_size > r <- readArray tbl index > if (s `elem` r) then return () else do > writeArray tbl index (s : r) > > elemHashTable :: PackedString -> HashTable -> IO Bool > elemHashTable s tbl = do > let h = hashPS s > index = h `mod` arr_size > r <- readArray tbl index > return (s `elem` r) > \end{code} > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

1 0

RE: Data.HashTable bug
by Simon Marlow 19 Mar '04

19 Mar '04

> looking at `The Great Computer Language Shootout' mentioned in another > thread, I wanted to try if Data.HashTable gives better results than > Data.FiniteMap for the spell checker test > http://www.bagley.org/~doug/shootout/bench/spellcheck/ > > I came up with the attached program. With data files > > http://www.bagley.org/data/shootout/spellcheck/Usr.Dict.Words > http://www.bagley.org/data/shootout/spellcheck/Input > > it yields the result > > carsten@penne:~/t> ./a.out < Input > blooper > cager > cashmere > coming > tablespoonful > zuul > > However, the result should be only `zuul'. Is the problem in > Data.HashTable? I have tested, 6.0, 6.2, 6.2.20040304. Eek! There are two bugs in Data.HashTable. One correctness, and one performance. Thanks for the report, I'll hold up the 6.2.1 release to get this one in. However, your hash table version of the spell checker doesn't go any faster than the FiniteMap version. I haven't investigated why, though. I did post a hash table version of this program a while back, that I claimed was a factor of 3 faster at the time. Unfortunately the attachment in the archive is in base64 and I can't read it, and I've lost the code :-( If you can decode the attachment, it's here: http://www.haskell.org/pipermail/haskell-cafe/2001-July/002061.html Cheers, Simon

2 1

Haskell performance
by Sébastien Pierre 19 Mar '04

19 Mar '04

Hi all, I am a Haskell newbie, but have been interested in Haskell (and generally speaking ML-derivates) for some time. I am currently evaluating different languages for implementing an application which will have to manipulate large graphs representing the structure of programs and their evolution. In this respect, I need to find a language which offers a proper paradigm for implementation of graph algorithms (possibly involing some AI techniques), while offering great speed. Speed is in fact a crucial criterium for the language choice. I once read that Haskell was rather slow, especially when compared to Standard ML, which seems to be confirmed by "The Great Computer Language Shootout" (http://www.bagley.org/~doug/shootout/craps.shtml) However, this performance comparison seems rather outdated, so I wanted to know if GHC had improved in performance in the meantime. For now, the (somewhat unpleasing) conclusion I came with is that a Java (app core), Python (proto, UI) plus some interfaced C++ libs would be OK... but I would largely prefer to use a fonctional language for my application core. OCaml would have been just great, if only it had a properly designed library and a decent syntax... like Haskell ! What do you Haskell-experts could say about using Haskell for an application requiring graph processing performance ? TIA, -- Sébastien

8 10