- Glasgow-haskell-users

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

upgrading Cabal in ghc-6.4.1-pre
by Serge D. Mechveliani 08 Aug '05

08 Aug '05

Dear Cabal developers, I have the following problem with upgrading Cabal in ghc-6.4.1.20050806-i386-unknown-linux. First, I have installed this ghc-6.4.1-pre binary to my home directory. > which ghc /home/mechvel/ghc/6.4.1-aug-1/binary/inst/bin/ghc 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/ and edit in GNUmakefile the two lines to PREF=/home/mechvel/ghc/cabal/1.1.1/inst HCBASE=/home/mechvel/ghc/6.4.1-aug-1/binary/inst/bin/ in order to install new Cabal to /home/mechvel/ghc/cabal/1.1.1/inst . Then I command make setup ./setup configure --prefix=/home/mechvel/ghc/cabal/1.1.1/inst ./setup build ./setup install --user Then, 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 ... linking ... done. -------------------------------------------------------- Then I go to my application Dumatel and try to make it with GHC: ~/dm/1.03/dm/source> runhaskell Setup configure --ghc --prefix=$dmSource/inst ------------------------------------------------------ Configuring dumatel-1.3... configure: Using install prefix: /home/mechvel/dm/1.03/dm/source/inst configure: Using compiler: /home/mechvel/ghc/6.4.1-aug-1/binary/inst/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.4.1.20050806 configure: Using package tool: /home/mechvel/ghc/6.4.1-aug-1/binary/inst/bin/ghc-pkg configure: No haddock found configure: Using happy: /usr/bin/happy configure: Using alex: /usr/bin/alex configure: Using hsc2hs: /home/mechvel/ghc/6.4.1-aug-1/binary/inst/bin/hsc2hs configure: No c2hs found configure: No cpphs found configure: No greencard found configure: Dependency data-any: using data-1.0 -------------------------------------------------------------------- This looks all right. runhaskell Setup build --------------------------------------------------- Preprocessing library dumatel-1.3... Building dumatel-1.3... Chasing modules from: Dumatel,Dumatel.Prelude,Dumatel.Prelude5,Dumatel.TermComp,Dumatel.Reduce,Dumatel.CritPair,Dumatel.KBC,Dumatel.Bool,Dumatel.BTerm,Dumatel.ReduceBT,Dumatel.UKBB,Dumatel.Prover,Dumatel.DemoTest.Test,Dumatel.DemoTest.T_kbcTrad,Dumatel.DemoTest.T_ukb,Dumatel.DemoTest.T_logicSimp,Dumatel.DemoTest.T_nat,Dumatel.DemoTest.T_list,Prelude0,Prelude0_0,Prelude1,Prelude2,Prelude2_0,Prelude3,Prelude3_0,Prelude3_1,Prelude4,Bool0,BTerm0,BTerm1,Prover0,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) --------------------------------------------------- And this differs from what it was with Cabal-1.0. I does not want to compile things. How to fix this, please? The file dm.cabal is ------------------------------------------------------ name: dumatel version: 1.3 build-depends: data exposed-modules: "Dumatel" "Dumatel.Prelude" "Dumatel.Prelude5" "Dumatel.TermComp" "Dumatel.Reduce" "Dumatel.CritPair" "Dumatel.KBC" "Dumatel.Bool" "Dumatel.BTerm" "Dumatel.ReduceBT" "Dumatel.UKBB" "Dumatel.Prover" "Dumatel.DemoTest.Test" "Dumatel.DemoTest.T_kbcTrad" "Dumatel.DemoTest.T_ukb" "Dumatel.DemoTest.T_logicSimp" "Dumatel.DemoTest.T_nat" "Dumatel.DemoTest.T_list" . other-modules: Prelude0 Prelude0_0 Prelude1 Prelude2 Prelude2_0 Prelude3 Prelude3_0 Prelude3_1 Prelude4 Bool0 BTerm0 BTerm1 Prover0 Parse1 Parse2 Parse3 Prover1 Prover2 Prover3 "Dumatel.DemoTest.Test0" . ghc-options: -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances -fno-warn-overlapping-patterns -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports --------------------------------------------------------------- When upgrading Cabal, `make setup' has produced many messages like -------------- Distribution/Compat/Directory.hs:2:24: Warning: `copyFile' is exported by `copyFile' and `module System.Directory' Distribution/Compat/FilePath.hs:298:15: Warning: This binding for `pre' shadows an existing binding In a case alternative -------------- ./setup configure ... produced ---------------------- Configuring Cabal-1.1.1... configure: Using install prefix: /home/mechvel/ghc/cabal/1.1.1/inst configure: Using compiler: /home/mechvel/ghc/6.4.1-aug-1/binary/inst/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.4.1.20050806 configure: Using package tool: /home/mechvel/ghc/6.4.1-aug-1/binary/inst/bin/ghc-pkg configure: No haddock found configure: Using happy: /usr/bin/happy configure: Using alex: /usr/bin/alex configure: Using hsc2hs: /home/mechvel/ghc/6.4.1-aug-1/binary/inst/bin/hsc2hs configure: No c2hs found configure: No cpphs found configure: No greencard found configure: Dependency base-any: using base-1.0 configure: Dependency util-any: using util-1.0 ----------------------------------------- ./setup build produced ------------------------------ ... ... Compiling Distribution.Compat.Directory ( ./Distribution/Compat/Directory.hs, dist/build/Distribution/Compat/Directory.o ) Distribution/Compat/Directory.hs:2:8: Warning: `findExecutable' is exported by `findExecutable' and `module System.Directory' ... ... Linking ... Preprocessing library Cabal-1.1.1... Preprocessing executables for Cabal-1.1.1... Building Cabal-1.1.1... hsSourceDirs: ["."] ------------------------------------ ./setup install --user produced ---------------------------------------------- building GHCi library /home/mechvel/ghc/cabal/1.1.1/inst/lib/Cabal-1.1.1/ ghc-6.4.1.20050806/HSCabal-1.1.1.o... done. Creating user package database in /home/mechvel/.ghc/i386-linux-6.4.1.20050806/package.conf Reading package info from ".installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. Installing: /home/mechvel/ghc/cabal/1.1.1/inst/lib/Cabal-1.1.1/ghc-6.4.1.20050806 & /home/mechvel/ghc/cabal/1.1.1/inst/bin Cabal-1.1.1... Registering Cabal-1.1.1... ------------------------------------------- Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

