September 2013 - Libraries

Proposal: merge either into transformers
by Roman Cheplyaka 03 Jan '17

03 Jan '17

I propose to add the sole module of the 'either' package[1], Control.Monad.Trans.Either, to the transformers package. It provides EitherT, a very basic and fundamental data type. The difference between EitherT and ErrorT is that the latter has an Error constraint, which is used to imlement 'fail'. Note that 'either' depends on the 'semigroupoids' and 'semigroup' packages to provide appropriate instances. The proposal is not to add those instances to 'transformers' to avoid additional dependencies. The instances can then be left in the 'either' package or moved to the 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' already depends on 'transformers', while 'semigroups' does not). Compared to the 'either' package, Show, Read, Eq and Ord instances will be dropped to keep the code Haskell2010 (those instances require FlexibleInstances, FlexibleContexts, and UndecidableInstances). The patch is attached. [*] [*] against transformers-0.3.0.0, because the darcs version is not buildable (Control/Monad/Signatures.hs is not in the repository). Roman

22 72

Proposal: Use time rather than old-time in directory
by Ian Lynagh 16 Sep '14

16 Sep '14

Hi all, This proposal is to change directory to use the time package rather than the old-time package. This will hopefully be a significant step towards actually making the transition in general. I'm not sure if POSIXTime or UTCTime is the better type to use. Does anyone know? I started off with UTCTime, then switched to POSIXTime as UTCTime didn't have a Show instance. I've since found that actually UTCTime has both Show and Read instances, but they are orphaned. So actually, if UTCTime is the better type then switching back to UTCTime would allow us to fix this comment in hpc: -- We would rather use ClockTime in Mix, but ClockTime has no Read instance and simplify the code slightly. Attached are patches for directory, hpc and ghc. Suggested discussion period: Until 5th Nov 2011. Thanks Ian

14 35

Proposal: Add Data.Semigroup to base, as a superclass of Monoid
by John Wiegley 11 Aug '14

11 Aug '14

1. I propose that we add the following package to base: http://hackage.haskell.org/packages/archive/semigroups/0.9.2/doc/html/Data-… This is somewhat in the spirit of the AMP proposal: further improving the correctness of our algebraic abstractions. 2. That we make Semigroup a superclass of Monoid, so that (minimally): class Semigroup a where (<>) :: a -> a -> a class Semigroup a => Monoid a where mempty :: a mconcat :: [a] -> a mconcat = foldr (<>) mempty mappend :: Semigroup a => a -> a -> a mappend = (<>) 3. (Optional, recommended) There are other useful functions that can be added to Semigroup, such as sconcat and times1p, but I will let Edward speak to whether those should be proposed at this time. 4. (Optional, recommended) That we fix the Monoid instance for Maybe to be: instance Semigroup a => Semigroup (Maybe a) where Just x <> Just y = Just (x <> y) _ <> _ = Nothing instance Semigroup a => Monoid (Maybe a) where mempty = Nothing For some clarification on what semigroups are and why we'd want to change Monoid, I excerpt here a selection from Brent Yorgey's "Monoids and Variations" paper: Semigroups A semigroup is like a monoid without the requirement of an identity element: it consists simply of a set with an associative binary operation.... Of course, any monoid is automatically a semigroup (by forgetting about its identity element). In the other direction, to turn a semigroup into a monoid, simply add a new distinguished element to serve as the identity, and extend the definition of the binary operation appropriately. This creates an identity element by definition, and it is not hard to see that it preserves associativity.... Adding a new distinguished element to a type is typically accomplished by wrapping it in Maybe. One might therefore expect to turn an instance of Semigroup into an instance of Monoid by wrapping it in Maybe. Sadly, Data.Monoid does not define semigroups, and has a Monoid instance for Maybe which requires a Monoid constraint on its argument type... This is somewhat odd: in essence, it ignores the identity element of [the type] and replaces it with a different one. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net

9 9

Proposal: Show and Read for Data.Ord.Down
by Krzysztof Gogolewski 14 Oct '13

