November 2010 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

Printing of asynchronous exceptions to stderr
by Mitar 16 Dec '10

16 Dec '10

Hi! I have been spend some time to debug this in my program. ;-) Why is ThreadKilled not displayed by RTS when send to thread (and unhandled), but any other exception is? For example, I am using custom exceptions to signal different kinds of thread killing. Based on those my threads cleanup in different ways. But after they cleanup they keep "running". Not really running as their computations were interrupted. But simply hanging there. And if then new custom exception arrives it is not handled anymore (as it is after my normal exception handlers already cleaned everything) and it is printed to stderr. Now I added "`finally` throwIO ThreadKilled" at the end of my cleanup computations to really kill the thread. So that possible later exceptions are not delivered anymore. Why it is not so that after all computations in a thread finish, thread is not killed/disposed of? Because it can be reused by some other computation? But then my exceptions could be delivered to wrong (new) thread while they were meant for old one? Mitar

4 20

ANNOUNCE: GHC version 7.0.1
by Ian Lynagh 07 Dec '10

07 Dec '10

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.0.1 ============================================================= The GHC Team is pleased to announce a new major release of GHC. Since the 6.12 branch we are delighted that more than 60 people have contributed patches to GHC or the accompanying libraries and utilities. There have been a number of significant changes since the last major release, including: * GHC now defaults to the Haskell 2010 language standard * -fglasgow-exts is now deprecated, in favour of the individual extension flags * On POSIX platforms, there is a new I/O manager based on epoll/kqueue/poll, which allows multithreaded I/O code to scale to a much larger number (100k+) of threads * GHC now includes an LLVM code generator which, for certain code, can bring some nice performance improvements * The type checker has been overhauled, which means it is now able to correctly handle interactions between the type systemextensions * The inliner has been overhauled, which should in general give better performance while reducing unnecessary code-size explosion * Large parts of the runtime system have been overhauled, including fixing several instances of pathological performance when there are large numbers of threads * Due to changes in the runtime system, if you are using Control.Parallel.Strategies from the parallel package, please upgrade to at least version 2 (preferably version 3) * The full Haskell import syntax can now been used to bring modules into scope in GHCi * GHC now comes with a more recent mingw bundled on Windows, which includes a fix for windres on Windows 7 * There is a new -fno-ghci-sandbox flag, which stops GHCi running computations in a separate thread; in particular, this works around an issue running GLUT from GHCi on OS X The full release notes are here: http://new-www.haskell.org/ghc/docs/7.0.1/html/users_guide/release-7-0-1.ht… 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

6 13

Problems with openFd and -threaded
by wren ng thornton 03 Dec '10

03 Dec '10

So I've just started playing around with STM and -threaded programs and I've run into a bug. The bug is similar to [1] except that the file in question is a Posix FIFO instead of a Bluetooth device. Same behavior: always errors with -threaded, but expected behavior when not -threaded (i.e., blocks until another process opens the other end of the FIFO). GHC version is 6.12.1. In the previous thread Simon confirmed that it's a bug and said he'd fix it, but I didn't see any ticket mentioned. Does anyone know if there's a ticket for it, or when it will be/has been fixed? [1] http://www.haskell.org/pipermail/glasgow-haskell-users/2009-December/018147… -- Live well, ~wren

4 6

ANN: HaLVM 1.0: the Haskell Lightweight Virtual Machine
by Adam Wick 30 Nov '10

30 Nov '10

Galois, Inc. is pleased to announce the immediate release of the Haskell Lightweight Virtual Machine (or HaLVM), version 1.0. The HaLVM is a port of the GHC runtime system to the Xen hypervisor, allowing programmers to create Haskell programs that run directly on Xen's "bare metal." Internally, Galois has used this system in several projects with much success, and we hope y'all will have an equally great time with it. What might you do with a HaLVM? Pretty much anything you want. :) Explore designs for operating system decomposition, examine new notions of mobile computation with the HaLVM and Xen migration, or find interesting network services and lock them inside small, cheap, single-purpose VMs. The HaLVM is the result of many years of effort, by many people inside Galois. Although it is not yet totally bug-free, we have decided that broad adoption wins over perfection and thus we are releasing it for general review. As such, there will be some rough edges, and we urge you to read the documentation to understand the platforms we test on. We are releasing the HaLVM under a non-restrictive BSD3 license. You can find it here: http://halvm.org We welcome user feedback, feature requests, bug notices, patches, and feature additions; see the page above for guidelines on getting involved. Finally, we'd like to give many things to the GHC and Xen communities, without which this work would not be possible. If you have any questions or concerns, please don't hesitate to contact the HaLVM's maintainers at halvm-devel(a)community.galois.com. Have a lovely day! - Adam

2 1

Documentation of System.Process
by Jean-Marie Gaillourdet 30 Nov '10

30 Nov '10

Hi all, I've been searching information regarding file handles to pipes created by System.Process.createProcess. The documentation does not state whether they are in binary mode, i.e. whether they have line ending conversion or an encoding enabled. That kind of information is available for runInteractiveCommand in the same module. runInteractiveCommand opens all pipes in binary mode. I've concluded from the source of that module that the same is probably true for createProcess. I've two questions now: 1. Is it correct that createProcess returns file handles in binary mode when creating pipes? 2. Could you add that information to the haddock docs? Is their some other place where I could have found this? Thanks for your great work! Regards, Jean

2 2

Re: packaging options for Mac OS X
by Ian Lynagh 29 Nov '10

29 Nov '10

