- Glasgow-haskell-users

Package "mounting" proposal
by Sven Moritz Hallberg 16 Jul '06

16 Jul '06

Hi lists, (I hope my cross-posting is okay, but somehow this post seems to apply to all of you, so here goes...) I've recently noticed that folks at GHC HQ are working on a way to resolve the problem of importing two modules with the same name from different packages. There is a proposal[1] on the GHC wiki calling for a syntax extension for 'import' statements in Haskell modules so that the package (and version) to import from can be specified explicitly. There is a second ("extended") proposal[2], which calls for the ability to import (subtrees of) the module hierarchy exposed by a package and attach it to the global module namespace at an arbitrary point, analogous to mounting a filesystem in Unix. This proposal was appearently inspired by a post to the libraries mailing list by Frederik Eaton[3]. I agree with Frederik that it would be very nice to remove the burden of writing out long package or hierarchy prefixes in modules, and just work in some previously defined context. I'd like to propose yet another alternative to the existing two proposals that follows [2] in trying to satisfy [3] but differes from it in the following ways: - It doesn't require an extension of the existing Haskell syntax. - It can be implemented by extending Cabal alone (AFAICT). In particular, I propose to drop the assumption that Haskell modules are closed entities but rather always consider them to be seen in the context of a particular _package_. The package is now made responsible for assembling an appropriate (hierarchical) module namespace to which imports in the packaged modules are taken to refer. To this end, the current 'depends:' entry in a package description would be replaced by a more general "mounting" construct, i.e. "mount package foo at Foo.Bar in the module hierarchy". Optionally, as in [2], only a subtree of "foo" could be selected, or only a specific version of "foo". While I'm at it, I had to evaluate how this proposal would interact with the "ECT" module versioning scheme, I've proposed earlier[4]. I'd like to rework that scheme to this proposal. In ECT, a library author guarantees to his users that their imports will never break by providing different (numbered) variants of the library modules whenever their interface changes. By keeping the old variants as re-exports of updated versions, the author can record compatibilities. This carries the burden for users to annotate each import with a version number. If we lift the principles of ECT to the package level in accord with this proposal, that burden largely evaporates. Keeping the promise of "eternal backwards-compatibility", however, requires an (obvious) extension to the way Cabal deals with version numbers... First of all, package "mounts" must be able to say "this version, or any compatible one". Obviously, that's actually always what one wants, so it can be taken to be the only meaning of specifying "mount foo-1.3 at Foo.Bar". Then the question is just when to consider another version of foo compatible to 1.3. Obviously, only later versions should be considered, but when does compatibility end? Only the author of foo knows! She must specify it somehow. Two possibilities come to mind: 1. Add a field to the package description of foo (v1.4, say) that says "I'm backwards-compatible with 1.3." When building, this relation would have to be inspected to see whether any currently installed version of foo satisfies the dependency specified by the mount. 2. Declare a convention for version numbers to carry compatibility information, like the OpenGL standard, for example: If the new version is backwards-compatible, only the minor version number changes. If it isn't, the major version number must be incremented. I'd personally favour 2, as it would be easier to maintain for the author of foo (no compatiblity-field in the package description to update all the time) and also to implement in the build system (just a simple version comparison instead of a relation traversal to check a dependency). As a (more conservative?) variant of alternative 2, the third (instead of second) version component could be declared as "stays compatible", i.e. if only the third (or later) version component changes, the new version is assumed backwards-compatible, otherwise it's assumed incompatible. This would allow frequent incompatible updates without quickly getting large major version numbers... As for wasting space by keeping old versions around: Of course, if the new one is backwards-compatible, any old version can be removed. Otherwise, if it's "half-way" compatible, the author of foo can release a new backwards-compatible revision of the old version that reimplements (part of) the functionality in terms of the new operations, so the old version can be replaced by this leaner revision. Comments? Best regards, Sven [1]: http://cvs.haskell.org/trac/ghc/wiki/GhcPackages [2]: http://cvs.haskell.org/trac/ghc/wiki/GhcPackageNamespaces [3]: http://www.haskell.org/pipermail/libraries/2005-June/004009.html [4]: http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory

2 1

Poor compile times
by Neil Mitchell 15 Jul '06

15 Jul '06