14 Oct '13

Hello, I propose to add derived Show and Read instances to Data.Ord.Down. This should be uncontroversial. Any thoughts? For reference, Data.Ord.Down is currently defined as newtype Down a = Down a deriving (Eq) instance Ord a => Ord (Down a) where compare (Down x) (Down y) = y `compare` x Krzysztof Gogolewski

11 18

[Proposal] Add instance Monoid a => Monoid (Const a b)
by haskell＠nand.wakku.to 13 Oct '13

13 Oct '13

Hello, I think this a Monoid instance on Const would be useful. The motivation comes from ‘lens’, where folds come out as (a -> Const a a) -> s -> Const a s. This instance, together with the Monoid a => Monoid (r -> a) instance, allows folds themselves to be an instance of Monoid, allowing for some really pretty code. Example of the instance body: > instance Monoid a => Monoid (Const a b) where > mempty = Const mempty > mappend (Const a) (Const b) = Const (mappend a b) Examples of it being used together with lens: >>> "Hello, world!" ^.. mconcat [ix 2, ix 7, ix 1] "lwe" Discussion Period: 2 weeks

12 16

[Proposal] Renaming (:=:) to (==)
by Edward Kmett 11 Oct '13

11 Oct '13

As part of the discussion about Typeable, GHC 7.8 is going to include a Data.Type.Equality module that provides a polykinded type equality data type. I'd like to propose that we rename this type to (==) rather than the (:=:) it was developed under. We are already using (+), (-), (*), etc. at the type level in type-nats, so it would seem to fit the surrounding convention. I've done the work of preparing a patch, visible here: https://github.com/ekmett/packages-base/commit/fb47f8368ad3d40fdd79bdeec334… Thoughts? Normally, I'd let this run the usual 2 week course, but we're getting down to the wire for 7.8's release. Once 7.8 ships, we'd basically be stuck with the current name forever. Discussion Period: 1 week -Edward Kmett

14 27

Proposal: Partitionable goes somewhere + containers instances
by Ryan Newton 07 Oct '13

07 Oct '13

<subject change> On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki <mike(a)izbicki.me> wrote: > I've got a Partitionable class that I've been using for this purpose: > > https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/Cons… > Mike -- Neat, that's a cool library! Edward -- ideally, where in the standard libraries should the Partitionable comonoid go? Btw, I'm not sure what the ideal return type for comappend is, given that it needs to be able to "bottom out". Mike, our partition function's list return type seems more reasonable. Or maybe something simple would be this: *class Partitionable t where* * partition :: t -> Maybe (t,t)* That is, at some point its not worth splitting and returns Nothing, and you'd better be able to deal with the 't' directly. So what I really want is for the *containers package to please get some kind of Partitionable instances! * Johan & others, I would be happy to provide a patch if the class can be agreed on. This is important because currently the balanced tree structure of Data.Set/Map is an *amazing and beneficial property* that is *not* exposed at all through the API. For example, it would be great to have a parallel traverse_ for Maps and Sets in the Par monad. The particular impetus is that our new and enhanced Par monad makes extensive use of Maps and Sets, both the pure, balanced ones, and lockfree/inplace ones based on concurrent skip lists: http://www.cs.indiana.edu/~rrnewton/haddock/lvish/ Alternatively, it would be ok if there were a "Data.Map.Internal" module that exposed the Bin/Tip, but I assume people would rather have a clean Partitionable instance... Best, -Ryan On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki <mike(a)izbicki.me> wrote: > I've got a Partitionable class that I've been using for this purpose: > > > https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/Cons… > > The function called "parallel" in the HLearn library will automatically > parallelize any homomorphism from a Partionable to a Monoid. I > specifically use that to parallelize machine learning algorithms. > > I have two thoughts for better abstractions: > > 1) This Partitionable class is essentially a comonoid. By reversing the > arrows of mappend, we get: > > comappend :: a -> (a,a) > > By itself, this works well if the number of processors you have is a power > of two, but it needs some more fanciness to get things balanced properly > for other numbers of processors. I bet there's another algebraic structure > that would capture these other cases, but I'm not sure what it is. > > 2) I'm working with parallelizing tree structures right now (kd-trees, > cover trees, oct-trees, etc.). The real problem is not splitting the > number of data points equally (this is easy), but splitting the amount of > work equally. Some points take longer to process than others, and this > cannot be determined in advance. Therefore, an equal split of the data > points can result in one processor getting 25% of the work load, and the > second processor getting 75%. Some sort of lazy Partitionable class that > was aware of processor loads and didn't split data points until they were > needed would be ideal for this scenario. > > On Sat, Sep 28, 2013 at 6:46 PM, adam vogt <vogt.adam(a)gmail.com> wrote: > >> On Sat, Sep 28, 2013 at 1:09 PM, Ryan Newton <rrnewton(a)gmail.com> wrote: >> > Hi all, >> > >> > We all know and love Data.Foldable and are familiar with left folds and >> > right folds. But what you want in a parallel program is a balanced fold >> > over a tree. Fortunately, many of our datatypes (Sets, Maps) actually >> ARE >> > balanced trees. Hmm, but how do we expose that? >> >> Hi Ryan, >> >> At least for Data.Map, the Foldable instance seems to have a >> reasonably balanced fold called fold (or foldMap): >> >> > fold t = go t >> > where go (Bin _ _ v l r) = go l `mappend` (v `mappend` go r) >> >> This doesn't seem to be guaranteed though. For example ghc's derived >> instance writes the foldr only, so fold would be right-associated for >> a: >> >> > data T a = B (T a) (T a) | L a deriving (Foldable) >> >> Regards, >> Adam >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >

