- Glasgow-haskell-users

--make should not touch the -o file if it doesn't change it
by Alex Jacobson 03 Jan '08

03 Jan '08

Right now, if you recompile with --make, the exeutable gets a new timestamp. That seems incorrect. Is this a bug? -Alex-

2 2

Re: [Haskell] garbage collection of Concurrent Haskell threads?
by Simon Marlow 02 Jan '08

02 Jan '08

[ moving to glasgow-haskell-users(a)haskell.org ] Conal Elliott wrote: > Thanks, Simon. If I understand the mechanism you're describing, it > discards readers of an empty MVar when there are no other references to > the MVar *because* the MVar can never get written. And if there are > other readers but no writers, then I'm guessing GC wouldn't know that, > and none of the readers get discarded. Is that so? I'm not sure I understand precisely what you mean here. Do you mean when there are other running threads that might read the MVar in the future? In that case, yes, blocked readers would not be detected and sent an exception. > I think Baker & Hewitt's trick was analogous to discarding writers of an > already full MVar when there are readers (readMVar) but no takers > (takeMVar). (Though not quite, since readMVar is implemented via > takeMVar & putMVar.) It shouldn't be the case that you have a thread doing putMVar on a full MVar simultaneously with another thread doing readMVar, because the readMVar could be preempted between the take and put and then block - this would almost certainly be an undesirable race condition. > I guess that effectively means IVars instead of MVars. > > In either direction (blocked reader or blocked writer), the interface of > MVars (or IVars) would seem to prevent an accurate analysis, since GC > wouldn't know whether a Var reference was for reading or writing. > > Right? A simple solution might be to hide the Var itself and instead > expose reader and writer halves. If there's an analysis problem at all, > does that solution make sense? Absolutely. It ought to be possible to implement this using weak pointers in GHC, because you want relationships like "if a writer is alive, then the readers are alive", and this is the kind of thing you can express with weak pointers. Cheers, Simon > > Cheers, - Conal > > On Dec 24, 2007 1:02 AM, Simon Peyton-Jones <simonpj(a)microsoft.com > <mailto:simonpj@microsoft.com>> wrote: > > GHC already garbage-collects threads that are blocked on an MVar > that is otherwise inaccessible (and hence cannot be updated). More > precisely, GHC sends the thread an asynchronous exception > (ThreadBlocked or something), so that it has a chance to clean up. > > > > So perhaps the GC you want is already implemented? > > Simon > > > > *From:* haskell-bounces(a)haskell.org > <mailto:haskell-bounces@haskell.org> > [mailto:haskell-bounces@haskell.org > <mailto:haskell-bounces@haskell.org>] *On Behalf Of *Conal Elliott > *Sent:* 24 December 2007 00:15 > *To:* haskell(a)haskell.org <mailto:haskell@haskell.org> > *Subject:* [Haskell] garbage collection of Concurrent Haskell threads? > > > > The classic paper "The Incremental Garbage Collection of Processes" > (http://citeseer.ist.psu.edu/baker77incremental.html) describes > "futures" and how particularly garbage collecting them when their > pending result is no longer referenced. I've been playing with an > implementation of futures in Concurrent Haskell ( > http://haskell.org/haskellwiki/Reactive) using MVars, and I'm > stumped about how to GC non-winning threads in a race between > futures ("parallel or"). I'm having winner kill loser, which seems > to work fine, though is potentially dangerous w.r.t locked > resources. Still, the elegance of a GC-based solution appeals to > me. Has anyone explored process GC ideas for Concurrent Haskell (or > STM)? > > Futures are implemented using Concurrent Haskell's MVars. I first > tried using STM and TVars, simply using orElse to implement mappend > for futures. However, I didn't see how to avoid nesting > "atomically", which yielded a run-time error. If anyone has ideas > about using STM & TVars for futures, I'd love to hear. > > Thanks, - Conal > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

1 0

Re: [Haskell-cafe] Re: #haskell works
by Bulat Ziganshin 02 Jan '08

02 Jan '08

Hello Simon, Thursday, December 20, 2007, 4:01:59 PM, you wrote: > Fixing it all properly means some fairly significant architectural changes, > and dropping the via-C backend oh, thank you. from my POV, C backend still may be used together with "non-registerized" compilers. in particular, i hope that win-x64 will be supported at least in this way noone asked my question about plans of win-x64 support. it's important for my users, so i ask you again - can you please implement it? to other GHC users: i'm pretty sure that win-x64 support will not be implemented if it's required only for me. so, if someone need it - please write about this to ghc debelopers -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 2

ANNOUNCE: GHC version 6.8.2
by Ian Lynagh 02 Jan '08

02 Jan '08

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.8.1, including some significant performance fixes, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.8.2/html/users_guide/release-6-8-2.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

17 66

laura.daun@web.am
by Daniil Elovkov 02 Jan '08

02 Jan '08

Привет Лаура! С Новым Годом тебя и всю твою семью! Мама говорит тебе там мало солнца. День начал удлиняться. Пусть тебе будет светло и тепло. Мы тебе желаем здоровья, интересных приятных событий, поездок, дел. Пусть Оке и дети будут здоровы, удчачливы, всем довольны и тебя радуют! Gott nytt år till dig, Åke, Aram och David (och deras flickor också) ! Даня и Даша.

1 1

Re: patch applied (cabal): make rawSystemStdout put its temp files in the temp dir rather than cwd
by Gregory Wright 30 Dec '07

30 Dec '07

Hi Duncan, (Cross-posting to ghc-users since some of the issues were brought up there.) On Dec 2, 2007, at 5:04 PM, Duncan Coutts wrote: > Sun Dec 2 14:06:20 PST 2007 Duncan Coutts <duncan(a)haskell.org> > * make rawSystemStdout put its temp files in the temp dir rather > than cwd > Should fixe reported wierdness with finding program version numbers > > M ./Distribution/Simple/Utils.hs -2 +4 > I saw this problem when trying to build 6.8.1 on a mac (Leopard/Intel) using 6.4 to build compiler. I edited rawSystemStdout to put the tmp files directory in "/tmp" instead of using getTemporaryDirectory. On this combination of compilers, moving the temporary file did not fix the problem of finding the program version number. The underlying error was that the temp file was reported to still be locked. Building 6.8.2 with another 6.8.2 eliminated the program version problem, but I have seen two other intermittent errors which seem to be related. (Reported in trac as issue #1992.) Building 6.8.2 with 6.8.2 using the MacPorts infrastructure, I get this error about half the time: ../compiler/stage1/ghc-inplace -M -optdep-f -optdep.depend-BASE - osuf o -I../includes -H16m -O -I/opt/local/include -I/usr/include -L/ opt/local/lib -L/usr/lib -iutils -ibasicTypes -itypes -ihsSyn - iprelude -irename -itypecheck -ideSugar -icoreSyn -ivectorise - ispecialise -isimplCore -istranal -istgSyn -isimplStg -icodeGen -imain -iprofiling -iparser -icprAnalysis -indpFlatten -iiface -icmm - inativeGen -ighci -Wall -fno-warn-name-shadowing -fno-warn-orphans - Istage2 -package hpc -package bytestring -DGHCI -package template- haskell -DGHCI_TABLES_NEXT_TO_CODE -package readline -DUSE_READLINE - cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -H16M '- #include "cutils.h"' -package-name ghc-6.8.2 -fgenerics basicTypes/ BasicTypes.lhs basicTypes/DataCon.lhs basicTypes/Demand.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 cmm/CLabel.hs cmm/Cmm.hs cmm/ CmmBrokenBlock.hs cmm/CmmCPS.hs cmm/CmmCPSGen.hs cmm/CmmCallConv.hs cmm/CmmInfo.hs cmm/CmmLex.hs cmm/CmmLint.hs cmm/CmmLive.hs cmm/ CmmOpt.hs cmm/CmmParse.hs cmm/CmmProcPoint.hs cmm/CmmUtils.hs cmm/ Dataflow.hs cmm/MachOp.hs cmm/PprC.hs cmm/PprCmm.hs codeGen/Bitmap.hs codeGen/CgBindery.lhs codeGen/CgCallConv.hs codeGen/CgCase.lhs codeGen/ CgClosure.lhs codeGen/CgCon.lhs codeGen/CgExpr.lhs codeGen/ CgForeignCall.hs codeGen/CgHeapery.lhs codeGen/CgHpc.hs codeGen/ CgInfoTbls.hs codeGen/CgLetNoEscape.lhs codeGen/CgMonad.lhs codeGen/ CgParallel.hs codeGen/CgPrimOp.hs codeGen/CgProf.hs codeGen/ CgStackery.lhs codeGen/CgTailCall.lhs codeGen/CgTicky.hs codeGen/ CgUtils.hs codeGen/ClosureInfo.lhs codeGen/CodeGen.lhs codeGen/ SMRep.lhs coreSyn/CoreFVs.lhs coreSyn/CoreLint.lhs coreSyn/ CorePrep.lhs coreSyn/CoreSubst.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 cprAnalysis/CprAnalyse.lhs deSugar/ Check.lhs deSugar/Coverage.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/Debugger.hs ghci/GhciMonad.hs ghci/GhciTags.hs ghci/InteractiveUI.hs ghci/Linker.lhs ghci/ObjLink.lhs ghci/ RtClosureInspect.hs hsSyn/Convert.lhs hsSyn/HsBinds.lhs hsSyn/ HsDecls.lhs hsSyn/HsDoc.hs hsSyn/HsExpr.lhs hsSyn/HsImpExp.lhs hsSyn/ HsLit.lhs hsSyn/HsPat.lhs hsSyn/HsSyn.lhs hsSyn/HsTypes.lhs hsSyn/ HsUtils.lhs iface/BinIface.hs iface/BuildTyCl.lhs iface/IfaceEnv.lhs iface/IfaceSyn.lhs iface/IfaceType.lhs iface/LoadIface.lhs iface/ MkIface.lhs iface/TcIface.lhs main/BreakArray.hs main/CmdLineParser.hs main/CodeOutput.lhs main/Config.hs main/Constants.lhs main/ DriverMkDepend.hs main/DriverPhases.hs main/DriverPipeline.hs main/ DynFlags.hs main/ErrUtils.lhs main/Finder.lhs main/GHC.hs main/ HeaderInfo.hs main/HscMain.lhs main/HscStats.lhs main/HscTypes.lhs main/InteractiveEval.hs main/Main.hs main/PackageConfig.hs main/ Packages.lhs main/ParsePkgConf.hs main/PprTyThing.hs main/ StaticFlags.hs main/SysTools.lhs main/TidyPgm.lhs nativeGen/ AsmCodeGen.lhs nativeGen/GraphBase.hs nativeGen/GraphColor.hs nativeGen/GraphOps.hs nativeGen/GraphPpr.hs nativeGen/MachCodeGen.hs nativeGen/MachInstrs.hs nativeGen/MachRegs.lhs nativeGen/NCGMonad.hs nativeGen/PositionIndependentCode.hs nativeGen/PprMach.hs nativeGen/ RegAllocColor.hs nativeGen/RegAllocInfo.hs nativeGen/RegAllocLinear.hs nativeGen/RegAllocStats.hs nativeGen/RegArchBase.hs nativeGen/ RegArchX86.hs nativeGen/RegCoalesce.hs nativeGen/RegLiveness.hs nativeGen/RegSpill.hs nativeGen/RegSpillClean.hs nativeGen/ RegSpillCost.hs ndpFlatten/FlattenInfo.hs ndpFlatten/FlattenMonad.hs ndpFlatten/Flattening.hs ndpFlatten/NDPCoreUtils.hs ndpFlatten/ PArrAnal.hs parser/Ctype.lhs parser/HaddockLex.hs parser/ HaddockParse.hs parser/HaddockUtils.hs 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/TysPrim.lhs prelude/TysWiredIn.lhs profiling/ CostCentre.lhs profiling/SCCfinal.lhs rename/RnBinds.lhs rename/ RnEnv.lhs rename/RnExpr.lhs rename/RnHsDoc.hs rename/RnHsSyn.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/ SimplEnv.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/FamInst.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/TcGadt.lhs typecheck/ TcGenDeriv.lhs typecheck/TcHsSyn.lhs typecheck/TcHsType.lhs typecheck/ TcInstDcls.lhs typecheck/TcMType.lhs typecheck/TcMatches.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/TcTyFuns.lhs typecheck/TcType.lhs typecheck/TcUnify.lhs types/Class.lhs types/Coercion.lhs types/FamInstEnv.lhs types/ FunDeps.lhs types/Generics.lhs types/InstEnv.lhs types/TyCon.lhs types/ Type.lhs types/TypeRep.lhs types/Unify.lhs utils/Bag.lhs utils/ Binary.hs utils/BufWrite.hs utils/Digraph.lhs utils/Encoding.hs utils/ FastMutInt.lhs utils/FastString.lhs utils/FastTypes.lhs utils/ FiniteMap.lhs utils/IOEnv.hs utils/ListSetOps.lhs utils/Maybes.lhs utils/OrdList.lhs utils/Outputable.lhs utils/Panic.lhs utils/ Pretty.lhs utils/State.hs utils/StringBuffer.lhs utils/UniqFM.lhs utils/UniqSet.lhs utils/Util.lhs vectorise/VectBuiltIn.hs vectorise/ VectCore.hs vectorise/VectMonad.hs vectorise/VectType.hs vectorise/ VectUtils.hs vectorise/Vectorise.hs .depend-BASE: openFile: resource busy (file is locked) When I build in an eshell running under Aquamacs, I've consistently had the build fail with: ../utils/mkdependC/mkdependC -f .depend-BASE -D__GLASGOW_HASKELL__=608 -I../includes -Iutils -IbasicTypes -Itypes -IhsSyn -Iprelude -Irename - Itypecheck -IdeSugar -IcoreSyn -Ivectorise -Ispecialise -IsimplCore - Istranal -IstgSyn -IsimplStg -IcodeGen -Imain -Iprofiling -Iparser - IcprAnalysis -IndpFlatten -Iiface -Icmm -InativeGen -Ighci -I../ includes -- -O -I/opt/local/include -Iparser -I. -O -- parser/ cutils.c parser/hschooks.c /opt/local/bin/perl -pe 'binmode(stdin); binmode(stdout); s@(\S*[._]o)@stage2/$1@g; s@(\S*[._]hi)@stage2/$1@g; s@^.*/compat.* $@@g;' <.depend-BASE >.depend-2 /usr/bin/make -C compiler stage=2 ../compiler/stage1/ghc-inplace -cpp stage2/ghc-inplace.c -o stage2/ ghc-inplace ld: in /Users/gwright/Desktop/ghc-6.8.2/libraries/haskell98/dist/build/ libHShaskell98-1.0.1.0.a, archive has no table of contents collect2: ld returned 1 exit status make[2]: *** [stage2/ghc-inplace] Error 1 make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 In this last case, it looks as if libHShaskell98-1.0.1.0.a is being used before ranlib has been run on it. The common theme of these errors is that they all come out of Cabal, and seem to involve using the results of external processes before they are ready. In the original case of the temporary file used to record the version number, runProcess/waitForProcess are used. In the last case (running ranlib), runProcessPosix/ waitForProcess are used. Since the bug seems to be a race condition, it's not surprising that changing the code can cause it to disappear for a while. I will continue to look at what runProcess and waitForProcess are doing. Do you know of anything in Cabal that might confuse the handling of external processes? Were the original reports of weirdness in detecting the version number on OS X, or another operating system? Best Regards, Greg

2 1

How to use #ifdef WIN32
by Jim Burton 28 Dec '07

28 Dec '07

I want to switch code on the OS but this always goes through to the #else (on windows or elsewhere): {-# OPTIONS -cpp #-} #ifdef WIN32 main = putStrLn "hello windows" #else main = putStrLn "hello something else" #endif Does this depend on a Makefile setting WIN32, or should there be something predefined? Thanks, -- View this message in context: http://www.nabble.com/How-to-use--ifdef-WIN32-tp14448173p14448173.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

4 6

External Core - my goal
by Neil Mitchell 28 Dec '07

28 Dec '07

Hi Tim, Since you've now checked in External Core, I thought I'd ask how close we are to my ideal use case of External Core. My goal is to use External Core with Catch (http://www-users.cs.york.ac.uk/~ndm/catch/) To be able to use GHC Core with Catch, it is necessary to be able to do one of two things: 1) Compile all the associate libraries and modules of a program to generate separate GHC Core files for each one. Link them together to make one GHC Core file. Convert this Core file to Yhc Core. 2) Compile all the associate libraries and modules to generate separate GHC Core files for each. Convert each Core file to Yhc Core. Link the Yhc Core files together. I have no need to put the resultant Core back through GHC. How easy is it to compile up the Core for various associate libraries? Writing a convertor from GHC Core to Yhc Core is trivial, provided there can be some in-memory representation of GHC Core as an algebraic data type. The Core linker is trivial. The GHC bits are what I will need advice on! The Yhc compiler has this integrated, so that simply passing --linkcore will do all the magic listed here. Perhaps GHC could do with such a flag, or have some kind of ghc-linkcore program which is a wrapper around the GHC API. Thanks Neil

2 4

whole program optimization
by Isaac Dupree 28 Dec '07

28 Dec '07

GHC optimizes less effectively when parts of a program are in different modules, or are exported from a module. Therefore, merging all the code into one "module Main (main)" would help. Unfortunately, Haskell source syntax is ill-suited to this; for example: module-boundary monomorphism restriction different defaults in different modules deriving (Show, Read) --for renaming everything that's -- in different modules, so it doesn't conflict new GHC "{..}" etc. record stuff imports as, unknown import lists.... Also, program correctness can be wrongly increased; for example, using instances that were defined in some module imported by Main, but not by the module that uses the instance. I suppose this might affect overlapping instances somehow? But it seems plausible to merge modules on the GHC Core level, after desugaring and type-checking. Then the one infelicity would be that orphan RULES could apply in more places (RULES are converted and applied to Core!). Is this a problem? Does it already happen when modules import small inlinings from .hi files of modules that don't have access to the RULES? It would not actually be quite "whole-program" as long as all the libraries are compiled separately and only available through their .o and incomplete .hi files. Which is okay; but it would be nice if they could all also be compiled to the "complete-.hi" that we thought might serve for External Core -- and then one would just need to tell GHC to take all those complete-.hi's and compile them together into one executable. (except for complications like C _stub files, etc, etc. Also some parts of `base` might be wired-in enough that they need some thought before messing with them.) Then _any_ function that was only used once would be inlined, and GHC would generally be free to make decisions like that (at the GHC-speed price of having to look at all program and library code in detail) (however the GHC interface to this works, Cabal could probably help automate it somehow?) (Unfortunately, ghc-haskell source syntax doesn't provide an easy way to encode Core, even if we wanted to convert it back into GHC-compilable Haskell, without unsafeCoerce everywhere, I think?) So it's more complicated than it seems on the surface, but it could be done; I only wonder how effective it would be on various programs. I assume GHC doesn't currently implement any optimizations that can _only_ be whole-program, so it would still not be quite like Jhc, though this basic support might allow some such optimizations to be implemented. Isaac

7 12

GADT pattern match in non-rigid context
by Neil Mitchell 24 Dec '07

24 Dec '07

Hi, Upgrading from GHC 6.6 to 6.8 has caused some code to stop working: ---------------------------------------------------------------------- {-# OPTIONS_GHC -fglasgow-exts #-} module Data2 where data CCompany data Paradise :: * -> * where CC :: Paradise CCompany rewrapCC CC = [] ---------------------------------------------------------------------- [1 of 1] Compiling Data2 ( Data2.hs, interpreted ) Data2.hs:12:9: GADT pattern match in non-rigid context for `CC' Tell GHC HQ if you'd like this to unify the context In the pattern: CC In the definition of `rewrapCC': rewrapCC CC = [] This code is from the Uniplate benchmarking code, which runs the Paradise benchmark from SYB on Uniplate, Compos and SYB. The Compos code uses GADT's, so the program first needs to convert from standard data structures to GADT's before it can work, then back at the end. It's the problem of converting from a GADT to a normal data structure that is failing. So is there an easy workaround? Or should I be asking GHC HQ to unify things? Thanks Neil

3 4