June 2004 - Glasgow-haskell-users

Syntax for output-only arrows?
by Lauri Alanko 15 Jun '04

15 Jun '04

When I use arrows, I find that many of my primitives are of type (a () b) (for some arrow type a): they produce a value but don't take any input. E.g. deterministic parsers are like this. The syntactic sugar for arrows is lovely, but I find it a bit tedious writing "foo -< ()" all the time. The syntax allows the output of arrows to be ignored, why not input too? Would it cause unreasonable parsing problems simply to allow a simple expression of an arrow type to be a legal command inside a proc expression, with an implicit -< () input? Or are there other reasons against it? I for one find it extremely convenient that I can write "purely imperative" code with a simple syntax like do { foo; bar; baz }. I'd like similar simplicity when dealing with arrows, too. Lauri Alanko la(a)iki.fi

3 2

RE: Unregistered build (was Re: AMD64)
by Simon Marlow 15 Jun '04

15 Jun '04

On 02 June 2004 18:40, Bennett Todd wrote: > I too would be happy with an unregistered build. > > I've tried off and on to port ghc to my linux distro (uses static > linking against uClibc, glibc isn't present at all). Every time I go > through the process, I get stuck at the point where I seem to have a > working unregistered build. I can't quite find the missing link to > proceed on to a registered build, and "make install" on the > unregistered build doesn't do anything. > > Is there some special trick to get the unregistered build to make > install? You probably don't want to install the registerised build; just use it to build a fresh tree: $ ./configure --with-ghc=/unregisterised-build/ghc/compiler/ghc-inplace $ make If your platform supports registerised compilation, then this *should* just work. Cheers, Simon

2 2

RE: DLLs and shared libraries
by Simon Marlow 15 Jun '04

15 Jun '04

On 14 June 2004 03:03, Andrei de A. Formiga wrote: > I need to generate DLLs (in Windows) and shared > libraries (in unix environments) that expose some > Haskell functions (directly or through a C stub). My > first option is having ghc generate the libs directly > with the foreign export functions. But, searching > through the documentation, FAQ, web and some part of > the list archives, I didn't find any mention about how > to do this. The manual mentions the capability to > create DLLs in windows but as not working and > unsupported. If this is possible to do in all or most > platforms supported by ghc, I would be glad to know > how. You can create a DLL of Haskell code on Windows, but only of a complete self-contained library (ie. you can't split your Haskell library into several DLLs and link them together at runtime). On Unix, shared libraries are more difficult. It might be possible to make a single .so of a Haskell library, but I'm not sure. Alternatively you can use Don Stewart's hs-plugin package (announced here recently). Cheers, Simon

2 1

RE: IO question (hGetLine)
by Simon Marlow 15 Jun '04

15 Jun '04

On 14 June 2004 16:58, Gerd M wrote: > Duncan Coutts wrote: >> The GHC run time system is designed to block without using CPU when >> all threads are blocked doing IO. Could you give more details? It >> would be useful to see the code or preferably a small test case that >> demonstrates your problem. What version of ghc are you using? Which >> OS are you running that on? > I'm using ghc-6.2.1 to compile in 32bit mode while i'm running the > program in 64bit (Linux Kernel 2.6.5, amd64) with the 32bit emulation > libraries. I don't think that is the problem spot because all other > 32bit application are working fine. > > mainLoop dev = do inp <- hGetLine dev > (runIndexCmd . parseInput) inp > return () > > This is called from main with: > devHandle <- openFile device ReadMode > ................... > catchJust asyncExceptions > (forever (mainLoop devHandle)) > (cleanup devHandle) > > forever = a >> forever a > > The module that manages the device puts a process to sleep with > interruptible_sleep_on( queue ) if there's no data available and > wakes it up as soon as input arrives. As i said before this works > when i use "cat". GHC uses non-blocking I/O operations and select() to manage multi-threaded I/O, which would explain why you are seeing different behaviour compared to cat(1). If this is a home-grown device, I respectfully suggest :-) that you check the behaviour of the device when used with non-blocking I/O and select(). Try strace to see what system calls are in the loop. If it is select(), then perhaps the device is wrongly flagging select() when there is no data available? Cheers, Simon

1 0

