- Glasgow-haskell-users

heads up: GHC gets a new constraint solver (again)
by Dimitrios Vytiniotis 16 Nov '11

16 Nov '11

Friends, After a very busy period of hard work with Simon, we've re-engineered GHCs constraint solver and I just pushed a big patch on master along with modifications in the testsuite. The new constraint solver is based on the existing in its core ideas but is shorter, much cuter, and for many programs much faster (for others performance is roughly the same) If you had a program that was taking very long to compile in the past, we'd be very interested to see how this reengineered constraint solver performs on it. Same if you spot problems or notable regressions. Thanks, enjoy! Dimitrios > -----Original Message----- > From: cvs-ghc-bounces(a)haskell.org [mailto:cvs-ghc-bounces@haskell.org] > On Behalf Of dimitris(a)microsoft.com > Sent: 16 November 2011 17:42 > To: cvs-ghc(a)haskell.org > Subject: [commit: ghc] master: GHC gets a new constraint solver. More > efficient and smaller in size. (0007c0e) > > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : master > > http://hackage.haskell.org/trac/ghc/changeset/0007c0ec9c0de68e3a348b8c4 > 112ac48fd861b1e > > >--------------------------------------------------------------- > > commit 0007c0ec9c0de68e3a348b8c4112ac48fd861b1e > Author: Dimitrios Vytiniotis <dimitris(a)microsoft.com> > Date: Wed Nov 16 16:12:48 2011 +0000 > > GHC gets a new constraint solver. More efficient and smaller in size. > > compiler/basicTypes/DataCon.lhs | 9 +- > compiler/basicTypes/MkId.lhs | 10 +- > compiler/codeGen/CgCase.lhs | 18 +- > compiler/coreSyn/CoreLint.lhs | 78 +- > compiler/coreSyn/CoreSubst.lhs | 15 +- > compiler/coreSyn/CoreUtils.lhs | 27 +- > compiler/deSugar/Desugar.lhs | 7 +- > compiler/deSugar/DsBinds.lhs | 29 +- > compiler/deSugar/DsCCall.lhs | 4 +- > compiler/deSugar/DsUtils.lhs | 2 +- > compiler/hsSyn/HsBinds.lhs | 17 +- > compiler/prelude/TysPrim.lhs | 12 +- > compiler/simplCore/CoreMonad.lhs | 9 +- > compiler/simplCore/OccurAnal.lhs | 4 +- > compiler/simplCore/SimplUtils.lhs | 2 +- > compiler/simplCore/Simplify.lhs | 25 +- > compiler/typecheck/Inst.lhs | 71 +- > compiler/typecheck/TcCanonical.lhs | 1361 ++++++++++++++-------- > compiler/typecheck/TcErrors.lhs | 48 +- > compiler/typecheck/TcHsSyn.lhs | 12 +- > compiler/typecheck/TcInteract.lhs | 1664 +++++++++----------------- > compiler/typecheck/TcMType.lhs | 40 +- > compiler/typecheck/TcRnDriver.lhs | 15 +- > compiler/typecheck/TcRnMonad.lhs | 9 + > compiler/typecheck/TcRnTypes.lhs | 194 +++- > compiler/typecheck/TcSMonad.lhs | 1211 ++++++++++++++------ > compiler/typecheck/TcSimplify.lhs | 522 +++++---- > compiler/typecheck/TcSplice.lhs | 2 +- > compiler/typecheck/TcType.lhs | 41 +- > compiler/types/Coercion.lhs | 99 +- > compiler/types/FunDeps.lhs | 10 +- > compiler/types/Type.lhs | 12 +- > compiler/types/TypeRep.lhs | 21 +- > compiler/vectorise/Vectorise/Type/PRepr.hs | 4 +- > compiler/vectorise/Vectorise/Utils/PADict.hs | 2 +- > 35 files changed, 3205 insertions(+), 2401 deletions(-) > > > Diff suppressed because of size. To see it, use: > > git show 0007c0ec9c0de68e3a348b8c4112ac48fd861b1e > > _______________________________________________ > Cvs-ghc mailing list > Cvs-ghc(a)haskell.org > http://www.haskell.org/mailman/listinfo/cvs-ghc

2 1

Way to expose BLACKHOLES through an API?
by Ryan Newton 16 Nov '11

16 Nov '11

