- Libraries - Haskell.org

Functor instances for GetOpt data types
by Henning Thielemann 20 Nov '11

20 Nov '11

I propose to add Functor instances for data types in GetOpt as shown below. I like to have them since I want to build an Option record from sub-records for specific functions, and I like to glue together the sub-records and according argument descriptions. With the Functor instance I can lift the option descriptions for the sub-records to the main Option record. As an interim solution I could prepare a package that provides these instances as orphan instances and has a cabal switch to export the instances from base, once they appear there. Discussion period until 4th of December. PS: I am scared by the idea to have to compile the whole GHC only in order to get 'base' built, and then insert and test these Functor instances. Is there an easier way? PSS: Is it necessary to have GetOpt in base? ---------------------------------- instance Functor ArgOrder where fmap f order = case order of RequireOrder -> RequireOrder Permute -> Permute ReturnInOrder g -> ReturnInOrder $ f.g instance Functor ArgDescr where fmap f d = case d of NoArg a -> NoArg $ f a ReqArg g str -> ReqArg (f.g) str OptArg g str -> OptArg (f.g) str instance Functor OptDescr where fmap f (Option short long arg help) = Option short long (fmap f arg) help

2 1

Can the in-progress ByteString proposals make it into GHC 7.4.1?
by Herbert Valerio Riedel 17 Nov '11

17 Nov '11

Hello GHC HQ, According to the GHC Status October 2011 Report[3], the GHC 7.4 branch is supposed to be in "feature freeze" by now. Does this affect/include the bytestring library (as it happens to be a GHC-boot library) as well? More specifically, if the ongoing proposals "Add {to,from}Strict conversion functions between strict and lazy ByteStrings"[1] and "Add NFData instances for strict and lazy ByteStrings"[2] succeed, what's the next stable GHC release they're gonna be included in? [1]: http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/16444 [2]: http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/16397 [3]: http://hackage.haskell.org/trac/ghc/wiki/Status/Oct11 -- hvr

4 6

Proposal: Ignore sub-minor version components in package id
by Joachim Breitner 15 Nov '11

15 Nov '11

Hi, I’d like to propose that the package (shown by "ghc-pkg field <pkg> id" and used by "ghc-pkg field <pkg> depends") should only consist of the first three components of the package version, not all of them. By the package versioning policy, if the API stays the same, these version numbers stay identical. And if the change does not affect the ABI, the hash stays the same. This would allow upgrades of the package without having to re-build everything depending on it. And if the maintainer does not fully follow the PVP, then it is not a big deal either; the hash will change and Cabal will enforce rebuilds. One could argue that the version can be removed entirely from the package id, but it helps the human reader when looking at the "depends" field of a package. Greetings, Joachim -- Joachim "nomeata" Breitner mail(a)joachim-breitner.de | nomeata(a)debian.org | GPG: 0x4743206C xmpp: nomeata(a)joachim-breitner.de | http://www.joachim-breitner.de/

5 10

Addition to unix: raw ByteString APIs
by Simon Marlow 14 Nov '11

14 Nov '11

I propose to commit the attached patch to the unix package and release it with GHC 7.4.1. The commit log is reproduced below. Comments please! The unix version number will of course be bumped appropriately. Cheers, Simon commit d5e43be90d3c6f8869dd2b0c65800c9a6dd0ac70 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Fri Nov 11 16:18:48 2011 +0000 Provide a raw ByteString version of FilePath and environment APIs The new module System.Posix.ByteString provides exactly the same API as System.Posix, except that: - There is a new type: RawFilePath = ByteString - All functions mentioning FilePath in the System.Posix API use RawFilePath in the System.Posix.ByteString API - RawFilePaths are not subject to Unicode locale encoding and decoding, unlike FilePaths. They are the exact bytes passed to and returned from the underlying POSIX API. - Similarly for functions that deal in environment strings (System.Posix.Env): these use untranslated ByteStrings in System.Posix.Environment - There is a new function System.Posix.ByteString.getArgs :: [ByteString] returning the raw untranslated arguments as passed to exec() when the program was started.

