- ghc-devs - Haskell.org

HP 2015.2.0.0 and GHC 7.10
by Mark Lentczner 28 Mar '15

28 Mar '15

I've gone ahead and built a very provisional, alpha version of 2015.2.0.0 using GHC 7.10 RC3. I bumped all the GHC libs to the versions in 7.10, and bumped all the Platform libs to the latest versions I could find on Hackage. There were a few issues: - *old-locale and old-time* - no longer part of GHC, but cabal-install, cgi & HTTP need them - and they are part of the platform - so included now as added packages. Not sure this is a great idea, since they are now very deprecated... but until cabal-install, cgi, & HTTP update, not sure what else to do. - *tf-random* - is now required by alex and QuickCheck - seems a shame to add this, as now we're going to have two random packages - *network-uri *- was split out of network, and needed by cabal-install, cgi, & HTTP. I suppose we should include it, as it was functionality and API that was part of the platform - *exceptions* & *multipart* - needed by cgi - is exceptions now subsumed by something in transformers? and... multipart? maybe time to drop cgi? We didn't have it last time anyway as it wouldn't compile! - *scientific* - needed by attoparsec - debated in detail last time ... and we're still here! The Platform is significantly larger now: On OS X it has gone from 316M to 499M! Most of this is due to new OpenGL libs which are now huge (went from 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the whole installed magilla is 1.5G! Even the compressed installer is now 250M! If you want to poke at it, the source is in the pre-release branch at GitHub <https://github.com/haskell/haskell-platform/tree/pre-release>, and the OS X builds are at my usual platform staging area: Index of /mark/platform <http://www.ozonehouse.com/mark/platform/> Remember, it already includes GHC, so no need to download the GHC binary for OS X that is there, too. I'll try to get a generic linux build up soonish... but my VM now runs out of memory trying to build OpenGL - and adding more only makes my machine thrash to death! - Mark

11 23

Re: [commit: ghc] master: Rename driver phases C(obj)cpp to C(obj)cplusplus (abde5da)
by Karel Gardas 27 Mar '15

27 Mar '15