Hi GHC users, When implementing certain concurrent systems-level software in Haskell it is good to be aware of all potentially blocking operations. Presently, blocking on an MVar is explicit (it only happens when you do a takeMVar), but blocking on a BLACKHOLE is implicit and can potentially happen anywhere. If there are known thunks where we, the programmers, know that contention might occur, would it be possible to create a variant of "Control.Monad.Evaluate" that allows us to construct non-blocking software: evaluate :: a -> IO a evaluateNonblocking :: a -> IO (Maybe a) It would simply return Nothing if the value is BLACKHOLE'd. Of course it may be helpful to also distinguish the evaluated and unevaluated states. Further, the above simple version allows data-races (it may become blackhole'd right after we evaluate). An extreme version would actively blackhole it to "lock" the thunk... but maybe that's overkill and there are some other good ideas out there. A mechanism like the proposed should, for example, allow us to consume just as much of a lazy Bytestring as has already been computed by a producer, WITHOUT blocking and waiting on that producer thread, or migrating the producer computation over to our own thread (blowing its cache). Thanks, -Ryan

4 4

encoding and paths, again
by Ganesh Sittampalam 16 Nov '11

16 Nov '11

Hi, I'm not entirely clear on what the overall situation will be once Simon M's patch to add .ByteString versions to unix is added in GHC 7.4.1. In particular the original problem darcs ran into was with getDirectoryContents in the directory package. That in turn uses the unix package on Posix systems and another code path based on Win32 on Windows (http://hackage.haskell.org/packages/archive/directory/1.1.0.1/doc/html/src/…) So a couple of questions: (1) Does Win32 need similar additions? I can't spot any substantial changes to it for Max's PEP383, but I'm not sure if any lower-level library changes might have affected it. (2) What's the recommended way of doing the equivalent of getDirectoryContents for RawFilePath? Do we also need to add "raw" versins to the directory package? Cheers, Ganesh

2 3

Why not allow empty record updates?
by Herbert Valerio Riedel 16 Nov '11

16 Nov '11

Hello GHC HQ, I have been toying with phantom types in combination with "polymorphic" record-updates (which is a great feature imho), but stumbled over a limitation: GHC doesn't allow empty record updates (see toy example below), and I couldn't find a GHC language extension to relax this constraint. In the toy-example below it was easy to workaround by performing a dummy record update, but for more advanced uses workarounds becomes a bit more annoying. Is there a particular reason why empty record updates are disallowed by the Haskell Report? Would it be sensible, to allow empty record updates as a GHC language extension? hvr. ------------------------------------------------------- -- empty types for tagging data Clean data Dirty data Foo a = Foo { fa :: Int, fb :: String } data Bar a = Bar { ba :: Int, bb :: Foo a } markDirtyFoo :: Foo Clean -> Foo Dirty markDirtyFoo foo = foo { } -- rejected with "Empty record update" error markDirtyFoo foo = foo { fa = fa foo } -- workaround: dummy update markDirtyBar :: Bar Clean -> Bar Dirty markDirtyBar bar = bar { bb = markDirtyFoo (bb bar) } -- works

8 12

instance union proposal
by Serge D. Mechveliani 15 Nov '11

15 Nov '11

Dear Haskell implementors, I suggest the following small extension to the instance declaration in the language. So far -- for Haskell + glasgow-ext. I think that they are easy to implement. This is the "instance union" proposal. It is needed to write shorter several `old' instance declarations. This will make programs easier to read. It suggests the so-called inherited decl and, more general, union decl. Inherited instance decl proposal -------------------------------- Union several instance declarations with the same condition part and such that among the conclusion classes there exists some which inherits all others. Example 1. My program uses the class tower Field a Picture 1. | ERing | CRing a | Ring a / \ AddGroup a MulSemigroup a | | AddSemigroup a | \ / Set a -- "|" means that the upper inherits from the lower. Now, by the application meaning, I need to write instance (Show a, CRing a) => CRing (Pol a) where <implement operations of Set> <implement operations of AddGroup> ... <implement operations of CRing> >From the class decls it is clear to the compiler that CRing inherits all that is lower on the picture. Therefore, the conditional `instance (Show a, CRing a) =>' and 'where' is written only once. In the existing language, I need to write this conditional 6 times. Union instance decl proposal ---------------------------- It is a generalization for inhereted decl. instances (cond_1, ..., cond_n) -- of the type parameters a_1 ... a_m => <typeTuple> (<params>) has {<conclInstList>} where <implement operations for each member of <conclInstList>. It differs from the old instance declaration in that 1) it unions several old declarations having the same conditional part, 2) each member of <conclInstList> can be conditional, 3) in <conclInstList> it can be skipped any instance which is inherited by some other member in this list. <params> is a subset of {a_1 ... a_m}, <typeTuple> (<params>) is a tuple of type expressions, as in old declaration, for example, `(a, b)', `Vector a', `[(a,b), Vector a]'. It is the argument for the conclusion instance declarations. <conclInstList> is a list of inst-members separated by comma. Each member of <conclInstList> is either an old conclusion instance declaration or a conditional declaration. Example. In the situtation of Picture 1, I need to declare instance (Show a, CRing a) => (Pol a) has { CRing, if (has a Field) then ERing } where <define operations for Set (Pol a)> <define operations for AddSemigroup (Pol a)> ... <define operations for CRing (Polynomial a)> <define operations for ERing (Pol a)> -- this part has the -- additional condition (Field a) Its meaning is that the complier extends this into several `old' instance declarations: instance (Show a, CRing a) => Set (Pol a) where <define operations for Set (Pol a)> ... instance (Show a, CRing a) => CRing (Pol a) where <define operations for Set (Pol a)> instance (Show a, Field a) => ERing (Pol a) where <define operations for ERing (Pol a)> (in the last decl `Field a' has been moved to LHS). In this example <typeTuple> === (Pol a). For bi-parametric instances, the concusion part may be, for example => [a, Pol a] has {Foo1, Foo2} ... This means the two instance assertions Foo1 a (Pol a), Foo a (Pol a), and `[a, Pol a]' is the agrument tuple for the instance conclusions. This is a draft proposal. If the idea is accepted, some generalizations and corrections are expected. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

source/build separation
by Rustom Mody 15 Nov '11

15 Nov '11

I am building ghc from source. The building page http://hackage.haskell.org/trac/ghc/wiki/Building/Using#Sourcetreesandbuild… mentions lndir for separating source trees from build trees. Given how much detail is generally given for individual commands eg http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources maybe it would be nice to have a (typical?) lndir command also given? Also there is a mention about using a local git clone here http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources Arent these two alternative ways with similar intent - viz. keeping source pristine and separating build 'messiness'? Or do people use both git (local) clone + lndir? If so why? Rusi [ghc noob here: Please tell me if this is the wrong list to ask this kind of question :-) ]

3 2

ANNOUNCE: GHC version 7.2.2
by Ian Lynagh 14 Nov '11

14 Nov '11

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.2.2 ============================================================= The GHC Team is pleased to announce a new bugfix release of GHC, 7.2.2. The 7.2 branch is intended to be more of a "technology preview" than normal GHC stable branches; in particular, it supports a significantly improved version of DPH, as well as new features such as compiler plugins and "safe Haskell". The design of these new features may evolve as we get more experience with them. The changes in this release, relative to 7.2.1, are: * All packages are now trusted by default. If you wish to make use of Safe Haskell, you will need to manually untrust packages that you do not wish to trust. * An optimiser bug which can cause segfaults has been fixed. * A native code generator bug which can cause segfaults on x86 and amd64 has been fixed. * A race condition in the runtime system that can cause segfaults has been fixed. * Exception handlers are now run in the mask state, rather than the maskUninterruptible state. Fixes a bug that could cause the GHCi debugger to hang amongst other things. * The shutdownHaskellAndExit function now immediately exits, even if hs_init has been called multiple times. * A bug arising when using type signature declarations in Template Haskell splices has been fixed. * A bug arising when using class instances in Template Haskell splices has been fixed. * Incorrectly encoded text at the end of a file is now handled correctly. * The base package is now version 4.4.1.0 (was 4.4.0.0). * Haddock is now version 2.9.4. 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. 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

3 4

Re: instance union decl
by Serge D. Mechveliani 12 Nov '11

12 Nov '11

The general idea of my recent instance union proposal is that for a single polymorphic type T, sometimes it is natural to define several instances by a single `instances' declaration. ------ Sergei

1 0

GHC 7.2.2 RC 1
by Ian Lynagh 12 Nov '11

12 Nov '11

We are pleased to announce the first release candidate for GHC 7.2.2: http://www.haskell.org/ghc/dist/7.2.2-rc1/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. 7.2.2 will be a minimal bugfix release, fixing only bugs that cannot be worked around. Please let us know if you find any showstoppers. Thanks Ian, on behalf of the GHC team

8 11

sendWakeup bug #5553
by Bit Connor 11 Nov '11

11 Nov '11

Here's a bug I submitted 4 weeks ago, and there hasn't been much activity or responses regarding it since then: http://hackage.haskell.org/trac/ghc/ticket/5553 It causes the error message: ghc_sendWakeup_bug: sendWakeup: invalid argument (Bad file descriptor) It would be great if someone could take a look at this, or at least verify that you are able to reproduce the error using the test code provided in the bug report. Thanks, Bit

2 1