8 17

Haskell Platform Proposal: add the 'aeson' library
by Bas van Dijk 02 Oct '13

02 Oct '13

Hello, I would like to propose adding the 'aeson' library to the next Haskell Platform which is scheduled for November. The detailed proposal is kept at: http://trac.haskell.org/haskell-platform/wiki/Proposals/aeson Discussion deadline: October 7th, 2013 Regards, Bas

17 20

OT: Symbolic type variables (was Re: [Proposal] Renaming (:=:) to (==))
by Erik Hesselink 01 Oct '13

01 Oct '13

On Mon, Sep 30, 2013 at 8:25 PM, Conal Elliott <conal(a)conal.net> wrote: > I'm hoping we don't get more deeply invested in the syntactic change in GHC > 7.6 that removed the possibility of symbolic type variables ("~>", "*", "+", > etc). I had a new job and wasn't paying attention when SPJ polled the > community. From my perspective, the loss has much greater scope than the > gain for type level naturals. I'd like to keep the door open to the > possibility of bringing back the old notation with the help of a language > pragma. It would take a few of us to draft a proposal addressing details. I also miss these on a regular basis. I seem to remember that during the proposal, there was a mention of reversing the situation, i.e. having a prefix for type variable operators instead. Did anything ever come of that? Erik

2 1

[Proposal] add view function for NPlusKPatterns
by Stijn van Drongelen 30 Sep '13

30 Sep '13

Hello, I'm working on a desugaring library for Haskell. Desugaring NPlusKPatterns currently takes up the most code, since a proper translation involves generating two guards. Meanwhile, most other pattern-related language extensions are defined in terms of ViewPatterns, which are trivial to desugar. In my laziness to fix this otherwise, I propose that the following function is added to the Prelude: > maySubtractIntegral :: Integral a => a -> a -> Maybe a > maySubtractIntegral k nplusk = if n >= 0 then Just n else Nothing > where > n = nplusk - k So that `NPlusKPatterns` like < func (n+42) = expr may be desugared to < func (maySubtractIntegral 42 -> Just n) = expr rather than < func nplusk | n <- nplusk - 42, n >= 0 = expr The name of this function is, of course, subject to bikeshedding. Note that the signature is correct; though (Ord a, Num a) is more general, it's too weak for the semantics of the language extension. Discussion period: 2 weeks

3 3