- ghc-devs - Haskell.org

RE: Haskell on windows 7 installation instructions
by Simon Peyton Jones 27 Jun '14

27 Jun '14

Very helpful Artella. Your page is about *using* Haskell or GHC on Windows. That is usefully distinct from how to *build* GHC on Windows; there is a separate page on the Trac wiki about that. I’ve added a clarifying sentence to your page, and added links from each to the other. I’m cc’ing a few others who have Windows knowledge. I would love it if you guys formed a GHC-on-Windows Task Force, who tried to make sure that the Windows experience was always good. At the moment we have lots of Windows users but very few who are willing to help make it work, the recipients of this email being honourable exceptions. Simon From: Artella Coding [mailto:artella.coding@googlemail.com] Sent: 25 June 2014 11:54 To: Simon Peyton Jones Subject: Haskell on windows 7 installation instructions Hi, I saw the installation instructions in http://www.gundersen.net/haskell-on-windows/ which cover installing in windows with msys (you suggested to the author that he put the instructions up on haskellwiki). However I wanted to install with the newer msys2 (which allows copying and pasting) and had quite a few problems initially (especially when trying to build hoogle). I have worked out all the issues, and have taken the liberty of writing the instructions at : http://www.haskell.org/haskellwiki/Windows which might require further editing. It took me a whole week to sort this out and thought it might be of help to others. I found that if you don't define the MSYSTEM environment variable (if you use the "msys2_shell.bat" instead of the "mingw32_shell.bat" or "mingw64_shell.bat" then this environment variable is not defined), then when you build hoogle you get some strange linker error messages https://github.com/haskell/cabal/issues/1950 . I didnt want to make the instructions too long, so omitted any explanation of why this environment variable is needed. Cheers

1 0

Pruning GADT case alternatives with uninhabitable coercion parameters
by Conal Elliott 26 Jun '14

26 Jun '14

