- Glasgow-haskell-users

Transient compilations on CVS code
by Rafael Martinez Torres 18 Nov '03

18 Nov '03

Hi: I'm a newbie on using CVS but some time ago I decided to compile against the code on the CVS repository. I'm interested on 6.3 version. Recently I found this problem, after making autoheader,autoconf: ghc/include: make boot mkDerivedConstants.c:34 'StgTickyInfo' undeclared (first use of this function) is this a transient problem to be solved or I'm doing something wrong ? And three weeks ago, on the configure script, I was asked to download the alex tool, when on older versions (from tar.gz) this was not necessary ... Thanks...

1 0

RE: Executable size?
by Simon Marlow 13 Nov '03

13 Nov '03

> [apologies to anybody who sees the rather similar message I posted to > caml-list...] > > How does Haskell (ghc) compare with languages like O'Caml, C > and C++ for > executable size? How big is the runtime library? > > Are there any easily-identifiable, non-obvious, factors that affect > executable size (I'm talking about end-use factors, rather > those resulting > from the design decisions taken by the language designers and > implementors)? > > I currently use Python by preference, but I'm interested in a language > (other than C/C++!) that doesn't depend on a big runtime library and > generates "reasonably" small executables -- modems are here > to stay for a while yet. We do our best to keep the executable sizes down, but the fact is that GHC binaries are mostly statically linked, so they're going to be large. There's a FAQ entry on static vs. dynamic linking if you're interested. It might be possible to implement dynamic linking these days, because one of the obstacles that prevented it in the past was removed in GHC 6.0 (as a result of eval/apply, we no longer need to identify the extents of text segments in the address space). Cheers, Simon

1 0

Executable size?
by John J Lee 12 Nov '03

12 Nov '03

[apologies to anybody who sees the rather similar message I posted to caml-list...] How does Haskell (ghc) compare with languages like O'Caml, C and C++ for executable size? How big is the runtime library? Are there any easily-identifiable, non-obvious, factors that affect executable size (I'm talking about end-use factors, rather those resulting from the design decisions taken by the language designers and implementors)? I currently use Python by preference, but I'm interested in a language (other than C/C++!) that doesn't depend on a big runtime library and generates "reasonably" small executables -- modems are here to stay for a while yet. Thanks for any help John

1 0

Local qualification in data types
by Josef Svenningsson 11 Nov '03

11 Nov '03

Hi, I'm playing around with the type system trying to encode various stuff in it. I've gotten an error though which it would be useful to understand. Say I have a type class: class Foo a and then I want a datatype like this: data Bar a = Foo a => C1 | C2 ... | C3 This works fine syntactically but ghc says that I must have at least one existential type variable in the constraint. Hugs doesn't require that but has other problems.... Is there a good reason for not allowing the above? Cheers, /Josef

1 0

RE: command line option --show-iface
by Simon Peyton-Jones 10 Nov '03

10 Nov '03