Hi Thomas, Cplusplus is quite long identifier, bad for eyes. Usually in C++ community if you can't use cpp then you use cxx. It's shorter and clear even when reading fast, don't you think? Karel PS: of course even before cxx it was CC, but I think this does not have any advantage over cxx in this context... On 03/27/15 09:38 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/abde5da4dee5f3b83264f8471e458b20d… > >> --------------------------------------------------------------- > > commit abde5da4dee5f3b83264f8471e458b20d04f8b29 > Author: Thomas Miedema<thomasmiedema(a)gmail.com> > Date: Fri Mar 27 21:37:49 2015 +0100 > > Rename driver phases C(obj)cpp to C(obj)cplusplus > > Before: > Cpp = Pre-process C > Ccpp = Compile C++ > Cobjcpp = Compile Objective-C++ > CmmCpp = Pre-process Cmm > > Quite confusing! This commit renames `Ccpp` to `Ccplusplus`, and > `Cobjcpp` to `Cobjcplusplus`. The two letters `p-p` keep standing for > `pre-processing` throughout the compiler. > > Reviewed By: austin > > Differential Revision: https://phabricator.haskell.org/D756 > > >> --------------------------------------------------------------- > > abde5da4dee5f3b83264f8471e458b20d04f8b29 > compiler/main/DriverPhases.hs | 32 ++++++++++++++++---------------- > compiler/main/DriverPipeline.hs | 9 +++++---- > ghc/Main.hs | 2 +- > 3 files changed, 22 insertions(+), 21 deletions(-) > > diff --git a/compiler/main/DriverPhases.hs b/compiler/main/DriverPhases.hs > index 2433f6d..2d7d904 100644 > --- a/compiler/main/DriverPhases.hs > +++ b/compiler/main/DriverPhases.hs > @@ -111,10 +111,10 @@ data Phase > | Cpp HscSource > | HsPp HscSource > | Hsc HscSource > - | Ccpp > - | Cc > - | Cobjc > - | Cobjcpp > + | Ccplusplus -- Compile C++ > + | Cc -- Compile C > + | Cobjc -- Compile Objective-C > + | Cobjcplusplus -- Compile Objective-C++ > | HCc -- Haskellised C (as opposed to vanilla C) compilation > | Splitter -- Assembly file splitter (part of '-split-objs') > | SplitAs -- Assembler for split assembly files (part of '-split-objs') > @@ -148,10 +148,8 @@ eqPhase (Unlit _) (Unlit _) = True > eqPhase (Cpp _) (Cpp _) = True > eqPhase (HsPp _) (HsPp _) = True > eqPhase (Hsc _) (Hsc _) = True > -eqPhase Ccpp Ccpp = True > eqPhase Cc Cc = True > eqPhase Cobjc Cobjc = True > -eqPhase Cobjcpp Cobjcpp = True > eqPhase HCc HCc = True > eqPhase Splitter Splitter = True > eqPhase SplitAs SplitAs = True > @@ -163,7 +161,9 @@ eqPhase CmmCpp CmmCpp = True > eqPhase Cmm Cmm = True > eqPhase MergeStub MergeStub = True > eqPhase StopLn StopLn = True > -eqPhase _ _ = False > +eqPhase Ccplusplus Ccplusplus = True > +eqPhase Cobjcplusplus Cobjcplusplus = True > +eqPhase _ _ = False > > -- Partial ordering on phases: we want to know which phases will occur before > -- which others. This is used for sanity checking, to ensure that the > @@ -189,10 +189,10 @@ nextPhase dflags p > LlvmMangle -> As False > SplitAs -> MergeStub > As _ -> MergeStub > - Ccpp -> As False > + Ccplusplus -> As False > Cc -> As False > Cobjc -> As False > - Cobjcpp -> As False > + Cobjcplusplus -> As False > CmmCpp -> Cmm > Cmm -> maybeHCc > HCc -> As False > @@ -215,13 +215,13 @@ startPhase "hscpp" = HsPp HsSrcFile > startPhase "hspp" = Hsc HsSrcFile > startPhase "hc" = HCc > startPhase "c" = Cc > -startPhase "cpp" = Ccpp > +startPhase "cpp" = Ccplusplus > startPhase "C" = Cc > startPhase "m" = Cobjc > -startPhase "M" = Cobjcpp > -startPhase "mm" = Cobjcpp > -startPhase "cc" = Ccpp > -startPhase "cxx" = Ccpp > +startPhase "M" = Cobjcplusplus > +startPhase "mm" = Cobjcplusplus > +startPhase "cc" = Ccplusplus > +startPhase "cxx" = Ccplusplus > startPhase "split_s" = Splitter > startPhase "s" = As False > startPhase "S" = As True > @@ -247,9 +247,9 @@ phaseInputExt (Hsc _) = "hspp" -- intermediate only > -- because runPipeline uses the StopBefore phase to pick the > -- output filename. That could be fixed, but watch out. > phaseInputExt HCc = "hc" > -phaseInputExt Ccpp = "cpp" > +phaseInputExt Ccplusplus = "cpp" > phaseInputExt Cobjc = "m" > -phaseInputExt Cobjcpp = "mm" > +phaseInputExt Cobjcplusplus = "mm" > phaseInputExt Cc = "c" > phaseInputExt Splitter = "split_s" > phaseInputExt (As True) = "S" > diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs > index 24df3a2..845cc95 100644 > --- a/compiler/main/DriverPipeline.hs > +++ b/compiler/main/DriverPipeline.hs > @@ -1068,7 +1068,7 @@ runPhase (RealPhase Cmm) input_fn dflags > -- way too many hacks, and I can't say I've ever used it anyway. > > runPhase (RealPhase cc_phase) input_fn dflags > - | any (cc_phase `eqPhase`) [Cc, Ccpp, HCc, Cobjc, Cobjcpp] > + | any (cc_phase `eqPhase`) [Cc, Ccplusplus, HCc, Cobjc, Cobjcplusplus] > = do > let platform = targetPlatform dflags > hcc = cc_phase `eqPhase` HCc > @@ -1137,9 +1137,9 @@ runPhase (RealPhase cc_phase) input_fn dflags > > ghcVersionH<- liftIO $ getGhcVersionPathName dflags > > - let gcc_lang_opt | cc_phase `eqPhase` Ccpp = "c++" > + let gcc_lang_opt | cc_phase `eqPhase` Ccplusplus = "c++" > | cc_phase `eqPhase` Cobjc = "objective-c" > - | cc_phase `eqPhase` Cobjcpp = "objective-c++" > + | cc_phase `eqPhase` Cobjcplusplus = "objective-c++" > | otherwise = "c" > liftIO $ SysTools.runCc dflags ( > -- force the C compiler to interpret this file as C when > @@ -1176,7 +1176,8 @@ runPhase (RealPhase cc_phase) input_fn dflags > else []) > > -- GCC 4.6+ doesn't like -Wimplicit when compiling C++. > - ++ (if (cc_phase /= Ccpp&& cc_phase /= Cobjcpp) > + ++ (if (cc_phase /= Ccplusplus&& > + cc_phase /= Cobjcplusplus) > then ["-Wimplicit"] > else []) > > diff --git a/ghc/Main.hs b/ghc/Main.hs > index da95ebf..a95382f 100644 > --- a/ghc/Main.hs > +++ b/ghc/Main.hs > @@ -653,7 +653,7 @@ doMake srcs = do > haskellish (f,Nothing) = > looksLikeModuleName f || isHaskellUserSrcFilename f || '.' `notElem` f > haskellish (_,Just phase) = > - phase `notElem` [ As True, As False, Cc, Cobjc, Cobjcpp, CmmCpp, Cmm > + phase `notElem` [ As True, As False, Cc, Cobjc, Cobjcplusplus, CmmCpp, Cmm > , StopLn] > > hsc_env<- GHC.getSession > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits >

1 0

ANNOUNCE: GHC version 7.10.1
by Austin Seipp 27 Mar '15

27 Mar '15

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 7.10.1 ============================================================== The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Several new language features and changes have been implemented: - Applicative is now a superclass of Monad and in the Prelude. - Many prelude combinators have been generalized - Static pointers * GHC now has preliminary and experimental support for DWARF based debugging. * `integer-gmp` has been completely rewritten. * Type-checking plugins can now extend the type checker. * Support for partial type signatures * Many bugfixes and other performance improvements. * Preliminary support for 'backpack' features like signatures. * Typeable is now generated by default for all data types automatically. We've also fixed a handful of issues reported since RC3: - A bug in the call arity analysis that would result in invalid core was fixed (#10176) - A bug in the Win32 package causing it to fail to load was fixed (#10165) - ghc-prim has (correctly) been bumped to version 0.4.0.0, to comply with the PVP. - Several libraries have been bumped to their latest available versions after coordination. The full release notes are here: https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/release-7-1… How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: https://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://ghc.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: https://ghc.haskell.org/trac/ghc/wiki/Platforms https://ghc.haskell.org/trac/ghc/wiki/CodeOwners Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.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: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://www.haskell.org/mailman/listinfo/glasgow-haskell-users https://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 https://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug Hashes & Signatures ~~~~~~~~~~~~~~~~~ On https://downloads.haskell.org/~ghc/7.10.1/ you will find a signed copy of the SHA256 hashes for the tarballs, using my GPG key (0F8F 3AA9 9235 C704 ADA0 B419 B942 AEE5 3B58 D86F). -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 2

wither the Platform
by Mark Lentczner 27 Mar '15

27 Mar '15

I'm wondering how we are all feeling about the platform these days.... I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second option) pretty much steers folks away from it. Of the per-OS download pages, only the Windows version even mentions it. Does this mean that we don't want to consider continuing with it? It is a lot of community effort to put out a Platform release - we shouldn't do it if we don't really want it. That said, I note that the other ways to "officially get" Haskell look, to my eye, very ad hoc. Many of the options involve multiple steps, and exactly what one is getting isn't clear. It hardly looks like there is now an "official, correct" way to setup Haskell. The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new features and development have clearly changed the landscape for use to reconsider what to do. I don't think the status quo for the Platform is now viable - mostly as evidenced by waning interest in maintaining it. I offer several ways we could proceed: *1) Abandon the Platform.* GHC is release in source and binary form. Other package various installers, with more or less things, for various OSes. *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell. *3) Re-conceive the Platform.* Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction. Thoughts? — Mark