I'm looking for tips on pruning away impossible branches in `case` expressions on GADTs, due to uninhabited coercion parameter types. Here's a simple example (rendered by HERMIT) from a type-specializion of the Foldable instance a GADT for perfect leaf trees in which the tree depth is part of the type: > case ds of wild (Sum Int) > L (~# :: S (S Z) ~N Z) a1 -> f a1 > B n1 (~# :: S (S Z) ~N S n1) uv -> ... Note the kind of the coercion parameter to the leaf constructor (`L`): `S (S Z) ~N Z`, i.e., 2 == 0. I think we can safely remove this branch as impossible. The reasoning gets subtler, however. After inlining and simplifying in the second (`B`) alternative, the following turns up: > case ds0 of wild0 (Sum Int) > L (~# :: n1 ~N Z) a1 -> f0 a1 > B n2 (~# :: n1 ~N S n2) uv0 -> ... Now I want to remove the first `L` alternative with `n1 ~ Z`, given that the kind `S (S Z) ~N S n1` is inhabited (since we're in the first `B` alternative), so that `n1 ~ S Z`. With more inlining, more such equalities pile up. Soon we get to an impossible `B` alternative, whose removal would then eliminate the rest of the recursive unfolding. My questions: * Does this sort of transformation already live in GHC somewhere, and if so, where? * Are there gotchas / sources of unsoundness in the transformation I'm suggesting? * Is anyone else already working on this sort of transformation? -- Conal

3 6

2nd call for contributions: Haskell Implementors' Workshop 2014
by Jost Berthold 26 Jun '14

26 Jun '14

Dear fellow Haskellers, We are 20 days away from the deadline for HIW 2014. If you have an exciting topic you would like to present, please propose a talk by submitting an abstract (through easychair, see below). Best regards Jost Berthold ==================================================================== Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2014 Gothenburg, Sweden, 06 September, 2014 Co-located with ICFP 2014 http://www.icfpconference.org/icfp2014/ Important dates --------------- Proposal Deadline: Monday, 14 July, 2014 (anywhere on earth) Notification: 21 July 2014 Workshop: Saturday, 6 September 2014 The 6th Haskell Implementors' Workshop is to be held alongside ICFP 2014 this year in Gothenburg. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings; the workshop will be informal and interactive, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Attendance figures clearly reflect the growth of the Haskell user community and a constant interest in implementation aspects. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2014. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- At this stage we would like to invite proposals from potential speakers for talks and demonstrations. We are aiming for 20 minute talks with 10 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via EasyChair. The website is: https://www.easychair.org/conferences/?conf=hiw2014 If you don't have an account you can create one here: https://www.easychair.org/account/signup.cgi Because the submission is an abstract only, please click the "abstract only" button when you make your submission. There is no need to attach a separate file. We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers ---------- * Jost Berthold (co-chair) (University of Copenhagen) * Kevin Hammond (University of St.Andrews) * Gabriele Keller (University of New South Wales) * Paul Liu (Intel Labs) * Rita Loogen (Philipps-Universitat Marburg) * Geoffrey Mainland (co-chair) (Drexel University, Philadelphia) * Carter Schonwald (WellPosed Ltd) Contact ------- * hiw2014(a)easychair.org * Jost Berthold <berthold at di.ku.dk> * Geoffrey Mainland <mainland at cs.drexel.edu>

1 0

Interesting whoCreated output (stack trace related)
by Ömer Sinan Ağacan 25 Jun '14

25 Jun '14

Hi all, I'm running this program: {-# LANGUAGE DeriveDataTypeable, ScopedTypeVariables #-} import GHC.Stack import Control.Exception.Base import Data.Typeable data MyException = MyException deriving (Show, Typeable) instance Exception MyException err1 :: IO Integer err1 = {-# SCC error1 #-} err2 >>= return err2 :: IO Integer err2 = {-# SCC error2 #-} throw MyException main = print =<< whoCreated =<< catch err1 =<< (\(_ :: MyException) -> return (42 :: Integer)) I'd expect `whoCreated` to return something like [Main.CAF, Main.main, Main.main.\] but instead this is the output: ["Main.CAF (<entire-module>)","Main.err2 (ioerr.hs:14:1-43)","Main.error2 (ioerr.hs:14:27-43)","Main.main (ioerr.hs:16:1-103)","Main.main.\\ (ioerr.hs:16:81-102)"] This output has two things that look somewhat weird to me. First, I'd expect cost-centre stack to be restored when exception is catched and then program would produce shorter stack trace like I mentioned above.(without err1 or err2 calls) Second, when no cost-centre restoring is done, I'd expect stack trace to include `Main.err1` and `Main.error1`. So can anyone explain my why stack trace contains err2 calls but not err1 calls? I think none of error1 and error2 should have been included in the stack trace or both of them should have been included. Thanks. --- Ömer Sinan Ağacan http://osa1.net

2 1

RFC: Phabricator for patches and code review
by Austin Seipp 25 Jun '14

25 Jun '14

Hello all, Recently, while doing server maintenance, several of the administrators for Haskell.org set up an instance of Phabricator[1], located at https://phabricator.haskell.org For those who aren't aware, Phabricator (or "Phab") is a suite of tools for software development. Think of it like a polished, semi-private GitHub with a lot of applications and tools for all kinds of needs. We've been using it to do issue tracking for Haskell.org maintenance and like it a lot so far. One very nice aspect of Phabricator though is it has a very nice code review tool, called 'Differential', that is very useful. For people who have used a tool like Review Board, it's similar. Furthermore, it has a very convenient userland tool called 'Arcanist' which makes it easy for newcomers to post a review and get it merged when it's ready all from the command line. I'd like to see if people are interested in using Phab _strictly_ for code review of GHC patches. It is a dedicated tool specifically for this, and I think it works much better than Trac or inline GitHub comments. Also, Phab can also support post-commit reviews. So if I touch something in the runtime system and just push, perhaps Simon or Edward would like to look, and they can be alerted right when I do this, and then yell if I did something stupid. Before I go much further, I'd like to ask: is there *any* interest in this? Or are people satisifed with Trac? The primary motivations are roughly, in no particular order: 1) Code review is good for everyone, a good way for people to learn the code and ask questions, and useful to give feedback to newcomers. And even experienced GHC hackers can learn things from reading code, as we all do regularly, or find things that need cleanup. 2) Phabricator in particular makes it very easy to submit patches for review. To submit a patch, I just run the command 'arc diff' and it Does The Right Thing. It also makes it easy to ensure people are *alerted* when a patch might be relevant to them. 3) They can be uploaded and created from the command line, and merged easily afterwords the same way. This is particularly useful for newcomers, and for me. :) 4) Differential is dedicated to code review, and much better at it than just reading patches on Trac IMO. 5) It supports both post-commit code review, as well as pre-commit review. Post commit would be especially useful for us too, I think. Point #2 and #3 are mostly relevant for me, because I mostly handle incoming patches. But I think in general it would be nice, and make it a lot easier for newcomers to submit patches, and us to look over them. Here's an example of a Differential code review: https://phabricator.haskell.org/D4 This is a demo using my 'wip/ermsb' patch. You'll need to create an account to login, but it shouldn't be much trouble, you can login several ways. I'll fix the login requirement soon. Feel free to read the code, comment on it, and play around. It's more of a demonstration, but real code review would be welcome too. :) If people are interested in doing this, I can add notes to the wiki pages for newcomers, and I'll send another email about Phab so people can understand it a little better. But I want to ask first. There is an argument that our team is so small, code review has unnecessary burdens. But I think Phab could help a lot with tracking outside patches and getting good reviews for incoming patches, and it'll make it easier for newcomers. And experienced pros can probably learn a thing as well. Again, to be clear, I don't propose we migrate anything to Phabricator from, say, Trac. There's no real pressure to do so and it would be tons of work. I only propose we use it for code review, which is perfectly fine, and how other projects like LLVM do code review (they use Bugzilla). I also don't think the usage of Phabricator should be mandatory (unless we decide that later because we like it), but I would like to see people use it if possible. [1] http://phabricator.org -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

12 32

Re: validator1-linux-x86-head (Linux/x86 HEAD (Mateusz Kowalczyk)), build 18, Failure
by Herbert Valerio Riedel 25 Jun '14

25 Jun '14

Fyi, this also broke on the nightly PPA builds (which made me notice it): https://launchpadlibrarian.net/178475113/buildlog_ubuntu-precise-i386.ghc-h… Cheers, hvr On 2014-06-25 at 05:42:57 +0200, Builder wrote: > validator1-linux-x86-head (Linux/x86 HEAD (Mateusz Kowalczyk)), build 18 > > Build failed > Details: http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18.html > > git clone | Success > create mk/build.mk | Success > get subrepos | Success > repo versions | Success > booting | Success > configuring | Success > compiling | Failure: Just (ExitFailure 2) > > Build failed > Details: http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18.html [...] > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 7.9.20140624 for i386-unknown-linux): > RegAllocLinear.allocRegsAndSpill: no spill candidates > > allocating vreg: VirtualRegI n1Q6 > assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] > freeRegs: FreeRegs 4282318848 > initFreeRegs: FreeRegs 4282318861 > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 > libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed > Makefile:64: recipe for target 'all' failed > make: *** [all] Error 2

1 0

Re: [commit: ghc] master: Add more primops for atomic ops on byte arrays (d8abf85)
by Mateusz Kowalczyk 25 Jun '14

25 Jun '14

On 06/24/2014 07:47 PM, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/d8abf85f8ca176854e9d5d0b12371c4bc… > >> --------------------------------------------------------------- > > commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > Author: Johan Tibell <johan.tibell(a)gmail.com> > Date: Mon Jun 9 11:43:21 2014 +0200 > > Add more primops for atomic ops on byte arrays > > Summary: > Add more primops for atomic ops on byte arrays > > Adds the following primops: > > * atomicReadIntArray# > * atomicWriteIntArray# > * fetchSubIntArray# > * fetchOrIntArray# > * fetchXorIntArray# > * fetchAndIntArray# > > Makes these pre-existing out-of-line primops inline: > > * fetchAddIntArray# > * casIntArray# > > >> --------------------------------------------------------------- > > d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > compiler/cmm/CmmMachOp.hs | 19 ++ > compiler/cmm/CmmSink.hs | 4 + > compiler/cmm/PprC.hs | 4 + > compiler/codeGen/StgCmmPrim.hs | 94 +++++++ > compiler/llvmGen/Llvm/AbsSyn.hs | 7 + > compiler/llvmGen/Llvm/PpLlvm.hs | 18 +- > compiler/llvmGen/LlvmCodeGen/CodeGen.hs | 71 ++++-- > compiler/nativeGen/CPrim.hs | 50 +++- > compiler/nativeGen/PPC/CodeGen.hs | 4 + > compiler/nativeGen/SPARC/CodeGen.hs | 4 + > compiler/nativeGen/X86/CodeGen.hs | 92 +++++++ > compiler/nativeGen/X86/Instr.hs | 38 ++- > compiler/nativeGen/X86/Ppr.hs | 8 + > compiler/prelude/primops.txt.pp | 76 +++++- > includes/stg/MiscClosures.h | 1 - > libraries/ghc-prim/cbits/atomic.c | 280 +++++++++++++++++++++ > libraries/ghc-prim/ghc-prim.cabal | 1 + > rts/Linker.c | 1 - > rts/PrimOps.cmm | 12 - > testsuite/tests/concurrent/should_run/.gitignore | 1 + > .../tests/concurrent/should_run/AtomicPrimops.hs | 245 ++++++++++++++++++ > .../concurrent/should_run/AtomicPrimops.stdout | 7 + > testsuite/tests/concurrent/should_run/all.T | 1 + > 23 files changed, 984 insertions(+), 54 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > I think the above killed compilation on 32-bit boxes. See the usually-green boxes turn red at [1], specifically validator1-linux-x86-head, freebsd-i386-head and solaris-x86-head. The error looks like: "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140624 for i386-unknown-linux): RegAllocLinear.allocRegsAndSpill: no spill candidates allocating vreg: VirtualRegI n1Q6 assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] freeRegs: FreeRegs 4282318848 initFreeRegs: FreeRegs 4282318861 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 It'd be great if the devs would look at [1] every day or so. [1]: http://haskell.inf.elte.hu/builders/ -- Mateusz K.

2 2

RE: Associated type instances
by Simon Peyton Jones 24 Jun '14

24 Jun '14

I'm not sure when this "feature" was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? I think you are right. I think I added the new stuff in a fit of enthusiasm one day, a fit that I am now regretting! But I'm just checking that no one has meanwhile become addicted to it. Simon From: Manuel Chakravarty [mailto:mchakravarty@me.com] Sent: 24 June 2014 08:54 To: Simon Peyton Jones Cc: GHC List; ghc-devs(a)haskell.org Subject: Re: Associated type instances Simon, I'm not sure when this "feature" was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? Manuel Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>>: Friends I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack. Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#… All of this arose when thinking about fixing Trac #9063. I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). Does anyone object? Thanks Simon The issue Consider this: class C a where type T a b :: * instance C [x] where type T [x] b = x -> b That is just what you'd expect. But currently this is allowed too: instance C [x] where type T [x] Int = x -> Int type T [x] Bool = Bool -> x That is, GHC 7.8 allows many associated type instances, provided they don't overlap. But, oddly you can't further instantiate the instance pattern. This would make just as much sense, but isn't allowed: instance C [x] where type T [Int] b = b -> Int type T [Bool] b = Bool -> b Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like class D a where type S (b :: Bool) a :: * Now this would make some kind of sense: instance D [x] where type S True [x] = x -> x type S False [x] = x But for closed kinds, you really want a closed type family. So this would be better: instance D [x] where type S b [x] = SHelp x b type family SHelp x b where SHelp x True = x -> x SHelp x False = x So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange. All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it's a bit more complicated and indirect. My solution I propose to simplify substantially, as follows: * The "shared arguments" of an associated type are the argument positions that mention a type variable from the class header. So in class C above, the first argument position of T is "shared"; and in class D, the second argument position of S is shared. * A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have o type variables in the non-shared argument positions, and o an exact copy of the corresponding instance header type in the shared positions * For each associated type you can have o at most one default declaration in the class declaration o at most one type instance declaration in the class instance declaration _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs

2 2

CmmLint error when doing safe ccall from cmm
by Yuras Shumovich 24 Jun '14

24 Jun '14

Hello, I'm trying to do safe ccall from cmm (see below for the code). It seems to work, but -dcmm-lint is not satisfied: /opt/ghc-7.8.2/bin/ghc --make -o test hs.hs cmm.cmm c.c -dcmm-lint -fforce-recomp Cmm lint error: in basic block c4 in assignment: _c1::I32 = R1; Reg ty: I32 Rhs ty: I64 Program was: {offset c5: _c0::I64 = R1; _c2::I64 = c_test; _c3::I32 = %MO_UU_Conv_W64_W32(_c0::I64); I64[(young<c4> + 8)] = c4; foreign call "ccall" arg hints: [] result hints: [] (_c2::I64)(...) returns to c4 args: ([_c3::I32]) ress: ([_c1::I32])ret_args: 8ret_off: 8; c4: _c1::I32 = R1; R1 = %MO_SS_Conv_W32_W64(_c1::I32); call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; } <no location info>: Compilation had errors The same code without "safe" annotation passes cmm lint. Is it my error or ghc bug? How can I do safe ccall in cmm correctly? Here is the code: == c.c == #include <assert.h> int c_test(int i) { assert(i == 1); return 2; } == cmm.cmm #include "Cmm.h" cmm_test(W_ i) { CInt i1; (i1) = ccall c_test(W_TO_INT(i)) "safe"; return (TO_W_(i1)); } == hs.hs == {-# LANGUAGE GHCForeignImportPrim #-} {-# LANGUAGE ForeignFunctionInterface #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE UnliftedFFITypes #-} import GHC.Prim import GHC.Types import Control.Exception foreign import prim "cmm_test" test :: Int# -> Int# main :: IO () main = do let i1 = test 1# assert (I# i1 == 2) (return ()) Thanks, Yuras

3 4

GHC 7.10 plans
by Austin Seipp 24 Jun '14

24 Jun '14

Hello all, Let me redirect you to the following page, which lists out some of the plans for 7.10: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 The listing here is mostly based on what we had all put down during the May status reports. If you have something planned, please mention it with a paragraph on the page if you don't mind. Given the last release schedule, we'd like an RC by Christmas, and a release close to Feburary 2015. This will give the 7.10 branch a full year of changes. Do let me know if anything is unclear! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 2