RE: Unregistered build (was Re: AMD64)
by Simon Marlow 15 Jun '04

15 Jun '04

On 14 June 2004 21:57, Gerd M wrote: > Well I just tried it and that's what happened: > ------------------------------------------------------------------------ > ==fptools== make boot - --no-print-directory -r; > in ghc-6.2.1/ghc/utils/ghc-pkg > ------------------------------------------------------------------------ > ghc-test/usr/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O > -cpp -DPKG_TOOL -DWANT_PRETTY -DGHC_PKG_VERSION=6.2.1 Main.hs > Package.hs ParsePkgConfLite.hs > Main.hs:87: warning: backslash and newline separated by space > Main.hs:259: warning: backslash and newline separated by space > Main.hs:260: warning: backslash and newline separated by space > make all > ghc-test/usr/bin/ghc -H16m -O -cpp -DPKG_TOOL -DWANT_PRETTY > -DGHC_PKG_VERSION=6.2.1 -c Main.hs -o Main.o -ohi Main.hi > Main.hs:87: warning: backslash and newline separated by space > Main.hs:259: warning: backslash and newline separated by space > Main.hs:260: warning: backslash and newline separated by space > Main.hs:87: lexical error in string/character literal > make[4]: *** [Main.o] Error 1 > make[3]: *** [boot] Error 2 > make[2]: *** [boot] Error 1 > make[1]: *** [boot] Error 1 > make[1]: Leaving directory `ghc-6.2.1/ghc' This is caused by changes to CPP in recent versions of gcc. Unfortunately it means we can't use string gaps in CPP'd source any more. Until we move to cpphs, I'll have to remove all string gaps from our sources. Sigh. Cheers, Simon

1 0

dynamically loading the dynamic loader
by dons＠cse.unsw.edu.au 14 Jun '04

14 Jun '04

