- Glasgow-haskell-users

Re: GHC rewrite rules pragma
by Don Stewart 27 May '08

27 May '08

jakubuv: > Thanks lot, it works now. Now, I have just a simple question: > > Is there any chance to make rewriting working in ghci ? I think you can actually enable them by putting: {-# OPTIONS -frewrite-rules #-} at the top of the file to be interpreted. Works for me, anyway. -- Don

2 1

ghci Problem
by Dominic Steinitz 26 May '08

26 May '08

I've built ghc and installed it but when I run ghci e.g. the up arrow keys don't work :-( Can someone let me know what I've done wrong and how to fix it? Thanks, Dominic. > dom@lagrange:~/ndp> ghci > GHCi, version 6.9.20080517: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Prelude> ^[[A

3 6

integer size on NetBSD amd64
by Donn Cave 23 May '08

23 May '08

I have been trying to get ghc working on the NetBSD AMD64 platform, and there seems to be a little problem with the integer size. With minInt and maxInt defined as they are in GHC/Base.lhs, ghc can't compile this file - it cranks away and just gets bigger until all the memory is gone. Base.lhs compiles right away if I reduce the size of minInt and maxInt by several bits - minInt = I# (-0x2000000000000000#) maxInt = I# 0x1FFFFFFFFFFFFFFF# -- minInt = I# (-0x8000000000000000#) -- maxInt = I# 0x7FFFFFFFFFFFFFFF# (... and it goes on to crash in GHC/Num.lhs.) So ... maybe somewhere in there, something isn't configured right for 64 bit integer arithmetic, even though the word size parameters in ghcautoconf.h look right? Anyone have an idea what to look for? The GHC version is 6.6.1. The .hc donor host is OpenBSD, gcc3 (NetBSD has gcc4.) The include files from NetBSD (DerivedConstants.h, GHCConstants.h, ghcautoconf.h) look fine, I just went back to the OpenBSD build to verify that they weren't changed during the build. The procedure I'm following is `Cross-compiling to produce an unregisterised GHC' http://hackage.haskell.org/trac/ghc/wiki/Building/Porting thanks! Donn Cave, donn(a)avvanta.com

2 1

Re[4]: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core
by Bulat Ziganshin 23 May '08

23 May '08

Hello Duncan, Friday, May 23, 2008, 11:55:57 PM, you wrote: >> > me too. btw, this already present in jhc. inlining doesn't work in any >> > complex case since recursive functions can't be inlined >> >> GHC inlines recursive functions, too, otherwise it could not turn 'foldl' >> and friends into plain machine loops. > As I understand it, if foldl was written in the standard directly way > then ghc would not inline it well, i'm not a True GHC Hacker ;) but i was bitten by this problem in 6.4. i had a lot of SPECIALIZE pragmas in Streams library exactly because INLINE doesn't help. actually, it even does things worser by disabling some other form of optimization, i don't remember which one i have proposal of inlining even recursive functions just for one level of recursion in order to allow to call here specialized version of function. what GHC HQ will say? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

Type checker loops with innocent looking associated type synonym
by Stefan Holdermans 22 May '08

22 May '08

I've written this cute ;-) piece of code involving an associated type synonym, {-# OPTIONS_GHC -fglasgow-exts #-} class ZipWithA a where type Elem a :: * zipWithA :: [Elem a] -> a instance ZipWithA [a] where type Elem [a] = a zipWithA xs = xs instance ZipWithA b => ZipWithA ([a] -> b) where type Elem ([a] -> b) = a -> Elem b zipWithA fs = zipWithA . zipWith ($) fs and it behaves as intended: *Main> zipWithA [2, 3] :: [Int] [2,3] *Main> zipWithA [pred, succ] [2, 3] :: [Int] [1,4] *Main> zipWithA [(+), (-)] [2, 3] [5, 7] :: [Int] [7,-4] However, as soon as the overloading cannot be resolved, the type checker loops: *Main> zipWithA [head, last] ["more than", "haskell"] :: String "ml" *Main> zipWithA [head, last] ["more than", "haskell"] <<loops>> Just to be clear, I do not expect GHC to be able to type this last example, I would just have thought it would want to tell me in finite time that it cannot resolve the overloading here. Should I report this a bug? Or is it perhaps already been taken care of in the head? Or am I just plain unreasonable here? :-) Cheers, Stefan

3 3

Re: -optc-O2 considered useful
by Bernd Brassel 20 May '08

20 May '08

I think it would be nice to have some speedy optimizations turned on by default in ghc. Might even be good to win new users. But I also think that much hacking for and around ghc+tool support needs a way to achieve what -O0 does today. So, how about an -O(-1) or flag?

1 0

whence _stub.c ?
by Conal Elliott 20 May '08

20 May '08

what causes ghc to emit a stub.c file? - Conal

3 2

Experiment: ghc-api and --split-objs
by Bertram Felgenhauer 20 May '08

20 May '08

Hi, I've made an experiment compiling ghc-api with --split-objs. To summarize, while this is not worthwhile for the compiler itself, it could be a huge win for plugin libraries. A fairly detailed description can be found here, http://int-e.home.tlink.de/haskell/README.ghc-api-test A tarball with the examples and auxiliary files is at http://int-e.home.tlink.de/haskell/ghc-api-test.tar.bz2 Open questions: - How much work would it to do this within the ghc build? - Maybe users that only need the parser can win as well? Haddock comes to mind here. In any case, this is food for thought, I hope. Enjoy, Bertram

2 1

making GHC from source
by Serge D. Mechveliani 19 May '08

19 May '08

People, I need to install ghc-6.8.2 from source. As I recall, this needs Happy and Alex. Right? Among Happy versions, it is visible only a couple latest ones, and to install any of them, one needs Cabal. Installing Cabal is as follows: make install mkdir -p dist/tmp ghc --make -cpp -Wall -DCABAL_VERSION=1,2,3,0 -i. -odir dist/tmp -hidir dist/tmp Setup.lhs -o setup make: ghc: command not found. We have a `make' loop: ghc --> Happy --> Cabal --> ghc Old Happy was good: it did not require GHC -- as I recall. Do I mistake? Now I have to install GHC from binary, and it will report of library version mismatch ... and so on. Do not you think that, generally, something is going wrong here? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru http://www.botik.ru/~mechvel

2 1

bug in 6.8.2?
by Bulat Ziganshin 19 May '08

19 May '08

Hello glasgow-haskell-users, i've rather complicated class structure: class BufferData a where instance (FastBufferData a) => BufferData a where class FastBufferData a where instance (Storable a) => FastBufferData a where of course, it's compiled with -fallow-undecidable-instances -fallow-overlapping-instances -fallow-incoherent-instances BufferData class includes procedure `write`: class BufferData a where write :: OutStream -> a -> IO () there is writeAll procedure which uses this `write` and therefore should be able to write any BufferData instance: writeAll receiveBuf sendBuf cleanup x = bracket (create receiveBuf sendBuf cleanup) (closeOut) (\buf -> write buf x) it works great in 6.6.1 but in 6.8.2 GHC infers that writeAll can write only Storable instances, so i was forced to add signature to writeAll: writeAll :: (BufferData a) => RecvBuf -> SendBuf -> Cleanup -> a -> IO () the same problems raised many times when i switched from 6.6.1 to 6.8.2 - lots of procedures need to add signatures because by default 6.8.2 decided that they are restricted to Storable does GHC developers interested in minimal test case for this problem? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1