- Glasgow-haskell-users

-O2
by Saswat Anand 15 Apr '02

15 Apr '02

Hi, In my program I observe that, with -O2 flag turned on, Program 1 behaves like Program 2. And without O2, their outputs are different. Is it the desirable behaviour? For my program, I did not expect the optimizer to do this transformation. Thanks, Saswat Program 1: eval = \..-> let t = some_long_expression tree q = Tree (w:=q) some_long _expression in if w /= 0 then concatMap (cc con1) [tree x | x <- [1..n]] else t Program 2: eval = \..-> let t = some_long_expression tree q = Tree (w:=q) t -- Here is the difference in if w /= 0 then concatMap (cc con1) [tree x | x <- [1..n]] else t some_long_expression stands for, concatMap (cc con2) $ zipWith join (eval v c1 (reverse v1)) (eval v c2 v2)

1 0

handling of multibyte char strings
by Jens Petersen 14 Apr '02

14 Apr '02

GHC 5.02.[23] seems to be quite strict about literal strings in source code. I presume this is a feature. :-) However this is annoying for people who want to use wide chars in strings in source code. (Though I realise that doing so is not very "portable".) To illustrate, the following program main :: IO () main = let ja = 'Japanese character' in putChar ja >> putChar '\n' results in Compiling Main ( test-ja.hs, interpreted ) test-ja.hs:3: error in character literal Failed, modules loaded: none. with both ghc and ghci. Is anything allowed in literal strings except ascii? utf-8? Jens

3 2

RE: An answer and a question to GHC implementors [was Re: How to make Claessen's Refs Ord-able?]
by Simon Marlow 11 Apr '02

11 Apr '02

> > However, it is possible to have global top-level references using > > unsafePerformIO if you're very careful about it. In GHC we > do something > > like this: > > > > {-# NOINLINE global_var #-} > > global_var :: IORef Int > > global_var = unsafePerformIO (newIORef 42) > > > > the NOINLINE pragma is used to ensure that there is > precisely *one* copy > > of the right hand side of global_var in the resulting > program (NOTE: you > > also need to compile the program with -fno-cse to ensure that the > > compiler doesn't also common up the RHS of global_var with > other similar > > top-level definitions). > > this usage of unsafePerformIO is such a staple of real-world Haskell > programming, it seems there should be some language (or experemental > compiler *wink wink ghc nudge*) support for it. I am not sure > what form > it would take though. <muse> I did wonder once whether IO monad bindings should be allowed at the top-level of a module, so you could say module M where ref <- newIORef 42 and the top-level IO would be executed as part of the module initialization code. This solves the problems with unsafePerformIO in a cleanish way, but would add some extra complexity to implementations. And I'm not sure what happens if one top-level IO action refers to other top-level IO bindings (modules can be recursive, so you could get loops too). </muse> > getGlobalVar :: IO (IORef Int) > getGlobalVar = memoIO (newIORef 42) > > note that this is not exactly the same since getting the global var is > in the io monad, but that really makes sense if you think > about it. and > chances are you are already in IO if you need an IORef. This doesn't really solve the problem we were trying to solve, namely that passing around the IORef everywhere is annoying. If we were happy to pass it around all the time, then we would just say main = do ref <- newIORef 42 ... pass ref around for ever ... We could use implicit parameters, but that means changing the types of lots of functions, and that's just as annoying as actually passing the arguments around explicitly. Cheers, Simon

3 2

RE: ANNOUNCE: GHC 5.03.20020410 snapshot released
by Simon Marlow 11 Apr '02

11 Apr '02

