May 2013 - Libraries - Haskell.org

HP 2013.2 home stretch, RC2 installers
by Mark Lentczner 11 May '13

11 May '13

*We are in the home stretch for Haskell Platform 2013.2!* The Mac OS X RC2 installers are up: Haskell Platform 2013.2.0.0 32bit rc2.signed.pkg<http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202013.2.0.0%203…> Haskell Platform 2013.2.0.0 64bit rc2.signed.pkg<http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202013.2.0.0%206…> Only real difference in these from RC1 is packaging: the Cabal doc is now included. There is no update to source tarball RC1, which is still there too. I expect these to be renamed the official release within a week. *Packagers:* Please produce Release Candidates. The package version list shouldn't change, unless any of you find an issue. - Mark

1 0

Control.Monad proposal: Add whenJust
by Niklas Hambüchen 10 May '13

10 May '13

I would like to propose the addition of whenJust :: Monad m => Maybe a -> (a -> m ()) -> m () whenJust (Just x) f = f x whenJust _ _ = return () to Control.Monad, in the section "Conditional execution of monadic expressions" next to guard :: MonadPlus m => Bool -> m () when :: Monad m => Bool -> m () -> m () unless :: Monad m => Bool -> m () -> m () Why? It would allow us to write more readable code and fit well into the group of similar functions of this style. Compare mUser <- lookupUser whenJust mUser email or whenJust mUser $ \user -> do putStrLn "Mailing!" email user with some currently available alternatives: case mUser of Just user -> do putStrLn "Mailing!" email user Nothing -> return () (Default base case clutter.) import Data.Foldable forM_ mUser $ \user -> do putStrLn "Mailing!" email user (Not too intuitive/well-named here and "Ambiguous occurrence forM_" clash with Control.Monad.) Some more dissatisfying alternatives: maybe (return ()) (\user -> do putStrLn "Mailing!" email user ) mUser flip (maybe (return ())) mUser $ \user -> do putStrLn "Mailing!" email user import Control.Monad.Trans.Maybe import Control.Monad.Trans (lift) _ <- runMaybeT $ return mUser >>= \user -> lift $ do putStrLn "Mailing!" email user return () Alternative names: - withJust, analog to withFile and withForeignPtr Any comments?

13 14

Re: HP 2013.2 RC1 Mac OS X Installers
by Mark Lentczner 08 May '13

08 May '13

Johan asked me a great question about installing HP release candidates on Mac OS X, and I thought the answer would be of general interest: On Wed, May 8, 2013 at 8:55 AM, Johan Tibell <johan.tibell(a)gmail.com> wrote: > I always want to try out new RCs when they are released, but I'm always > worried I'll screw up my current install. Can these happily coexist next to > old versions of the platform and random GHC binary installs I have? > Multiple HPs can exist side-by-side *so long as they are different GHC versions*. Nothing in the older install will get clobbered..... *EXCEPT*, the "bare" symlinks in /usr/local/bin will point at the newer version. For example, after installing both the last HP, and this RC1, I now have: /usr/bin/ghc@ -> /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/bin/ghc /usr/bin/ghc-7.4.2@ -> /Library/Frameworks/GHC.framework/Versions/7.4.2-i386/usr/bin/ghc-7.4.2 /usr/bin/ghc-7.6.3@ -> /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/bin/ghc-7.6.3 The following executables in /usr/bin are symlinked in both versioned and non-versioned forms: ghc ghc-pkg ghci haddock [set 1] These executables in /usr/bin and docs are linked only bare, and will end up pointing to the new ones: hpps hpc hsc2hs runghc runhaskell [set 2] alex cabal happy patch-ghc-settings uninstall-hs [set 3] /usr/share/man/man1/ghc.1 /usr/share/doc/ghc You can reset the executables in [set 1] and [set 2], as well as the docs, to a particular version with: sudo /Library/Frameworks/GHC.framework/Versions/*<version>*/Tools/create-links dummy /Library/Frameworks /usr Note that this will *not* update the links for the executables marked [set 3], though usually using later versions of those executables is no problem. If I could install a RC without disrupting my current setup (not changing > the ghc, etc symlinks would be a bonus) I'd be much more likely to try them > out! > This would be a good option for a re-worked installer. However, installers with user options on Mac OS X are a bit tricky both to develop and for users to use.... - Mark

1 0

HP 2013.2 RC1 Mac OS X Installers
by Mark Lentczner 08 May '13

08 May '13

The Mac OS X installers for HP 2013.2 RC 1 are up: Haskell Platform 2013.2.0.0 32bit rc1.signed.pkg<http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202013.2.0.0%203…> Haskell Platform 2013.2.0.0 64bit rc1.signed.pkg<http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202013.2.0.0%206…> This corresponds to what is currently checked in to the pre-release branch on github: https://github.com/haskell/haskell-platform/tree/pre-release There is at least one small wibble with these: The cabal documentation is missing. So I expect at least one small turn before final release.... but this is pretty close. - Mark

1 0

HP 2013.2 RC1 Source Tar Ball
by Mark Lentczner 05 May '13

05 May '13

The source tar-ball for HP 2013.2 RC 1 is up: http://www.ozonehouse.com/mark/platform/haskell-platform-2013.2.0.0-rc1.tar… This corresponds to what is currently checked in to the pre-release branch on github: https://github.com/haskell/haskell-platform/tree/pre-release *Packagers:* Please produce an RC1 candidate from the above. I'm having some trouble producing a Mac release (Xcode woes again...) but expect it in a few days. — Mark

1 0

Re: Haskell Platform 2013.2 Proposal Status
by Mark Lentczner 03 May '13

03 May '13

I've pushed some changes to the pre-release branch<https://github.com/haskell/haskell-platform/tree/pre-release>of haskell platform. The tentative version list is now set, and I've done a preliminary build of the Mac release to be sure everything builds smoothly.... ....it doesn't: - Cabal as of 1.14 now refuses to run if GHC_PACKAGE_PATH is set. Alas, this the way I was getting ghc to build in a hermetic environment (building the platform with the platform's version of GHC, not the version installed on my system). I've hacked around it in the build.sh script... but it is fugly. Other packagers may well encounter the same issue. - cgi will need a quick rev. as it relies on extensible-exceptions which are no longer a separate package in 7.6.x As such, I don't think I'll have a candidate by tomorrow --- but soon. - Mark

1 2