Good idea -- done. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Steffen Mazanek | Sent: 27 October 2003 21:27 | To: glasgow-haskell-users(a)haskell.org | Subject: command line option --show-iface | | Hello, | | the following error is slightly confusing: | | ghc --show-iface | ghc-6.0.1: unrecognised flag: --show-iface | Usage: For basic information, try the `--help' option. | | ghc --show-iface Unify.hi | __interface "Main" Unify 1 where | __export Unify Unifiable{mgu} match mguType varBind; | ... | | A hint in the right direction would be more | convenient :-) | | Maybe in /ghc/compiler/main/DriverUtil.hs a function | | unknownFlagErrUsage :: String->String -> a | unknownFlagErrUsage f specusage = throwDyn | (UsageError ("unrecognised flag: " ++ f ++ "\n" ++ | "hint: " ++ specusage)) | | and changing processOneArg from DriverFlags.hs | | HasArg fio -> | if rest /= "" | then fio rest >> return args | else case args of | [] -> unknownFlagErrUsage dash_arg "argument for flag expected" | (arg1:args1) -> fio arg1 >> return args1 | | Would this be ok? | | Regards, | Steffen | _______________________________________________ | 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 weirdness
by Simon Marlow 10 Nov '03

10 Nov '03

> I have some code that uses the Data.HashTable module (passing > around a > hash table as part of the state in a state monad). I had a > function which > took a key and value and added it to the hash table, using > the HashTable.insert > function. When I changed this function to delete the key from > the table first, > using HashTable.delete, the behavior of the function changed. > That is, at > first, looking up a key in the table gave a wrong result > (seemingly, a "stale" > value), but after changing the function to delete the key > before adding it, > my program behaved correctly. > > This seems strange to me. According to my understanding of > how a hash table > should work, inserting a key in the table should overwrite > the previous value > for that key, so inserting a key should be equivalent to > deleting it and then > inserting it. But clearly that's not the case here. Can > anyone explain this? Inserting doesn't actually delete other entries with the same key (for speed), but as far as I can tell that shouldn't make any difference to the semantics. If you insert then lookup the same key, you should always get the most recently inserted value back. That is, unless the compare and hash functions passed to Data.HashTable.new are wrong. The docs should probably say that, for 'new eq hash', the following implication should hold: eq A B => hash A == hash B Assuming this isn't your problem, you may have found a bug. Can you put together a repeatable test case? Cheers, Simon

1 0

RE: DiffArray Performance
by Simon Marlow 10 Nov '03

10 Nov '03

> >This is one good reason they have to be protected by MVars > > Forgive my stupidity, but arn't the MVar operations > (takeMVar, putMVar) > IO operation, therefore the locks must be in the IO monad, therefore > the code acting on the DiffArray should be in the IO monad... > otherwise they can't use the MVar calls? DiffArray is an example of a good use for unsafePerformIO: it uses imperative operations to implement a pure API. The DiffArray is made of mutable objects under the hood, but as far as the programmer is concerned it behaves just like a pure Array. Cheers, Simon

4 3

Why does sizeOf Word64 = 4?
by Ben Escoto 09 Nov '03

09 Nov '03

Hi, I'm trying to learn about Haskell's FFI (running 6.0.1 on linux) and see the following weird behavior with ghci: Prelude> :module Data.Word Foreign.Storable Foreign.Ptr Prelude Foreign.Ptr Foreign.Storable Data.Word> sizeOf nullPtr 4 Prelude Foreign.Ptr Foreign.Storable Data.Word> sizeOf (nullPtr :: Ptr Word64) 4 Shouldn't "sizeOf nullPtr" return an error? And sizeOf a Ptr Word64 should be 8 I think. Also this program prints "4", when it seems it should print "8": module Main where import Data.Word import Foreign.Storable import Foreign.Ptr import Foreign.StablePtr x :: Word64 x = 5 main = do x_sptr <- newStablePtr 5 putStrLn $ show $ sizeOf x_sptr These are artificial examples, but I originally noticed this when trying to decode a C structure. Is this a bug in ghc or am I misunderstanding what sizeOf is supposed to do? -- Ben Escoto

4 4

Data.HashTable weirdness
by Kirsten Chevalier 08 Nov '03

08 Nov '03

I have some code that uses the Data.HashTable module (passing around a hash table as part of the state in a state monad). I had a function which took a key and value and added it to the hash table, using the HashTable.insert function. When I changed this function to delete the key from the table first, using HashTable.delete, the behavior of the function changed. That is, at first, looking up a key in the table gave a wrong result (seemingly, a "stale" value), but after changing the function to delete the key before adding it, my program behaved correctly. This seems strange to me. According to my understanding of how a hash table should work, inserting a key in the table should overwrite the previous value for that key, so inserting a key should be equivalent to deleting it and then inserting it. But clearly that's not the case here. Can anyone explain this? -- Kirsten Chevalier * krc(a)cs.berkeley.edu * Often in error, never in doubt "The information superhighway showed the average person what some nerd thinks about Star Trek."--Homer Simpson http://www.cs.berkeley.edu/~krc/

1 0

Show (Set a)
by Serge D. Mechveliani 08 Nov '03

08 Nov '03

Dear GHC developers, In my user program I define instance Show a => Show (Set a) where showsPrec x = showsPrec x . setToList instance (Show a, Show b) => Show (FiniteMap a b) where showsPrec x = showsPrec x . fmToList On the other hand, is not this natural for the GHC library to provide such instances? (add, please, mechvel(a)botik.ru to the respond list) ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0