> > Another snapshot along the 5.03 line, we expect this to be the last > > snapshot before 5.04. As before, there are NO GUARANTEES as to the > > stability of this release, but it has passed our > three-stage bootstrap > > and all but one(!) of the 754 regressions tests passed. > Documentation is > > also still lagging behind the new features. > > Hi, > > I tried > > ./configure --prefix=$HOME/Lang > make all > > but the latter command fails with: > > mk/target.mk:45: mk/package.mk: Datei oder Verzeichnis nicht gefunden > make: *** No rule to make target `mk/package.mk'. Stop. Sigh, I'll re-roll the source dist. Thanks for pointing it out. Simon

1 0

ANNOUNCE: GHC 5.03.20020410 snapshot released
by Simon Marlow 11 Apr '02

11 Apr '02

Another snapshot along the 5.03 line, we expect this to be the last snapshot before 5.04. As before, there are NO GUARANTEES as to the stability of this release, but it has passed our three-stage bootstrap and all but one(!) of the 754 regressions tests passed. Documentation is also still lagging behind the new features. Get it from the usual place: http://www.haskell.org/ghc/ Changes since the previous snapshot (5.03.20020204): * GHC switched over to the new hierarchical library structure for its base libraries. The old hslibs and the standard Haskell 98 libraries are still there, so you shouldn't notice any difference for existing code. We're currently working on documenting the new library structure for the next release. * The syntax for implicit parameters has changed: implicit bindings are now introduced with the let keyword instead of with. The bindings in a let must be either all implicit bindings or all explicit, not a mixture of the two. The old with syntax will be supported for a couple of versions or so, but will elicit a warning message from the compiler if you use it. * Foreign export dynamic is allegedly working in GHCi. * Generics are working again. * Explicit kind annotations can now be given on type variables. See the documentation (type system extensions, explicitly-kinded quantification) for more details. * Interface files are now in a binary format for speed of reading/writing. Use ghc --show-iface to show the textual representation of an interface. The synatx of .hi-boot files has changed, and is now much more readable. Cheers, Simon

2 1

getting types out
by Hal Daume III 11 Apr '02

11 Apr '02

I know -ddump-types will get me the types of top level functions, but is there a way to get ghc (or really any compiler) to dump the types of everything (or at least more than that, maybe just locally bound definitions)? - 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

2 1

register error
by Andre W B Furtado 10 Apr '02

10 Apr '02

While trying to install GHC-5.02.3 (win32 release) in my computer (Windows 98), I got the following error message: Error 1406: Could not write value _MainFeature to key HKEY_LOCAL_MACHINES\Software\Microsoft\Windows\CurrentVersion\Installer\Feat ures\8C655693FA0801D4E87FA1CA60C4AAE1 Verify that you have sufficient access to that key, or contact your support personel. I then finished the installation, and would like to ask 2 things: 1. What problems am I supposed to expect with this error? 2. Why this happened? I though I had sufficient access to all needed register keys... :) Thanks, -- Andre

1 0

RE: concurrent --make
by Simon Marlow 10 Apr '02

10 Apr '02

> Dear GHC (5.02.2), > > By occasion, can you --make things parallelwise, concurrently ? > For we have 6 processors here, and > ghc -O --make <HeadModule> > > takes more than 60 minutes on one procesor to `make' my application > (to find import dep-s, compile many .hs modules, create libraries). > > Also `making' GHC from source takes more that 4 hours on one > processor. We'd like to do something like this, but it's not high up the priority list. For the time being, you can use normal Makefiles with 'ghc -M' to create dependencies, and then use 'make -j' to get parallelism. Cheers, Simon

1 0

concurrent --make
by Serge D. Mechveliani 10 Apr '02

10 Apr '02

Dear GHC (5.02.2), By occasion, can you --make things parallelwise, concurrently ? For we have 6 processors here, and ghc -O --make <HeadModule> takes more than 60 minutes on one procesor to `make' my application (to find import dep-s, compile many .hs modules, create libraries). Also `making' GHC from source takes more that 4 hours on one processor. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: GHC 4.08.2 binaries for OpenBSD i386 available
by Simon Marlow 10 Apr '02

10 Apr '02

Hi Donald, > I've finished a port of GHC 4.08.2 to OpenBSD i386. > The binary package (12M) can be ftp'd from: > > ftp://ftp.cse.unsw.edu.au/pub/users/dons/ghc/ghc-4.08.2.tgz That's great news. Have you tried using that to build a newer release of GHC? I'd like to get any patches that you have incorporated into the main tree so we can support OpenBSD in the future. Cheers, Simon

1 0