Hi, Using GHC 6.4.2 on Windows and 6.4.1 on Linux, I get really poor compile time performance for large do blocks - for example: main = do return () return () .... return () The following are the compile times in seconds for a given number of return () lines, GHC 6.4.1 on Linux, with a very beefy processor (my department server) and loads of RAM. 100 1.444 200 4.054 300 7.977 400 13.967 500 21.265 600 30.71 700 43.997 For comparison on my desktop machine I get out of heap space with 268Mb of heap, in a few minutes for 700. Compared to Hugs and Yhc, which both deal with all of these files instantly. By splitting the 700 line do block into 7 separate do blocks, each 100 lines, I get a compile time of 8.530. The particular reason I was running into this issue was with an auto generated file of tests, about 360 lines of reasonably lines in a do block, which exhausted the memory in GHCi. I have modified my test generator to split the files into 50 line blocks. Thanks Neil

1 0

Compile problem on Windows
by Robert Dockins 14 Jul '06

14 Jul '06

I posted a message on the libraries list a couple of days ago about a compile problem I'm having. I haven't got any nibbles. Because I now suspect this is a GHC problem, I'm posting here to see it I can get this resolved. Rather than repost the details, allow me to refer you to (http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/ 4873) which contains a complete description of the problem. As far as I can tell, the GHC install is missing a necessary system header, or it isn't being found, or somesuch. I tried crawling through the headers to find out what the problem is, but, as per usual, the system headers are almost totally incomprehensible. I've tried using both Cygwin and MSYS shells, but the results are identical. As I said in the above message, I'm not very familiar with this environment, so I'd appreciate pointers in the correct direction if I've made some mistake. Thanks Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

2 3

Where is HsTimeConfig.h?
by Alistair Bayley 14 Jul '06

14 Jul '06

I'm trying to build Ashley's time package with GHC6.4 on Windows XP, and there are a few things it uses which seem to be in GHC6.6 only. Some of them I can find in the GHC sources, but I am unable to locate HsTimeConfig.h. When GHC is installed I'd expect to find it under C:\ghc\ghc-6.4.1\include, but I can't tell where this maps to in the ghc source tree. Thanks, Alistair

5 8

STM check operation
by Rodney D Price 14 Jul '06

14 Jul '06

I've been reading the STM papers on Simon PJ's website, but I find that the GHC I'm using (6.5) changes a few things from the paper's descriptions. For instance, "atomic" becomes "atomically" and "catch" becomes "catchSTM". I can't, however, find "throw", and the type signature of "check" has changed. The GHC documentation isn't much help. Is there a discussion, perhaps in a mailing list archive somewhere, that will shed some light on these changes? Thanks, -Rod

3 4

RE: [Haskell] crash unsafeperformio stm
by Simon Peyton-Jones 14 Jul '06

14 Jul '06

[Redirecting to GHC users] A crash is bad, and the HEAD reports an error in a civilised way. It is indeed illegal to use atomically inside an unsafePerformIO. I've also committed a fix to the documentation of atomically to mention this point. In general, the documentation of STM is very thin -- we would welcome someone to improve it. Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Johannes Goetz | Sent: 12 July 2006 04:50 | To: Haskell Mailing List | Subject: [Haskell] crash unsafeperformio stm | | hi folks, | | i'm using ghc6 (apt-get install ghc6) on debian31. as far is i | understand, the following program shouldn't crash. can somebody tell me | why it does? thanks a lot. johannes. | | module Main(main) where | | import Control.Concurrent.STM | import System.IO.Unsafe | | {-# NOINLINE a #-} | a :: TMVar Int | a = unsafePerformIO $ atomically $ newTMVar 123 | | main = do | atomically $ takeTMVar a >>= putTMVar a | | ghc --make -fno-cse Test.hs -o test | ./test | Segmentation fault | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

RULES pragmas
by Malcolm Wallace 14 Jul '06

14 Jul '06

