August 2005 - Glasgow-haskell-users

RE: 6.4.1 release candidate testing on OS X
by Simon Marlow 09 Aug '05

09 Aug '05

On 09 August 2005 14:15, Gregory Wright wrote: > ghc-6.4.1.20050806 builds successfully on OS X 10.4.2 using Apple's > gcc-4.0. > > > Bug 1249527 is still fixed, and I was able to build darcs with the > compiler. Nice to hear, thanks Greg! Cheers, Simon

1 0

RE: 6.4.1 release candidate testing on OS X
by Simon Marlow 09 Aug '05

09 Aug '05

On 05 August 2005 23:05, Gregory Wright wrote: > ghc-6.4.1.20050804 builds successfully on Mac OS X 10.4.2 using gcc > 3.3. > > This snapshot also appears to fix bug 1249527, "runhaskell causes GHC > to segfault on OS X". > > The new compiler was also tested by building darcs-1.0.3. > > The build was done under the darwinports infrastructure using ghc-6.4 > as the bootstrap > compiler. > > I haven't yet tried to build using gcc 4.0; should I expect that to > work yet? It might - we've been testing with gcc 4.0, but I believe the MacOS X version has some differences. Cheers, Simon

2 1

RE: Question about ghc case analysis
by Simon Marlow 09 Aug '05

09 Aug '05

On 09 August 2005 12:25, Adrian Hey wrote: > Well this is actually a couple of questions.. > > First question is how does ghc do case analysis on algebraic > data type constructors. I always assumed it was by using some > kind of jump table on a tag field, but I don't know really (I'm > not even sure ghc makes use of tag fields as such). If the number of constructors is less than or equal to 8 (currently), GHC uses vectored returns. The case exrpession pushes a return address on the stack that is a pointer to a vector, and the code for the constructor jumps to the appropriate entry. For >8 constructors, GHC uses a direct return address and then a comparison on the tag value extracted from the constructor's info table. > Second question is really the same question but for literals. > What search algorithm is employed and is it likely to be > worth hand coding something else? (a binary search maybe). > > I'm thinking of code like this.. > case n of > 0 -> > 7 -> > 34622 -> > .. lots more > _ -> GHC's code generator turns these into binary trees or table jumps, or a combination of the two, depending on the population. But if you're compiling via C, then we just generate a switch and leave it up to the C compiler to choose. Cheers, Simon

1 0

Question about ghc case analysis
by Adrian Hey 09 Aug '05

09 Aug '05

Hello, Well this is actually a couple of questions.. First question is how does ghc do case analysis on algebraic data type constructors. I always assumed it was by using some kind of jump table on a tag field, but I don't know really (I'm not even sure ghc makes use of tag fields as such). Second question is really the same question but for literals. What search algorithm is employed and is it likely to be worth hand coding something else? (a binary search maybe). I'm thinking of code like this.. case n of 0 -> 7 -> 34622 -> .. lots more _ -> Thanks -- Adrian Hey

1 0

RE: Inferred type is less polymorphic than expected?
by Simon Peyton-Jones 09 Aug '05

09 Aug '05

| > Are you saying, that the second error causes the first one? Thus, | > everything is caused by 'printer' being recursively defined? | Yes, that's what I believe. I'm not sure why it shows the first error | message at all; in my experience, strange things happen when ghc | continues after an error message that you shouldn't pay too much | attention to. Perhaps ghc-6.4 just assumes identical contexts in | recursive groups without checking the type signatures. After an error in a function definition for f, GHC carries on assuming the function has type f :: forall a. a That very seldom leads to subsequent errors, but maybe it did this time. The way to find out is to show the program that elicits this message but not the other. Simon

2 1

RE: C--
by Simon Peyton-Jones 09 Aug '05

09 Aug '05

We're already compiling via an intermediate data type that is closely based on C--. That internal data type is used regardless of whether you emit C, asm, or C--. Actually using C-- itself as an output medium keeps slipping down the agenda, mainly because no one asks for it! But I still fully intend to do it. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Simon Marlow | Sent: 01 August 2005 13:13 | To: Bulat Ziganshin; glasgow-haskell-users(a)haskell.org | Subject: RE: C-- | | On 31 July 2005 08:10, Bulat Ziganshin wrote: | | > can you please say about value of using C-- in GHC? will this | > reduce compile time, increase speed of compiled programs, improve | > portability or make some other effect? would the C-- compile path | > replace asm or C path? | | It should reduce compile time compared to compiling via C, though I | suspect it will still be slower than using GHC's built-in native code | generator. | | It should improve the speed of compiled programs, because C-- will be | using its own, efficient, calling convention. For example, this will | mean that some arguments can be passed in registers on x86, which we | can't do currently because of a combination of the lack of registers and | limitations in what we can convince gcc to do. | | It should improve portability, because there is less work in GHC | required to compile via C-- on a new platform: no mangler to modify, for | example. | | Eventually, we hope the registerised via-C path would become redundant. | The unregisterised path is still useful for bootstrapping, given that | more platforms have a C compiler than a C-- compiler (if C-- were to | become ubiquitous, the unregisterised path would become irrelevant too). | | Cheers, | Simon | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

RE: how to return ghc to Cabal-1.0
by Simon Marlow 09 Aug '05

09 Aug '05