mixing x86_64 and i386
by John Meacham 08 Aug '05

08 Aug '05

Just thought I'd share a little hack... linux has a command 'setarch' which changes the current architecture so you can do things like build i386 rpms on a x86_64 system... by installing both a i386 and x86_64 ghc (both from the fedora repo work great) and replacing the ghc driver with something like the below makes ghc "just work" too. (replace paths as appropriate) I wonder if we should make the driver script a bit smarter in general to allow multiple versions of ghc normally so you can just pass a version and arch command line argument to ghc and the driver will intpret it and call the appropriate back end. #!/bin/sh case `uname -m` in x86_64) GHCBIN="/usr/lib64/ghc-6.4.1.20050626/ghc-6.4.1.20050626" TOPDIROPT="-B/usr/lib64/ghc-6.4.1.20050626" EXTRA_OPTS="" ;; i*86) GHCBIN="/usr/lib/ghc-6.4/ghc-6.4" TOPDIROPT="-B/usr/lib/ghc-6.4" EXTRA_OPTS=" -optc-m32 -optl-m32 -opta-m32 " ;; *) echo "Unknown architecture" ; exit 2;; esac echo $GHCBIN $TOPDIROPT $EXTRA_OPTS ${1+"$@"} exec $GHCBIN $TOPDIROPT $EXTRA_OPTS ${1+"$@"} -- John Meacham - ⑆repetae.net⑆john⑈

3 2