I have a question about {-# RULES #-} pragmas. Here is a very simple attempt to use them: module Simplest where {-# RULES "simplestRule" forall x. id (id x) = x #-} myDefn = id (id 42) I want to verify whether ghc-6.4.1 does actually fire this rule, but have so far been unable to do so. According to the manual (section 7.10.5), the flag -ddump-rules should list "simplestRule" if it has been parsed correctly, and -ddump-simpl-stats should list the number of times it has fired. But it does not appear in either listing. Reasoning that I have the syntax wrong, I have tried numerous variations on the indentation, added type signatures, etc., all to no avail. So what am I doing wrong? And is there any way to ask the compiler to give a warning if the RULES pragma contains errors? Regards, Malcolm

4 5

RE: [Haskell] problem building syb-generics
by Simon Peyton-Jones 12 Jul '06

12 Jul '06

[Redirecting to ghc-users] Matthew Lexically-scoped type variables are undergoing a slight upheaval in GHC 6.6 that has not quite settled, and that is what you are running into. Pattern-bound lexically-scoped type variables are particularly problematic f (x::a) = ... The ones that are totally safe are f :: forall a. a->a f x = ... In this, 'a' is in scope in the whole of f's right-hand side. Maybe you can refactor the code a little to use this? I'm sorry about this. We need to get the rules for lexically scoped type variables nailed down (for Haskell Prime as well as GHC) but it keeps slipping down my priority list. It's important but unrewarding! Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Matthew Pocock | Sent: 04 July 2006 12:38 | To: haskell(a)haskell.org | Subject: [Haskell] problem building syb-generics | | Hi, | | I had some trouble getting syb-generics 2.9 to compile with ghc 6.5 (don't | ask - I should probably be waiting for a stable release). I fixed the first | problem by replacing a definition with in-line type info by splitting the | type out, although I am not sure that I have done it right. Can anybody shed | some light on this? | | Matthew | | | ---------the error-------- | Building syb-generics-2.9... | [1 of 7] Compiling Data.Context ( Data/Context.hs, | dist/build/Data/Context.o ) | | Data/Context.hs:48:9: | A pattern type signature cannot bind scoped type variables `l' | unless the pattern has a rigid type context | In the pattern: l :: l () | In the definition of `pairCtx': | pairCtx (l :: l ()) (r :: r ()) = undefined :: PairCtx l r () | | --------original code------ | pairCtx (l::l ()) (r::r ()) | = undefined::PairCtx l r () | | --------my code------------- | pairCtx :: l () -> r () -> PairCtx l r () | pairCtx l r | = undefined | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

2 2

Is this test summary good or bad?
by Joel Reymont 12 Jul '06

12 Jul '06

