November 2003 - Glasgow-haskell-users

RE: C--
by Simon Peyton-Jones 19 Nov '03

19 Nov '03

Norman It might be time to update the web site? Simon JP: best thing to do if you are interested in C-- is to join the mailing list. The compiler is indeed emitting code, and there is a first-cut runtime system (stack-walking etc) too. Norman and his Merrie Men have been busy. | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of JP Bernardy | Sent: 19 November 2003 14:15 | To: glasgow-haskell-users(a)haskell.org | Subject: C-- | | | Hi, | | The haskell communities report says: | | "... which we want to do now that C-- is available | (http://www.cminusminus.org)" | | which is really good to hear! :) | | The most recent news on C--.org dates August 2002 | however: "the compiler is still not ready for prime | time." Any clue? | | JP. | | __________________________________ | Do you Yahoo!? | Protect your identity with Yahoo! Mail AddressGuard | http://antispam.yahoo.com/whatsnewfree | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

C--
by JP Bernardy 19 Nov '03

19 Nov '03

Hi, The haskell communities report says: "... which we want to do now that C-- is available (http://www.cminusminus.org)" which is really good to hear! :) The most recent news on C--.org dates August 2002 however: "the compiler is still not ready for prime time." Any clue? JP. __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree

1 0

Compiling ghc
by Ulf Doz 18 Nov '03

18 Nov '03

Hi list I try to compile ghc 6.0.1 on RH 9. In my compile-it-my-self-fanatism I need to do a two-stage-bootstrap. As explained in the porting and bootstrapping documentation I used the cross-port script distrbuted with the source. But in the first stage ghc issues an error message as follows: --------- ghc-6.0.1: invalid option combination Usage: For basic information, try the `--help' option. --------- The last call make did, before the error was issued: --------- ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -package-name base -keep-hc-files-too -optc-DNO_REGS -optc-DUSE_MINIINTERPRETER -fno-asm-mangling -funregisterised -fvia-C -split-objs -c GHC/Base.lhs -o GHC/Base.o -ohi GHC/Base.hi --------- I'm not familiar with ghc, more precisely, I'm completely new to Haskell. So it would be nice if someone could give me a hint. Thanks in advance... -- Robert...

2 1

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