On Sun, Nov 28, 2010 at 12:56:00PM -0800, Mark Lentczner wrote: > > Outstanding question is what should this framework be called? I would like to continue to call it GHC.framework, but change the version to something like 7.0.1+HP-i386, I think it ought to be called Haskell-Platform.framework. > [*] The binary GHC distribution could be > - built by the GHC team, and asking them for a tarball (as Duncan suggested) I do "make framework-pkg" to build the OS X installer, but it's essentially a black box to me. We're happy to accept patches that make this also produce a bindist, though. Now that we have the Haskell Platform, perhaps we should stop making GHC OS X installers, and only make plain old unix bindists. Thanks Ian

2 2

SpecConstr number of specializations (-fspec-constr-count)
by José Pedro Magalhães 29 Nov '10

29 Nov '10

Hi all, When compiling some program with -O2 using ghc-7.0.1, I got warnings like > SpecConstr > Function `$j_s7Xo{v} [lid]' > has three call patterns, but the limit is 1 > Use -fspec-constr-count=n to set the bound > Use -dppr-debug to see specialisations > SpecConstr > Function `$j_s7YI{v} [lid]' has 7 call patterns, but the limit is 3 > Use -fspec-constr-count=n to set the bound > Use -dppr-debug to see specialisations > I proceeded to compile with -fspec-constr-count=10, but I still got > SpecConstr > Function `$j_s7Xo{v} [lid]' has 7 call patterns, but the limit is 1 > Use -fspec-constr-count=n to set the bound > Use -dppr-debug to see specialisations > With -fspec-constr-count=55, I got > SpecConstr > Function `$j_s7Xo{v} [lid]' has 7 call patterns, but the limit is 6 > Use -fspec-constr-count=n to set the bound > Use -dppr-debug to see specialisations > Finally, with -fspec-constr-count=56, the warnings disappear. Is this a bug, or is the value of spec-constr-count being manipulated in some way for certain passes? Thanks, Pedro

3 3

How to activate DEBUG in Data.HashTable?
by Wolfram Kahl 29 Nov '10

29 Nov '10

Hello, with a large Agda development, I have a reproducible segmentation fault that I have been able to localise to the serialisation (Agda.TypeChecking.Serialise.encode), which heavily relies on Data.HashTable. Now I find that Data.HashTable (from GHC-7.0.1) has a CPP-enabled DEBUG version --- is there a ``proper'' way to activate this? Possibly even so that it can be added ex-post to an existing installation? (So I don't have to re-install all packages.) mk/ways.mk says that the ``debug'' way only affects the RTS... Wolfram

2 1

Modifying functions in the typechecker?
by Nils Schweinsberg 29 Nov '10

29 Nov '10

Hi, I'm currently working on a GHC extension called "monad comprehensions" [1]. Typechecking for generators ("pat <- rhs") already works, but filters are a bit more tricky. Basicly, it works like that: A monad comprehension... [ body | E ] -- E :: Bool ...should desugar to: Control.Monad.guard E >> return body In the typechecker I typecheck E for type Bool, and see if we're in a MonadPlus by typechecking "guard". But I have to "pass" this guard-then-op function to the desugarer, so I created a new expression "then_op' = (>>) . guard" and pass this function to the ExprStmt constructor. The code in typecheck/TcMatches.lhs looks currently like this: tcMcStmt _ (ExprStmt rhs then_op _) res_ty thing_inside = do { -- Typecheck rhs on type Bool rhs' <- tcMonoExpr rhs boolTy -- Deal with rebindable syntax: -- then_op :: rhs_ty -> new_res_ty -> res_ty -- See notes in tcDoStmt. -- After this we redefine then_op to have the following type: -- then_op' :: Bool -> new_res_ty -> res_ty -- then_op' = (>>) . guard ; rhs_ty <- newFlexiTyVarTy liftedTypeKind ; new_res_ty <- newFlexiTyVarTy liftedTypeKind ; let then_ty = mkFunTys [rhs_ty, new_res_ty] res_ty guard_ty = mkFunTys [boolTy] rhs_ty comp_ty = mkFunTys [then_ty, guard_ty, boolTy, new_res_ty] res_ty ; then_op <- tcSyntaxOp MCompOrigin then_op then_ty ; guard_op <- tcSyntaxOp MCompOrigin (HsVar guardMName) guard_ty ; compose_op <- tcSyntaxOp MCompOrigin (HsVar composeName) comp_ty ; let then_op' = HsApp (nlHsApp (noLoc compose_op) (noLoc then_op)) (noLoc guard_op) ; thing <- thing_inside new_res_ty ; return (ExprStmt rhs' then_op' boolTy, thing) } Is this a valid approach? Should I move the "(>>) . guard" function somewhere else? I had a look at the renamer where "(>>)" is added to the statement "ExprStmt" the first time, but apparently you cannot call "tcSyntaxOp" in the typechecker on this function if you construct it with "HsApp (compose_op `HsApp` then_op) guard_op". Is there another function which could typecheck such a constructed expression without telling the user what functions we've used? I also had a look at the MDo typechecker, where they use this: ; let names = [mfixName, bindMName, thenMName, returnMName, failMName] ; insts <- mapM (\name -> newMethodFromName DoOrigin name m_ty) names ; return $ mkHsWrapCoI coi $ HsDo (MDoExpr (names `zip` insts)) stmts' body' res_ty' } So they can use these names with their typechecked versions in the desugarer. But if I do this for monad comprehensions and "guard", *every* monad comprehension will require a MonadPlus instance, which shouldn't be necessary if there are no filter expressions. Any advice on how this could be solved? Thanks, Nils [1]: http://hackage.haskell.org/trac/ghc/ticket/4370

2 1