24 59

RE: GHC 7.10 Regression(?) regarding Unicode subscript characters in identifiers
by Yongqian Li 27 Mar '15

27 Mar '15

Is this a bug, and if so, will it be fixed before the final release? We currently use subscript characters in our identifiers and would like to see the old behavior restored...

2 2

Fwd: [hackage-server] Duplicate anchors in source code (#319)
by Eric Crockett 27 Mar '15

27 Mar '15

I reported a bug in HsColour ( https://github.com/haskell/hackage-server/issues/319#issuecomment-76088047) which has been fixed in a new version. The HSColour dev thought it might be useful to mention this new version of HsColour to the GHC devs so that documentation for 7.10 will be marginally easier to reference. -Eric

1 0

quick report using GHC 7.10 RC3
by Mark Lentczner 26 Mar '15

26 Mar '15

I built up a provisional HP 2015.2.0.0 based on GHC 7.10 RC3, and then when testing it, built my medium-ish project Plush with it all. This is my first brush with 7.10 and the new base libs, Applicative, FTP and all. For the most part, it all worked, but here are some observations: *1. Cabal-1.22.1.2 isn't on Hackage* Boot strapping HP now needs to bootstrap cabal-install in order to be able to build with 7.10. My fancy-pants build system for HP doesn't do that (yet), so I did it by hand. Only hitch: Cabal 1.22.1.2 isn't on hackage, so I had to build with 1.22.1.1 - so the bootstrap wasn't perfect, but good enough to work. *2. Still need old-local and old-time* Because....wait for it... cabal-install needs them! So do cgi and HTTP packages. *3. Slower compilation* The platform used to take about 20min. to compile. Now it takes a full hour. Did GHC really slow down that much? The newer OpenGL and OpenGLRaw packages are significantly larger and slower, and that might account for about half the extra time... but still GHC seems much slower. *4. GHC is a disk monster* Now weighing in at 900+MB! That is 100MB over 7.8! *5. Warnings Galore* Of course most of the packages compile with tons of warnings. I mean tons! Looking at my own packages, since I usually compile -Wall, I will need tons of work to remove these. The saddness is that if I want my package to continue to work on 7.8 I'll have to put in tons of CPP statements. *6. Bit by additions to the Prelude* In particular, Word, since I had a data type named that. (It was in a grammar for the shell, and since Data.Word was no where near this, I claim it was a reasonable choice of name.) I had to add tons of import Prelude hiding (Word) statements. Adding common words as new exports from the Prelude is a real pain! *7. Cabal incompatible API change* In particular, the api that a custom Setup.hs uses. Distribution.Simple.UserHooks changed the type of a hook. It should not, it should have added another to do what it wanted. The poblem is you can't use CPP in Setup.hs. And so now anyone using the testHook hook is in a pickle: Your Setup.hs can't work in both 7.10 and 7.8! *8. Haddock messaging* What has gotten into Haddock? There is so much terminal output now - I just have to ignore it all. It spews more than the compiler does. *9. Library divergence* We have random... and now we'll have to have tf-random, too, because alex and QuickCheck both need it. So now we'll have two random libraries. Couldn't we have folded tf-random into random? On a similar front, we've got attoparsec, pulling in scientific. Couldn't that have gone somewhere? I realize that the trend is for many small minimal libs... but for the core that is going to all be there always anyway - and more closed set works better I think. Summary: 1, 2 & 8 are minor, 3 & 4 are sad. 5 ~ 7 will make the job of anyone who wants their code to work with even one prior major GHC rev. hard, and ugly. 9 is what makes me worry most... — Mark

4 3

Re: wither the Platform
by Brandon Allbery 25 Mar '15

25 Mar '15

On Wed, Mar 25, 2015 at 10:47 AM, Mike Meyer <mwm(a)mired.org> wrote: > The words "Core Platform" makes me think there ought to be a "non-Core" > platform. This would actually match the Clojure model, where there's "the > stuff that's part of Clojure", "a set of recommended libraries", and "the > library archive anyone can put stuff in". If the platform is going to > undergo serious shrinkage, maybe the things that get pushed out - like the > OpenGL stuff - should be considered for that middle category? Less rigorous > testing, not bundled with the platform, but unlike all of hackage, an > effort is made to insure that there's a repository where it builds on top > of the "core platform"? > That's pretty much what I'm thinking of, yes. Not sure about "less rigorous testing" --- but "doesn't have to release at the same time" is a possibility. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

RE: wither the Platform
by Simon Peyton Jones 25 Mar '15

25 Mar '15

Very good! This one is perhaps a missing piece, if you are saying that a Windows user cannot use GHC without MSYS: • On Windows, it does not provide a complete environment (missing MSYS). On the other hand these three are examples of HP getting in the way: • By placing a large number of packages in the global package database, Haskell Platform installations are more easily corrupted. • The choice of package versions conflicts with the needs of many commonly used packages. • Some of the package versions included with the platform have known and severe bugs, and cannot be reliably upgraded. My question was: can they be fixed so that HP does not get in the way? E.g. if we solve the multiple-versions-of-packages problem with Cabal (which Duncan in a separate thread says we can), then that would solve the first two; and for the third, I guess the solution is to release a new version of HP. Simon From: Mike Meyer [mailto:mwm@mired.org] Sent: 25 March 2015 09:30 To: Simon Peyton Jones Cc: Mark Lentczner; Gershom B; Manuel M T Chakravarty; haskell-platform(a)projects.haskell.org; haskell-infrastructure(a)community.galois.com; Duncan Coutts; ghc-devs(a)haskell.org; Haskell Libraries Subject: Re: wither the Platform On Wed, Mar 25, 2015 at 4:09 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: So that was the plan. I still think it’s a good plan. But it clearly is not working well, and I’m hazy about why. Possible reasons: Possibly relevant is the stackage commentary on HP at http://www.stackage.org/install#why-not-haskell-platform: • On Windows, it does not provide a complete environment (missing MSYS). • By placing a large number of packages in the global package database, Haskell Platform installations are more easily corrupted. • The choice of package versions conflicts with the needs of many commonly used packages. • Some of the package versions included with the platform have known and severe bugs, and cannot be reliably upgraded.

3 2

Re: wither the Platform
by Michael Snoyman 25 Mar '15

25 Mar '15

Thanks for linking to that Mike, I'd actually forgotten that I'd written that :). Those are all very concrete issues people run into with the platform regularly, but I'd like to point out a meta issue: the platform tries to do too much, and in a non-composable manner. As I pointed out previously, it's providing a tools installer, choosing blessed libraries, pegging certain library versions, and selecting a distribution manner for those libraries. Even if the other issues were all addressed, I still believe the current trajectory of the platform is problematic, because it is necessarily removing choice. When Mark, Duncan and I were discussing GPS Haskell at ICFP, a big goal (in my mind at least) was to allow individual tools to target individual goals. I don't expect every use case to be served by a curated package set (like LTS), so making that an optional feature of tooling makes sense. Similarly, almost all users (excepting some people playing with bleeding-edge GHC) will benefit from having an easy-to-use GHC+cabal-install installation, but a large set of users (specifically Hackage package authors) need a way to compile against different versions than the HP-blessed ones for testing purposes. And now a completely separate point: the current functioning of the HP process seems very much at odds with the way people actually write and release packages. Some examples: * Having to go through an extra step of requesting that a package version is bumped is tedious, and resulted in a buggy attoparsec being released in HP * Requiring package authors to endure long debate periods before the package is accepted scares people off from wanting to participate * A number of months back, the HP was used as a vehicle to push the PVP agenda as well, which completely alienated some people from wanting to participate (ironically, the package being pushed instead was not PVP compliant either, go figure). The practical result to that is we currently have no plans at all for getting TLS/HTTPS support into the platform, and everyone's tooling (cabal-install) is far less secure than it should be. * Authors want the freedom to quickly release new versions to their users, especially for bug fixes. While in theory the HP is set up to do bugfix releases, in practice this has never happened. In that sense, it is often preferable from the eyes of a package author *not* to have his/her package in the HP, as then users are better served As long as I'm writing a long email, I want to point out one other thing. A lot of the points being raised in this thread are discussing an idealized view of what the HP could become. I'm fully in favor of improving it (like I said, that's why I tried working with Mark on GPS Haskell and integrating with Stackage). However, we need to accept the reality of the situation today. Could the windows HP installer be improved like MinGHC to include MSYS? Absolutely, and I hope it happens. Could we improve Cabal and work around the global package database issues we've been mentioning? Yes, and I support such moves. But we need to acknowledge current deficiencies, and plot out a course of action to solve them. And given that this thread started by lamenting how much effort the platform currently takes to maintain, I'm concerned about those improvements actually occurring. On Wed, Mar 25, 2015 at 11:30 AM Mike Meyer <mwm(a)mired.org> wrote: > On Wed, Mar 25, 2015 at 4:09 AM, Simon Peyton Jones <simonpj(a)microsoft.com > > wrote: > >> So that was the plan. I still think it’s a good plan. But it clearly >> is not working well, and I’m hazy about why. Possible reasons: >> > > Possibly relevant is the stackage commentary on HP at > http://www.stackage.org/install#why-not-haskell-platform: > > • On Windows, it does not provide a complete environment (missing MSYS). > • By placing a large number of packages in the global package database, > Haskell Platform installations are more easily corrupted. > • The choice of package versions conflicts with the needs of many commonly > used packages. > • Some of the package versions included with the platform have known and > severe bugs, and cannot be reliably upgraded. > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

1 0