- Glasgow-haskell-users

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

Idempontent IO actions and unsafeSTMToIO
by Robert van Herk 06 Aug '05

06 Aug '05

Hi all, Is it true to say that to perform idempotent IO actions inside a STM monad by using unsafeSTMToIO is safe? I mean something like: do ... -- some STM actions unsafeSTMToIO a -- Here, a is an idempotent IO action ... -- some other STM actions What I read from the various sources on the web is that unsafeSTMToIO is just unsafe in the sence that the IO actions may be performed multiple times. So I recon that, if the IO actions are idempotent, there would be no problem. Am I correct? Regards, Robert

2 1

Re: ghc and cabal
by Lemmih 06 Aug '05

06 Aug '05

On 8/6/05, Serge D. Mechveliani <mechvel(a)botik.ru> wrote: > On Aug 05, 2005 we wrote: > > > "Serge D. Mechveliani" <mechvel(a)botik.ru> writes: > > > > > Which Cabal version will be in official ghc-6.4.1 by default? > > > > > It'll be 1.0 with some bug fixes (Simon: can you please make the > > version number '1.0.1'?) > > > > > > If it is 1.0, then ghc-6.4.1 will fail with `make' for profiling. > > > So, the user needs to install another Cabal version and to link it > > > to GHC, and this occurs difficult. This is likely to complicate the > > > usage of GHC > > > > Yep. Profiling support won't be there, but some of the problems you > > faced in building a separate Cabal will hopefully be fixed in the new > > version of GHC. > > > First, I tried to test profiling in ghc-6.4.1-pre-release, > and could not -- due to this misfeature with "_p" modules in > Cabal-1.0. > Generally, what I need: > fresh GHC with working profiling, with Cabal processing > "_p" module suffixes, and such > (in runhaskell Setup build, install). > > If official ghc-6.4.1 (with default Cabal version) has not the > needed feature, then, the next question is > > which higher Cabal version supports such `make' for profiling? > > After I know the answer to this, I could start searching for possible > _simple instructions_ for the users of GHC and its applications on > how to upgrade Cabal in their installed ghc-6.4.1. Such instructions > that are clear almost to everyone, not only to system hackers. > > If all this occurs difficult to arrange, then the profiling occurs > delayed to future official GHC versions. (If I've completely misunderstood the question please ignore me :) Guide to profiling in Cabal: Step 1: Installing a new Cabal You can either download Cabal 1.1.1 from the webpage or pull it from http://cvs.haskell.org/darcs/cabal with darcs. When you got the source tree you install it as any other Cabal package. [global installation] $ runhaskell Setup.lhs configure $ runhaskell Setup.lhs build $ sudo runhaskell Setup.lhs install [user installation, GHC <= 6.4 wont like this] $ runhaskell Setup.lhs configure --prefix=/your/desired/prefix $ runhaskell Setup.lhs build $ runhaskell Setup.lhs install --user Step 2: Compiling Cabal packages with profiling. You can now pass '-p' or '--enable-library-profiling' when you configure a package and the .cabal file will have a new stanza call GHC-prof-options for profiling options. -- Friendly, Lemmih

1 0

unsafePerformIO and optimizations
by Wolfgang Jeltsch 06 Aug '05

06 Aug '05

Hello, http://haskell.org/ghc/docs/latest/html/libraries/base/ System.IO.Unsafe.html#v%3AunsafePerformIO talks about what optimizations you should disable if you apply unsafePerformIO to an action which contains side effects. These are: * inlining of functions which call unsafePerformIO * common subexpression elimination (on the module which contains the unsafePerformIO application, if I understand correctly) * let-floating Alas, the documentation is very terse, in my opinion, and I don't understand these things fully. First, what is the problem with inlining a function call? Say, I have a function f defined as follows: f :: Char -> () f c = unsafePerformIO (putChar c) If inlining is allowed, the expression f '*' becomes unsafePerformIO (putChar '*'). Is this a problem? Or is inlining dangerous in other situations? On the other hand, I can see that inlining non-functions could cause harm. Say I have something like this: u :: () u = unsafePerformIO (putChar '*') Now, inlining u would transform (u,u) to (unsafePerformIO (putChar '*),unsafePerformIO (putChar '*')) which could result in putChar '*' being executed multiple times. So why does the library documentation only talk about disabling inlining of functions? I understand that common subexpression elimination could cause harm. It could transform the expression (unsafePerformIO (putChar '*),unsafePerformIO (putChar '*')) to let u = unsafePerformIO (putChar '*') in (u,u), couldn't it? This would result in the I/O action be performed at most once which is not what was intended. But couldn't the same thing also happen if I use the expression (f '*',f '*'), probably in a different module? Does this mean that I have to use -fno-cse not only in the module which contains the unsafePerformIO application but also in every other module which uses unsafePerformIO indirectly via f or functions using f? Does let-floating only have to be disabled in the module which uses unsafePerformIO? Say, I have f defined as above and have the following definition in a module different from the one f is defined in: g :: Int -> () g n = f '*' Couldn't it be that the asterisk is output only once instead of every time, g is called? I would be thankful for any help. Best regards, Wolfgang

1 0

Inductive kinds
by Geoffrey Alan Washburn 06 Aug '05

06 Aug '05

Are there any plans for inductively defined kinds in some future version of GHC?

1 0

ghc and cabal
by Serge D. Mechveliani 06 Aug '05

06 Aug '05

Dear GHC developers, dear Cabal developers, To my report >> I have `made' ghc-6.4.1.20050801 >> >> Without profiling, it `makes' and installs. >> For profiling, dm.cabal adds >> -prof -auto-all -hisuf p_hi -osuf p_o >> to its options. >> The commands >> runhaskell Setup configure --ghc --prefix=$dmSource/inst >> runhaskell Setup build >> >> seem to work all right. Then, runhaskell Setup install --user >> reports >> Installing: /home/mechvel/dm/1.03/dm/source/inst/lib/dumatel-1.3 & >> /home/mechvel/dm/1.03/dm/source/inst/bin dumatel-1.3... >> Error: Could not find module: Dumatel with any suffix: ["hi"] >> >> And the directory $dmSource/dist/build/ contains >> Dumatel.p_hi, Dumatel.p_o >> among its files. >> [..] Simon Marlow writes that I need to install the later version of Cabal independently on GHC. I do have some difficulties with this, because Cabal-1.1.1 `README' suggests just to run `make install' as a root, I do not see any configureing possibility for the installation, and so on. But, in principle, what is the relation between Cabal and GHC installation? In ghc-6.4.1.20050801, `ghci -package Cabal' says "Cabal-1.0". I have read some of Cabal manual, about how to use runhaskell. But as I recall, I never installed Cabal. GHC has installed it itself. (?) Which Cabal version will be in official ghc-6.4.1 by default? If it is 1.0, then ghc-6.4.1 will fail with `make' for profiling. So, the user needs to install another Cabal version and to link it to GHC, and this occurs difficult. This is likely to complicate the usage of GHC (?) Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 2