Folks, I'm running Mac OSX 10.4.7 on Intel. This is the result of running the ghc-regress suite of tests using a freshly updated ghc 6.5 that was bootstrapped using a binary distribution. I suspect the framework failures were cases where tests got hung and I had to Ctrl-C them to let testing continue. I'm not sure, though. OVERALL SUMMARY for test run started at Sun Jul 9 19:02:59 BST 2006 1090 total tests, which gave rise to 4985 test cases, of which 13 caused framework failures 1003 were skipped 3460 expected passes 22 expected failures 0 unexpected passes 448 unexpected failures Unexpected failures: 10queens(ghci) CPUTime001(ghci) Chan001(ghci) IOError002(ghci) MVar001(opt,ghci) QSem001(ghci) QSemN001(ghci) SampleVar001(ghci) TH_bracket1(normal) TH_bracket2(normal) TH_bracket3(normal) TH_class1(normal) TH_dupdecl(normal) TH_exn(normal) TH_fail(normal) TH_genEx(normal) TH_mkName(normal) TH_recover(normal) TH_reifyDecl1(normal) TH_reifyType1(normal) TH_reifyType2(normal) TH_repE1(normal) TH_repE2(normal) TH_repE3(normal) TH_repGuard(normal) TH_repGuardOutput(normal) TH_repPatSig(normal) TH_repPrim(normal) TH_repPrimOutput(normal) TH_spliceDecl1(normal) TH_spliceDecl2(normal) TH_spliceDecl3(normal) TH_spliceDecl4(normal) TH_spliceE1(normal) TH_spliceE3(normal) TH_spliceE4(normal) TH_spliceE5(normal) TH_spliceE5_prof(normal) TH_spliceExpr1(normal) TH_spliceInst(normal) TH_tuple1(normal) TH_where(normal) addr001(ghci) andre_monad(ghci) andy_cherry(ghci) arith001(ghci) arith002(ghci) arith003(ghci) arith004(ghci) arith005(ghci,threaded1) arr001(ghci) arr002(ghci) arr003(ghci) arr004(ghci) arr005(ghci) arr006(ghci) arr007(ghci,threaded2) arr008(normal,ghci) arr009(profasm,ghci) arr010(ghci) arr011(ghci) arr012(ghci) arr013(ghci) arr014(ghci) arr015(ghci) arr016(ghci,threaded2) arr017(ghci) arrowlet1(normal) arrowrun001(ghci) arrowrun002(ghci,threaded2) arrowrun003(ghci) arrowrun004(profasm,ghci) barton-mangler-bug(ghci) bits(ghci) cabal01(normal) cc012(profasm) cg001(ghci) cg002(prof,ghci) cg003(ghci) cg004(ghci) cg005(ghci) cg006(ghci) cg007(ghci) cg008(ghci) cg009(ghci) cg010(ghci) cg011(ghci) cg012(ghci) cg013(ghci) cg014(ghci) cg015(prof,ghci) cg016(ghci) cg017(optasm) char001(ghci) char002(ghci) cholewo-eval(ghci) church(ghci) conc001(ghci) conc002(ghci) conc003(ghci) conc006(ghci) conc007(ghci) conc008(ghci) conc027(ghci) conc049(ghci) conc051(ghci) concprog001(ghci) currentDirectory001(ghci) cvh_unboxing(ghci) datatype(ghci) diffArray001(prof,profasm,ghci) directory001(ghci) doesDirectoryExist001(ghci) drvfail001(normal) drvfail002(normal) drvrun001(ghci) drvrun002(ghci) drvrun003(ghci) drvrun004(ghci) drvrun005(ghci) drvrun006(ghci) drvrun007(profasm,ghci) drvrun008(ghci) drvrun009(ghci) drvrun010(ghci) drvrun011(ghci) drvrun012(ghci) drvrun013(ghci) drvrun014(ghci) drvrun015(ghci) drvrun016(ghci) drvrun017(ghci) drvrun018(ghci) drvrun019(ghci) dsrun001(ghci) dsrun002(ghci) dsrun003(ghci) dsrun004(prof,ghci) dsrun005(prof,ghci) dsrun006(ghci) dsrun007(ghci,threaded2) dsrun008(ghci,threaded2) dsrun009(prof,ghci) dsrun010(ghci) dsrun011(ghci) dsrun012(ghci) dsrun013(ghci) dynamic001(ghci) dynamic002(ghci) echo001(ghci) enum01(ghci) enum02(ghci) enum03(ghci) exceptions001(ghci,threaded2) exceptions002(ghci) exitWith001(ghci) ext1(optasm,ghci) fast2haskell(ghci) ffi-deriv1(opt) fileexist01(normal,ghci) finalization001(ghci) forkprocess01(ghci,threaded2) freeNames(ghci) fun_insts(ghci) galois_raytrace(ghci) genUpTo(ghci) geq(ghci) getArgs001(ghci) getC(ghci) getEnv001(prof,ghci) getPermissions001(prof) ghci001(ghci,ghci) ghci002(ghci) ghci003(ghci) ghci004(ghci) ghci005(ghci) ghci006(ghci) ghci007(ghci) ghci008(ghci) ghci009(ghci) ghci011(ghci) ghci012(ghci) ghci013(ghci) ghci014(ghci) ghci015(ghci) ghciprog004(normal) gmapQ-assoc(ghci) gread(ghci) gshow(ghci) gzip(ghci) hClose001(optasm,ghci) hFileSize001(ghci) hTell001(ghci) hTell002(ghci) hash001(ghci) ioref001(ghci) jl_defaults(ghci) joao-circular(ghci) jq_readsPrec(ghci) jtod_circint(ghci) jules_xref(optasm,ghci) jules_xref2(optasm,ghci) labels(ghci) launchbury(ghci) lennart_range(ghci) lex(ghci) lexNum(ghci) life_space_leak(ghci) list001(profasm,ghci) maessen_hashtab (normal,opt,optasm,prof,profasm,ghci,threaded1,threaded2) memo001(ghci) memo002(ghci) mod100(normal) mod118(normal) mod30(normal) mod53(normal) mod55(normal) mod56(normal) nested-datatypes(ghci) net001(ghci,threaded2) net002(ghci) newtype(ghci) north_array(ghci) num001(ghci) num002(ghci) num003(ghci) num004(ghci) num005(ghci) num006(prof,ghci) num007(ghci) num008(optasm,ghci) packedstring001(ghci) paradise(ghci) performGC001(ghci) process001(ghci) process002(ghci) prog001(ghci) prog002(ghci) prog003(ghci) prog005(ghci) prog006(ghci) queryfdoption01(profasm) rand001(ghci) ratio001(ghci) read001(ghci) read015(opt) readLitChar(ghci) record_upd(ghci) regex001(ghci) reify(ghci) rittri(ghci) rn.prog006(normal) rn017(normal) rn022(prof) rn026(normal) rn028(opt) rn031(normal) rn035(profasm) rnfail043(normal) rw(normal) sanders_array(ghci) seward-space-leak(ghci) show001(ghci) signals001(optasm,ghci) signals002(ghci) simpl005(profasm) simpl009(prof) simpl011(normal,opt,optasm,prof,profasm) simpl014(profasm) stableptr001(ghci) stableptr003(optasm,ghci) stableptr004(profasm,ghci) stableptr005(prof,ghci) strict_anns(ghci) strings(ghci) system001(ghci) tc002(normal) tc056(normal,opt,optasm,prof,profasm) tc076(opt,optasm) tc092(normal,opt,optasm) tc097(normal,opt,optasm) tc102(normal,opt,optasm,prof,profasm) tc104(prof) tc106(prof) tc109(opt) tc134(normal,opt,optasm,prof,profasm) tc135(normal) tc136(normal,opt,optasm,prof,profasm) tc137(opt) tc141(normal,opt,optasm,prof,profasm) tc150(normal) tcfail002(normal) tcfail004(normal) tcfail005(normal) tcfail010(normal) tcfail013(normal) tcfail014(normal) tcfail018(normal) tcfail040(normal) tcfail043(normal) tcfail046(normal) tcfail061(normal) tcfail068(normal) tcfail071(normal) tcfail072(normal) tcrun001(ghci) tcrun002(opt,ghci) tcrun003(ghci) tcrun004(ghci,threaded2) tcrun005(ghci) tcrun006(ghci,threaded1) tcrun007(ghci) tcrun008(ghci) tcrun009(ghci) tcrun010(ghci) tcrun011(ghci) tcrun012(ghci) tcrun013(ghci) tcrun014(ghci) tcrun015(ghci,threaded2) tcrun016(ghci) tcrun017(ghci) tcrun018(ghci) tcrun019(ghci) tcrun020(ghci) tcrun021(ghci) tcrun022(ghci) tcrun023(ghci) tcrun024(ghci) tcrun025(ghci) tcrun027(ghci) tcrun028(normal,ghci) tcrun029(ghci) tcrun030(ghci) tcrun031(ghci) tcrun032(ghci) tcrun033(ghci) tcrun034(ghci) tcrun035(normal,opt,optasm,prof,profasm,ghci,threaded1,threaded2) tcrun036(ghci) tcrun037(ghci) testeq2(ghci) text001(ghci) thurston-modular-arith(ghci) time002(ghci,threaded1) time003(ghci,threaded1) time004(ghci) trace001(ghci) tree(ghci) tup001(ghci) twin(ghci) typecheck.testeq1(ghci) unicode001(ghci,ghci) unicode002(ghci) uri001(ghci) utf8_002(normal) utf8_003(normal) utf8_004(normal) utf8_005(normal) weak001(ghci) where(ghci) xmlish(ghci) -- http://wagerlabs.com/

3 11

HTML->Wiki pages conversion for old GHC commentaries
by Bulat Ziganshin 12 Jul '06

12 Jul '06

Hello , Let's compare http://haskell.org/haskellwiki/Test and http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/rts-libs/multi-thread.html Wiki supports part of HTML tags and as you can see results are not so bad (i just inserted the entire HTML file contents as the wiki source). May be we can just go this way in order to incorporate old GHC commentaries into haskellwiki instead of performing real html->wiki page conversion? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1