- Libraries - Haskell.org

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

new MonadRandom instance; and maintainership
by Brent Yorgey 26 Apr '13

26 Apr '13

Hi all, I would like to add a derived MonadPlus instance for both Rand and RandT. Also, since it seems that MonadRandom has no maintainer I propose to take on its maintainership. Any comments/objections/etc. welcome. -Brent

3 7

Proxy, new Typeable, and type-level equality
by Richard Eisenberg 24 Apr '13

24 Apr '13

Hi all, Combining ideas from a number of people/threads ("Proxy and new-typeable" [on libraries] and "RFC: Singleton equality witnesses" [on ghc-devs]), I propose this: > module GHC.TypeReasoning where > > data a :~: b where > Refl :: a :~: a > > -- with credit to Conal Elliott for 'ty' and Erik Hesselink & Martijn van Steenbergen for 'type-equality' > sym :: (a :~: b) -> (b :~: a) > trans :: (a :~: b) -> (b :~: c) -> (a :~: c) > coerce :: (a :~: b) -> a -> b > liftEq :: (a :~: b) -> (f a :~: f b) > liftEq2 :: (a :~: a') -> (b :~: b') -> (f a b :~: f a' b') > liftEq3 :: ... > liftEq4 :: ... > > instance Eq (a :~: b) where ... > instance Show (a :~: b) where ... > instance Read (a :~: a) where ... > instance Ord (a :~: b) where ... > -- what other instances? > > data Void > -- instances as in Edward Kmett's 'void' package > > absurd :: Void -> a > > type Refuted a = a -> Void > type Decision a = Proved a > | Disproved (Refuted a) > > class EqT f where > eqT :: f a -> f b -> Maybe (a :~: b) > > class EqT f => DecideEqT f where > decideEqT :: f a -> f b -> Decision (a :~: b) > > defaultEqT :: DecideEqT f => f a -> f b -> Maybe (a :~: b) -- for easy writing of EqT instances > > instance EqT ((:~:) a) where ... > instance DecideEqT ((:~:) a) where ... > module Data.Proxy where > -- as in Ben Gamari's version > module Data.Typeable ( … , Proxy(..), (:~:)(..) ) where > > ... > import GHC.TypeReasoning > import {-# SOURCE #-} Data.Proxy > > ... > eqTypeable :: (Typeable a, Typeable b) => Maybe (a :~: b) > decideEqTypeable :: (Typeable a, Typeable b) => Decision (a :~: b) > -- can't use EqT and DecideEqT because Typeable is in Constraint, not * > > gcast :: (Typeable a, Typeable b) => c a -> Maybe (c b) -- it is now polykinded > > {-# DEPRECATED gcast1 ... #-} > {-# DEPRECATED gcast2 ... #-} > ... On top of features others have proposed/written in packages, I have added DecideEqT and related definitions. I would indeed have use for this definition, and I imagine others will, too, once it's out there. We could theoretically hold off on that one, but it seems easy enough just to put it in now, while we're all thinking about it. I've tested the definition by writing instances of singletons, and it works as desired. If this proposal is accepted, we can then look at changing some of the definitions around TypeLits as well, linking in much of the ghc-devs thread "RFC: Singleton equality witnesses". I don't see any dependencies from the code above on the TypeLits/singleton stuff, so I think we can take those changes in a second round. One question in the above code: What other instances should there be for (:~:)? Comments? Thoughts? Thanks, Richard

8 9

ANN: data-textual: Human-friendly textual representations
by Mikhail Vorozhtsov 24 Apr '13

24 Apr '13

Hello lists, I'm pleased to announce the first release of data-textual[1], a library that provides human-friendly counterparts (called Printable/Textual) of the compiler-friendly Show/Read type classes. The library is intended to be used for printing and parsing of non-compound and non-polymorphic compound data (e.g. numbers, network and hardware addresses, date/time, etc). A quick example (vs network-ip[2] library): λ> import Data.Maybe (fromJust) λ> import Data.Textual λ> import Network.IP.Addr λ> let x = fromString "[dead::b:e:e:f]:123" :: Maybe Inet6Addr λ> x Just (InetAddr {inetHost = ip6FromWords 0xdead 0x0 0x0 0x0 0xb 0xe 0xe 0xf, inetPort = 123}) λ> toString (fromJust x) "[dead::b:e:e:f]:123" λ> let y = fromStringAs aNet4Addr "192.168.100.1/24" λ> y Just (netAddr (ip4FromOctets 192 168 100 1) 24) λ> toText (netPrefix $ fromJust y) "192.168.100.0" [1] http://hackage.haskell.org/package/data-textual [2] http://hackage.haskell.org/package/network-ip

1 0

Fix prelude definitions of abs/signum for Floats/Doubles
by Levent Erkok 22 Apr '13

22 Apr '13

The current definition of "abs" and "signum" for the types Float/Double is not IEEE-754 compliant. To wit: Prelude> abs (-0.0::Float) -0.0 Prelude> signum (-0.0::Float) 0.0 The correct result should be the other way around; abs returning 0.0 and signum returning -0.0 when they receive a negative-zero. The same also holds for the type Double. The issue came up several times in several forums, with general consensus that the behavior should match the IEEE-754 specs. Here're three different discussions on this matter: http://www.haskell.org/pipermail/libraries/2011-January/015761.html http://stackoverflow.com/questions/10395761/absolute-value-of-negative-zero… http://www.haskell.org/pipermail/haskell-cafe/2013-April/107471.html Proposed fix: Section 6.4.4 of the report http://www.haskell.org/onlinereport/basic.html#sect6.4 gives "default" definitions for abs/signum; which fails to take into account of negative-zero values for floating-point types. An easy fix would be to add to the report a note on the status of negative-zero for Real/Float instances; with individual implementations explicitly checking for negative-0 first. For instance GHC's implementation can be changed as follows: instance Num Float where signum x | isNegativeZero x = x | x == 0 = 0 | x > 0.0 = 1 | otherwise = negate 1 abs x | isNegativeZero x = 0 | x >= 0 = x | otherwise = negate x A similar change would need to be done for the "Num Double" instance as well. Of course, implementations can take advantage of the underlying CPU's native floating-point abs/sign functions if available as well, avoiding explicit tests at the Haskell code; based on the underlying platform. Library guidelines suggest a discussion period of 2 weeks on this issue. I'm hoping that we can resolve the issue in a timely manner, and at least GHC's implementation can match the desired semantics in the next release. If there's consensus at the end of 2-weeks; I'll go ahead and create a corresponding ticket for GHC. Thanks, -Levent.

12 19

Re: Haskell Platform 2013.2 Proposal Status
by Mark Lentczner 22 Apr '13

22 Apr '13

My point was really that it wasn't a bug, there's nothing to fix: unix-2.6.x.y isn't expected to work with ghc-7.4.z. In the bug's comments you wrote: *Any chance of a fix for this? Many packages depend on unix and these packages can't be installed on Mac OS with the latest Haskell Platform.* * * Why do you think this is a problem? Haskell Platform (including the latest) ships with a version of the unix package that is compatible with the GHC it ships with. Any package that depends on unix should compile on Platform out of the box, as long as it works with GHC-7.4.1 & unix-2.5.1.1. I'd like to know if there are packages for which this is not true. - Mark

1 0