At the moment I am unable to load the hs-plugins package into GHCi (or via the hs-plugins load() either). It seems the linker is always unable to find the symbols we bind to in Linker.c, i.e. addDLL, loadObj, and friends. How can I get the linker to see the HSrts/libHSrts symbols exported by Linker.c, or is something more nefarious at work? Here is a transcript: paprika$ ghci -package plugins ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.3, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Loading package altdata ... linking ... done. Loading package unix ... linking ... done. Loading package mtl ... linking ... done. Loading package lang ... linking ... done. Loading package posix ... linking ... done. Loading package haskell98 ... linking ... done. Loading package haskell-src ... linking ... done. Loading package plugins ... linking ... /home/dons/lib/hs-plugins/HSplugins.o: unknown symbol `addDLL' ghc-6.3: panic! (the `impossible' happened, GHC version 6.3): can't load package `plugins' Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, or http://sourceforge.net/projects/ghc/. On MacOS it can't find loadObj. Now, obviously the rts is actually loaded and running, but we can't see addDLL. I've tried making the package depend on the rts, which doesn't do much. I've also added the Linker.c symbols into the linker symbol table explicitly using SymX() and Sym(), with no success. Linking against hs-plugins statically works fine, of course. Any ideas? -- Don

1 0

RE: Data.Dynamic and dynamically loaded code
by Simon Marlow 14 Jun '04

14 Jun '04

On 10 June 2004 05:32, Donald Bruce Stewart wrote: > The problem appears to be in the hash keys of the type representation > used to compare to types for equality. A dynamic value in the > (statically compiled) application never has the same key as its > equivalent type in the dynamically loaded code. The type in the > dynamically-loaded plugin code is never recognised as having the same > type as in the application (static) code. > > The following comment from Data.Typeable seems to be relevant: > > -- In GHC we use the RTS's genSym function to get a new unique, > -- because in GHCi we might have two copies of the Data.Typeable > -- library running (one in the compiler and one in the running > -- program), and we need to make sure they don't share any keys. > -- > -- This is really a hack. A better solution would be to > centralise the > -- whole mutable state used by this module, i.e. both hashtables. > But > -- the current solution solves the immediate problem, which is > that > -- dynamics generated in one world with one type were erroneously > -- being recognised by the other world as having a different type. This is exactly the problem. To fix it, you need to implement the suggestion from the comment: i.e. somehow make it so that there is only one copy of the hash table rather than two. You could do this by keeping the hash table in a variable in the RTS, perhaps. I don't know why you get differing String representation of types, though. It doesn't have anything to do with Core types, I'm pretty sure. Cheers, Simon

2 1

Re: Unregistered build (was Re: AMD64)
by Gerd M 14 Jun '04

14 Jun '04

This was causing the error: version = tail "\ \ GHC_PKG_VERSION" However, when i moved it all in one line it worked and i got as far as this but i think that's the end of the line for now: ------------------------------------------------------------------------ ==fptools== make boot -wr; in ghc-6.2.1/ghc/compiler ------------------------------------------------------------------------ ../../glafp-utils/mkdirhier/mkdirhier stage1 mkdir stage1 for i in utils basicTypes types hsSyn prelude rename typecheck deSugar coreSyn specialise simplCore stranal stgSyn simplStg codeGen absCSyn main profiling parser cprAnalysis compMan ndpFlatten cbits ghci; do \ ../../glafp-utils/mkdirhier/mkdirhier stage1/$i; \ done mkdir stage1/utils mkdir stage1/basicTypes mkdir stage1/types mkdir stage1/hsSyn mkdir stage1/prelude mkdir stage1/rename mkdir stage1/typecheck mkdir stage1/deSugar mkdir stage1/coreSyn mkdir stage1/specialise mkdir stage1/simplCore mkdir stage1/stranal mkdir stage1/stgSyn mkdir stage1/simplStg mkdir stage1/codeGen mkdir stage1/absCSyn mkdir stage1/main mkdir stage1/profiling mkdir stage1/parser mkdir stage1/cprAnalysis mkdir stage1/compMan mkdir stage1/ndpFlatten mkdir stage1/cbits mkdir stage1/ghci for i in */*hi-boot*; do \ ln -s -f ../../$i stage1/$i || true ; \ done ln: creating symbolic link `stage1/nativeGen/MachMisc.hi-boot' to `../../nativeGen/MachMisc.hi-boot': No such file or directory ln: creating symbolic link `stage1/nativeGen/MachMisc.hi-boot-5' to `../../nativeGen/MachMisc.hi-boot-5': No such file or directory ln: creating symbolic link `stage1/nativeGen/MachMisc.hi-boot-6' to `../../nativeGen/MachMisc.hi-boot-6': No such file or directory ln: creating symbolic link `stage1/nativeGen/Stix.hi-boot' to `../../nativeGen/Stix.hi-boot': No such file or directory ln: creating symbolic link `stage1/nativeGen/StixPrim.hi-boot' to `../../nativeGen/StixPrim.hi-boot': No such file or directory ln: creating symbolic link `stage1/nativeGen/StixPrim.hi-boot-5' to `../../nativeGen/StixPrim.hi-boot-5': No such file or directory ln: creating symbolic link `stage1/nativeGen/StixPrim.hi-boot-6' to `../../nativeGen/StixPrim.hi-boot-6': No such file or directory Creating main/Config.hs ... done. gcc -E -undef -traditional -I../includes -x c prelude/primops.txt.pp | /bin/sed -e '/^#/d' > prelude/primops.txt ../utils/genprimopcode/genprimopcode --data-decl < prelude/primops.txt > primop-data-decl.hs-incl ../utils/genprimopcode/genprimopcode --primop-tag < prelude/primops.txt > primop-tag.hs-incl ../utils/genprimopcode/genprimopcode --primop-list < prelude/primops.txt > primop-list.hs-incl ../utils/genprimopcode/genprimopcode --has-side-effects < prelude/primops.txt > primop-has-side-effects.hs-incl ../utils/genprimopcode/genprimopcode --out-of-line < prelude/primops.txt > primop-out-of-line.hs-incl ../utils/genprimopcode/genprimopcode --commutable < prelude/primops.txt > primop-commutable.hs-incl ../utils/genprimopcode/genprimopcode --needs-wrapper < prelude/primops.txt > primop-needs-wrapper.hs-incl ../utils/genprimopcode/genprimopcode --can-fail < prelude/primops.txt > primop-can-fail.hs-incl ../utils/genprimopcode/genprimopcode --strictness < prelude/primops.txt > primop-strictness.hs-incl ../utils/genprimopcode/genprimopcode --primop-primop-info < prelude/primops.txt > primop-primop-info.hs-incl touch .depend-BASE ghc-test/usr/bin/ghc -M -optdep-f -optdep.depend-BASE -osuf o -I../includes -H16m -O -iutils -ibasicTypes -itypes -ihsSyn -iprelude -irename -itypecheck -ideSugar -icoreSyn -ispecialise -isimplCore -istranal -istgSyn -isimplStg -icodeGen -iabsCSyn -imain -iprofiling -iparser -icprAnalysis -icompMan -indpFlatten -icbits -ighci -DOMIT_NATIVE_CODEGEN -DGHCI -package haskell-src -package unix -package readline -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -recomp -Rghc-timing -H16M '-#include "hschooks.h"' absCSyn/AbsCSyn.lhs absCSyn/AbsCUtils.lhs absCSyn/CLabel.lhs absCSyn/CStrings.lhs absCSyn/Costs.lhs absCSyn/MachOp.hs absCSyn/PprAbsC.lhs basicTypes/BasicTypes.lhs basicTypes/DataCon.lhs basicTypes/Demand.lhs basicTypes/FieldLabel.lhs basicTypes/Id.lhs basicTypes/IdInfo.lhs basicTypes/Literal.lhs basicTypes/MkId.lhs basicTypes/Module.lhs basicTypes/Name.lhs basicTypes/NameEnv.lhs basicTypes/NameSet.lhs basicTypes/NewDemand.lhs basicTypes/OccName.lhs basicTypes/RdrName.lhs basicTypes/SrcLoc.lhs basicTypes/UniqSupply.lhs basicTypes/Unique.lhs basicTypes/Var.lhs basicTypes/VarEnv.lhs basicTypes/VarSet.lhs codeGen/Bitmap.hs codeGen/CgBindery.lhs codeGen/CgCase.lhs codeGen/CgClosure.lhs codeGen/CgCon.lhs codeGen/CgConTbls.lhs codeGen/CgExpr.lhs codeGen/CgHeapery.lhs codeGen/CgLetNoEscape.lhs codeGen/CgMonad.lhs codeGen/CgRetConv.lhs codeGen/CgStackery.lhs codeGen/CgTailCall.lhs codeGen/CgUpdate.lhs codeGen/CgUsages.lhs codeGen/ClosureInfo.lhs codeGen/CodeGen.lhs codeGen/SMRep.lhs compMan/CompManager.lhs coreSyn/CoreFVs.lhs coreSyn/CoreLint.lhs coreSyn/CorePrep.lhs coreSyn/CoreSyn.lhs coreSyn/CoreTidy.lhs coreSyn/CoreUnfold.lhs coreSyn/CoreUtils.lhs coreSyn/ExternalCore.lhs coreSyn/MkExternalCore.lhs coreSyn/PprCore.lhs coreSyn/PprExternalCore.lhs coreSyn/Subst.lhs cprAnalysis/CprAnalyse.lhs deSugar/Check.lhs deSugar/Desugar.lhs deSugar/DsArrows.lhs deSugar/DsBinds.lhs deSugar/DsCCall.lhs deSugar/DsExpr.lhs deSugar/DsForeign.lhs deSugar/DsGRHSs.lhs deSugar/DsListComp.lhs deSugar/DsMeta.hs deSugar/DsMonad.lhs deSugar/DsUtils.lhs deSugar/Match.lhs deSugar/MatchCon.lhs deSugar/MatchLit.lhs ghci/ByteCodeAsm.lhs ghci/ByteCodeFFI.lhs ghci/ByteCodeGen.lhs ghci/ByteCodeInstr.lhs ghci/ByteCodeItbls.lhs ghci/ByteCodeLink.lhs ghci/InteractiveUI.hs ghci/Linker.lhs ghci/ObjLink.lhs hsSyn/Convert.lhs hsSyn/HsBinds.lhs hsSyn/HsCore.lhs hsSyn/HsDecls.lhs hsSyn/HsExpr.lhs hsSyn/HsImpExp.lhs hsSyn/HsLit.lhs hsSyn/HsPat.lhs hsSyn/HsSyn.lhs hsSyn/HsTypes.lhs main/BinIface.hs main/CmdLineOpts.lhs main/CodeOutput.lhs main/Config.hs main/Constants.lhs main/DriverFlags.hs main/DriverMkDepend.hs main/DriverPhases.hs main/DriverPipeline.hs main/DriverState.hs main/DriverUtil.hs main/ErrUtils.lhs main/Finder.lhs main/GetImports.hs main/HscMain.lhs main/HscStats.lhs main/HscTypes.lhs main/Interpreter.hs main/Main.hs main/MkIface.lhs main/Packages.lhs main/ParsePkgConf.hs main/SysTools.lhs main/TidyPgm.lhs ndpFlatten/FlattenInfo.hs ndpFlatten/FlattenMonad.hs ndpFlatten/Flattening.hs ndpFlatten/NDPCoreUtils.hs ndpFlatten/PArrAnal.hs parser/Ctype.lhs parser/LexCore.hs parser/Lexer.hs parser/Parser.hs parser/ParserCore.hs parser/ParserCoreUtils.hs parser/RdrHsSyn.lhs prelude/ForeignCall.lhs prelude/PrelInfo.lhs prelude/PrelNames.lhs prelude/PrelRules.lhs prelude/PrimOp.lhs prelude/PrimRep.lhs prelude/TysPrim.lhs prelude/TysWiredIn.lhs profiling/CostCentre.lhs profiling/SCCfinal.lhs rename/RnBinds.lhs rename/RnEnv.lhs rename/RnExpr.lhs rename/RnHiFiles.lhs rename/RnHsSyn.lhs rename/RnIfaces.lhs rename/RnNames.lhs rename/RnSource.lhs rename/RnTypes.lhs simplCore/CSE.lhs simplCore/FloatIn.lhs simplCore/FloatOut.lhs simplCore/LiberateCase.lhs simplCore/OccurAnal.lhs simplCore/SAT.lhs simplCore/SATMonad.lhs simplCore/SetLevels.lhs simplCore/SimplCore.lhs simplCore/SimplMonad.lhs simplCore/SimplUtils.lhs simplCore/Simplify.lhs simplStg/SRT.lhs simplStg/SimplStg.lhs simplStg/StgStats.lhs specialise/Rules.lhs specialise/SpecConstr.lhs specialise/Specialise.lhs stgSyn/CoreToStg.lhs stgSyn/StgLint.lhs stgSyn/StgSyn.lhs stranal/DmdAnal.lhs stranal/SaAbsInt.lhs stranal/SaLib.lhs stranal/StrictAnal.lhs stranal/WorkWrap.lhs stranal/WwLib.lhs typecheck/Inst.lhs typecheck/TcArrows.lhs typecheck/TcBinds.lhs typecheck/TcClassDcl.lhs typecheck/TcDefaults.lhs typecheck/TcDeriv.lhs typecheck/TcEnv.lhs typecheck/TcExpr.lhs typecheck/TcForeign.lhs typecheck/TcGenDeriv.lhs typecheck/TcHsSyn.lhs typecheck/TcIfaceSig.lhs typecheck/TcInstDcls.lhs typecheck/TcMType.lhs typecheck/TcMatches.lhs typecheck/TcMonoType.lhs typecheck/TcPat.lhs typecheck/TcRnDriver.lhs typecheck/TcRnMonad.lhs typecheck/TcRnTypes.lhs typecheck/TcRules.lhs typecheck/TcSimplify.lhs typecheck/TcSplice.lhs typecheck/TcTyClsDecls.lhs typecheck/TcTyDecls.lhs typecheck/TcType.lhs typecheck/TcUnify.lhs types/Class.lhs types/FunDeps.lhs types/Generics.lhs types/InstEnv.lhs types/PprType.lhs types/TyCon.lhs types/Type.lhs types/TypeRep.lhs types/Variance.lhs utils/Bag.lhs utils/Binary.hs utils/BitSet.lhs utils/Digraph.lhs utils/FastMutInt.lhs utils/FastString.lhs utils/FastTypes.lhs utils/FiniteMap.lhs utils/ListSetOps.lhs utils/Maybes.lhs utils/OrdList.lhs utils/Outputable.lhs utils/Panic.lhs utils/Pretty.lhs utils/PrimPacked.lhs utils/StringBuffer.lhs utils/UnicodeUtil.lhs utils/UniqFM.lhs utils/UniqSet.lhs utils/Util.lhs /tmp/ghc25874.lpp:0: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugs.gentoo.org/> for instructions. <<ghc: 16006472 bytes, 5 GCs, 176280/176280 avg/max bytes residency (1 samples), 16M in use, 0.01 INIT (0.00 elapsed), 0.14 MUT (0.30 elapsed), 0.02 GC (0.05 elapsed) :ghc>> make[2]: *** [depend] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `ghc-6.2.1/ghc' make: *** [build] Error 1 _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

Re: Unregistered build (was Re: AMD64)
by Gerd M 14 Jun '04

14 Jun '04

Well I just tried it and that's what happened: ------------------------------------------------------------------------ ==fptools== make boot - --no-print-directory -r; in ghc-6.2.1/ghc/utils/ghc-pkg ------------------------------------------------------------------------ ghc-test/usr/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O -cpp -DPKG_TOOL -DWANT_PRETTY -DGHC_PKG_VERSION=6.2.1 Main.hs Package.hs ParsePkgConfLite.hs Main.hs:87: warning: backslash and newline separated by space Main.hs:259: warning: backslash and newline separated by space Main.hs:260: warning: backslash and newline separated by space make all ghc-test/usr/bin/ghc -H16m -O -cpp -DPKG_TOOL -DWANT_PRETTY -DGHC_PKG_VERSION=6.2.1 -c Main.hs -o Main.o -ohi Main.hi Main.hs:87: warning: backslash and newline separated by space Main.hs:259: warning: backslash and newline separated by space Main.hs:260: warning: backslash and newline separated by space Main.hs:87: lexical error in string/character literal make[4]: *** [Main.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `ghc-6.2.1/ghc' I also tried to build the standalone "happy" and got the same error: ==fptools== make all -wr; in happy-1.14/happy/src ------------------------------------------------------------------------ make INSTALLING=0 BIN_DIST=0 - --no-print-directory -r all ghc-test/usr/bin/ghc -H16m -O -cpp -fglasgow-exts -package lang -O -DHAPPY_VERSION=1.14 -c Version.hs -o Version.o -ohi Version.hi Version.hs:3: warning: backslash and newline separated by space Version.hs:3: lexical error in string/character literal make[3]: *** [Version.o] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all] Error 1 make[1]: Leaving directory `happy-1.14/happy' >2004-06-14T16:06:05 Simon Marlow: > > You probably don't want to install the registerised build; just use it > > to build a fresh tree: > > > > $ ./configure > > --with-ghc=/unregisterised-build/ghc/compiler/ghc-inplace > > $ make > >Thanks, I'll give it another go. It'll be a few days before I can >get back with results (each build seems to take about a day, I've >only got 128MB of RAM). I _think_ I tried that before and ended up >getting an error, that was why I was hoping to just install the >unregistered build. But I'll take another swing at it and report the >results. > >Thanks again, > >-Bennett ><< attach4 >> >_______________________________________________ >Glasgow-haskell-users mailing list >Glasgow-haskell-users(a)haskell.org >http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus

1 0

RE: Parallel
by Simon Marlow 14 Jun '04

14 Jun '04

On 03 June 2004 15:56, Goran Topic wrote: > I am a newcomer to functional programming, and I would like to learn > it very much. However, I'm also starting to deal with parallel > programming, and I thought I'd combine my two interests. > > So I grabbed the Debian ghc6 package (v6.2), and (after a lot of > searching) found out that I lack the "mp" way. Then I tried grabbing > the sources, and compiling them with WAYS=mp, but when the compiler is > compiling the "mp" way, it does so with the -parallel switch, which > requires the "mp" include files - the very ones I am trying to > compile! > > Now, several people tried telling me that GpH is a separate project, > but 1) it's very out of date > 2) ghc source has a ton of PVM references > 3) the ghc user manual mentions parallel code > ...so I kind of figured that GpH got integrated into ghc. The problem > is that I just can't get it to run! The parallel version of GHC is maintained by a separate group, the GPH project, and they do their own releases. There is old, non-working parallel code in the version of GHC we distribute (as you discovered). For the GPH project, go here: http://www.macs.hw.ac.uk/~dsg/gph/ Cheers, Simon

2 1