9 11

ANNOUNCE: iteratee-compress 0.3.0.0
by Maciej Marcin Piechotka 14 Nov '11

14 Nov '11

Iteratee-compress provides compressing and decompressing enumerators including flushing (using John Lato's implementation). Currently only gzip and bzip is provided but LZMA is planned. Changes from previous version: - Move API from enumerator to enumeratee Next goals: - LZMA support - Generic interface for flushing To think about: - Should inner iteratee be able to request flushing Regards

1 0

Proposal: Add the orphan instance Monoid e => Monad ((, )e) to Data.Monoid
by Edward Kmett 13 Nov '11

13 Nov '11

I propose adding an (orphan) instance of Monad for ((,) e) to Data.Monoid. Discussion deadline: 2 weeks from now (November 26) == Current State == No instance == The Issues == Control.Applicative already exports a compatible instance for Applicative for ((,) e), but there isn't a canonical place to get the compatible Monad. == Proposed enhancement == Add the following orphan instance to Data.Monoid. instance Monoid e => Monad ((,) e) where return a = (a, mempty) (w,a) >>= k = (mappend w w', b) where (w',b) = k a Why? Monoid isn't exported from the Prelude, so there is currently no place for this instance to live currently that doesn't render it an orphan. == Alternative == We could place this instance in Control.Monad.Instances which is where we've placed similar instances in the past. However, this would increase the likelihood of failure to properly import the instance for users, who would have to know to import both Data.Monoid and Control.Monad.Instances, rather than just Data.Monoid. Moreover in a separate active proposal I've just proposed moving all the Control.Monad.Instances instances out, so in the event that that proposal is adopted this would be unsatisfyingly the only instance there. -Edward

6 6

Proposal: Add Applicative instances for the remaining monads in base
by Bas van Dijk 12 Nov '11

12 Nov '11

Hello, The only public monads in base that don't have Applicative instances yet are: ReadP, ReadPrec and ArrowMonad. Because of the rule of least surprise I would like to propose adding Applicative instances for these monads. Concretely I would like to propose adding the following to Control.Applicative: instance Applicative ReadP where pure = return (<*>) = ap instance Alternative ReadP where empty = mzero (<|>) = mplus instance Applicative ReadPrec where pure = return (<*>) = ap instance Alternative ReadPrec where empty = mzero (<|>) = mplus instance ArrowApply a => Applicative (ArrowMonad a) where pure = return (<*>) = ap And adding a Functor instance for ArrowMonad to Control.Arrow: instance Arrow a => Functor (ArrowMonad a) where fmap f (ArrowMonad m) = ArrowMonad $ m >>> arr f Discussion deadline: I don't think this is a controversial proposal and so I don't expect objections. Can we bend the rules a bit and shorten the discussion period so this can be integrated into the base library that comes with the upcoming ghc-7.4? Regards, Bas

4 5

Why do we need Control.Monad.Instances?
by Bas van Dijk 12 Nov '11

12 Nov '11

Hello, I forgot the reason why we need Control.Monad.Instances which exports orphaned Functor and Monad instances for ((->) r), ((,) a) and (Either e): https://github.com/ghc/packages-base/blob/master/Control/Monad/Instances.hs Can't we just de-orphan these instances by moving the instances for ((->) r) and ((,) a) to GHC.Base and by moving the instances for Either to Data.Either? Regards, Bas

4 3

What's the future of the haskellYYYY packages?
by Bas van Dijk 11 Nov '11

11 Nov '11

On 11 November 2011 15:09, Henning Thielemann <lemming(a)henning-thielemann.de> wrote: > > On Fri, 11 Nov 2011, Bas van Dijk wrote: > >> I forgot the reason why we need Control.Monad.Instances which exports >> orphaned Functor and Monad instances for ((->) r), ((,) a) and (Either >> e): > > Compatibility with Haskell 98's Prelude? Thanks I understand. What exactly is the future plan of the haskell98 and haskell2010 packages? I understand that the Haskell' Process[1] now only deals with the Haskell language and that the evolution of the core libraries is now the responsibility of the Library Submission Process[2]. Does this mean we stop making haskellYYYY packages? I think that would be a good thing. Since these packages block innovation in certain parts of base (for example: getting rid of some orphaned instances in Control.Monad.Instances or designing a new monad hierarchy). Regards, Bas [1] http://hackage.haskell.org/trac/haskell-prime/wiki/Process [2] http://www.haskell.org/haskellwiki/Library_submissions

4 5

Proposal: New Eq and Ord instances for Double and Float
by Daniel Fischer 11 Nov '11

11 Nov '11

Proposal: Provide Double and Float with Eq and Ord instances that introduce a total order. Discussion period: Two weeks Rationale: The Eq and Ord instances for Double and Float currently follow the IEEE specification in that * NaN == x = False * NaN /= x = True * NaN < x = False * NaN > x = False * NaN <= x = False * NaN >= x = False This has several undesirable consequences: - (==) does not define an equivalence relation on those types - (<) does not define a total order on those types (not even a partial order) - compare always returns GT if (at least) one argument is a NaN As a result, various algorithms and data structures are broken in the presence of NaNs: Prelude Data.List Data.Set> let nan :: Double; nan = 0/0 Prelude Data.List Data.Set> max nan 1 NaN Prelude Data.List Data.Set> max 1 nan 1.0 Prelude Data.List Data.Set> minimum [0,1,nan,2,nan,3,4,nan,5,6] 5.0 Prelude Data.List Data.Set> sort [0,1,nan,2,nan,3,4,nan,5,6] [0.0,1.0,3.0,5.0,6.0,NaN,4.0,NaN,2.0,NaN] Prelude Data.List Data.Set> let st = fromList [0,1,nan,2,nan,3,4,nan,5,6] Prelude Data.List Data.Set> Prelude.filter (`member` st) [0 .. 10] [0.0,1.0,2.0,5.0,6.0] Prelude Data.List Data.Set> Prelude.filter (`member` (Data.Set.filter (not . isNaN) st)) [0 .. 10] [0.0,1.0,2.0,3.0,4.0,5.0,6.0] ===================== I therefore propose to change the Eq and Ord instances for Double and Float to conform with the behaviour expected from such instances in Haskell, and to make the comparisons with IEEE semantics available from the RealFloat class. In more detail: * Eq: The Eq instance for Double and Float shall be changed so that NaN == NaN = True NaN /= NaN = False Since there are many bit patterns which are NaN values, there remains the question whether all NaNs shall be considered equal or whether only NaNs with identical bit patterns should be considered equal. I lean towards treating all NaNs equal to each other. A different edge-case is negative zero. At the moment, we have 0.0 == (-0.0) = True as mandated by IEEE. The question is whether that should be kept or we want to disinguish between 0.0 and -0.0. Because of recip 0.0 = Infinity recip (-0.0) = -Infinity I lean towards distinguishing. * Ord: The Ord instance shall be modified so that - if currently x < y holds, that shall remain so - NaN shall (arbitrarily, in analogy to Maybe's Ord instance[s]) be considered smaller than all non-NaN values. If Eq should distinguish different NaNs, the Ord instance should do the same. If Eq should distinguish 0.0 and -0.0, so should the Ord instance. * IEEE comparisons: These shall be made available from the RealFloat class (where applicable, if the hardware doesn't provide them, default them to the Ord methods). Two reasons: first their semantics might be needed in some programmes; second, as hardware operations, they're fast, in number-crunching programmes where NaNs can't occur, that can make a significant difference. These operators should be visually similar to the Eq and Ord operators but not too similar. The ML languages - afaik - mark operators on floating point values by appending a dot, (+.), (<.) etc. That seems too easy to overlook to me, by enclosing the operator in dots, (.==.), (.<.) the opportunity to spot the difference is doubled without being too heavy notation. On the other hand, we already use the dot for other things, so using dots as the distinguishing means may be less that optimal. Suggestions welcome.

17 28