On 08 August 2005 13:42, Serge D. Mechveliani wrote: > Please, how to return GHC to Cabal-1.0 ? > > I have installed ghc-6.4.1.20050806-i386-unknown-linux > in my home. > Then I tried to upgrade Cabal in GHC to 1.1.1. > For this, I istalled Cabal-1.1.1 to my home. > > Then, there appeared a certain difficulty in building application. > > But now I decide to stop these experiments > (have not time now to struggle with complications) and to return to > regular > ghc-6.4.1 (with Cabal-1.0). > > And cannot! > > Then, I remove the installation directory and install > ghc-6.4.1-pre binary by new, starting from `configure'. > > Then ghci -package Cabal > > crashes, reporting something of Cabal-1.1.1. You should really cut and paste the *exact* command and error message, we can't tell much from this. Don't worry about spamming us with too much detail. To return to Cabal-1.0, you should simply unregister Cabal-1.1.1, assuming you haven't also unregistered Cabal-1.0. 'ghc-pkg list' will tell you which packages are registered, and whether they are registered globally or locally to you. 'ghc-pkg unregister Cabal-1.1.1' will unregister Cabal-1.1.1, for example. If it is registered for you only, then you will need to add the --user flag. Additionally, you probably want to delete the files that belong to Cabal-1.1.1. 'ghc-pkg describe Cabal-1.1.1' will tell you where the files live (before you unregister it, of course). Cheers, Simon

2 1

RE: Inductive kinds
by Simon Peyton-Jones 08 Aug '05

08 Aug '05

You mean something like 'datakind' in Tim Sheard's Omega? Nothing is imminent. What I'd like to do, though, is to use data *types* at the type level, rather than reproduce the data-type declaration stuff at the kind level. Thus data Nat = S Nat | Z data Foo :: Nat -> * where Nil :: Foo Z Cons :: Int -> Foo n -> Foo (S n) My dependent-type friends tell me that the paradoxes of "* has kind *" can be dealt with, but I don't understand the details yet. But as I say, nothing is very imminent. why do you ask? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Geoffrey Alan Washburn | Sent: 06 August 2005 15:18 | To: glasgow-haskell-users(a)haskell.org | Subject: Inductive kinds | | | Are there any plans for inductively defined kinds in some future | version of GHC? | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

how to return ghc to Cabal-1.0
by Serge D. Mechveliani 08 Aug '05

08 Aug '05

People, Please, how to return GHC to Cabal-1.0 ? I have installed ghc-6.4.1.20050806-i386-unknown-linux in my home. Then I tried to upgrade Cabal in GHC to 1.1.1. For this, I istalled Cabal-1.1.1 to my home. Then, there appeared a certain difficulty in building application. But now I decide to stop these experiments (have not time now to struggle with complications) and to return to regular ghc-6.4.1 (with Cabal-1.0). And cannot! Then, I remove the installation directory and install ghc-6.4.1-pre binary by new, starting from `configure'. Then ghci -package Cabal crashes, reporting something of Cabal-1.1.1. Then, I install Cabal-1.0, as tried earlier with 1.1.1 (change paths to point to home, make setup ./setup configure --prefix=/home... ./setup build ./setup install --user ). Then re-installed GHC. And again, ghci -package Cabal reports ------------------------------------------- GHC Interactive, version 6.4.1.20050806, for Haskell 98. ... Loading package base-1.0 ... linking ... done. Loading package mtl-1.0 ... linking ... done. Loading package lang-1.0 ... linking ... done. Loading package QuickCheck-1.0 ... linking ... done. Loading package readline-1.0 ... linking ... done. Loading package unix-1.0 ... linking ... done. Loading package posix-1.0 ... linking ... done. Loading package util-1.0 ... linking ... done. Loading package Cabal-1.1.1 ... ghc-6.4.1.20050806: can't load .so/.DLL for: HSCabal-1.1.1 (libHSCabal-1.1.1.so: cannot open shared object file: No such file or directory) ------------------------------------------ This looks like a tragedy. Please, how to return to 1.0 ? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: upgrading Cabal in ghc-6.4.1-pre
by Konovalov, Vadim 08 Aug '05

08 Aug '05

[skipped] > Then, ghci -package Cabal > reports of Cabal-1.0. > > I need to upgrade Cabal to 1.1.1. > To do this, I unfold new Cabal to > /home/mechvel/ghc/cabal/1.1.1/cabal/ > Then I do > cd /home/mechvel/ghc/cabal/1.1.1/cabal/ [skipped] > --------------------------------------------------- > Preprocessing library dumatel-1.3... > Building dumatel-1.3... > Chasing modules from: > Dumatel,Dumatel.Prelude,Dumatel.Prelude5,Dumatel.TermComp,Duma > tel.Reduce,Dumatel.CritPair,Dumatel.KBC,Dumatel.Bool,Dumatel.B > Term,Dumatel.ReduceBT,Dumatel.UKBB,Dumatel.Prover,Dumatel.Demo > Test.Test,Dumatel.DemoTest.T_kbcTrad,Dumatel.DemoTest.T_ukb,Du > matel.DemoTest.T_logicSimp,Dumatel.DemoTest.T_nat,Dumatel.Demo > Test.T_list,Prelude0,Prelude0_0,Prelude1,Prelude2,Prelude2_0,P > relude3,Prelude3_0,Prelude3_1,Prelude4,Bool0,BTerm0,BTerm1,Pro ver0,Parse1,Parse2,Parse3,Prover1,Prover2,Prover3,Dumatel.DemoTest.Test0 > Could not find module `Prelude': > it is a member of package base-1.0, which is hidden > (imported from Dumatel.hs) > --------------------------------------------------- I faced similar problem when building a module with ghc-6.5-pre, asked similar question on this list and received following advice: <quote> Cabal hides all packages when using GHC 6.5. Add 'base' to build-depends in trhsx's cabal file and send a patch to the author. </quote> Vadim

1 0