August 2015 - Libraries

DEPRECATED pragma for exports
by Ben Gamari 28 Aug '15

28 Aug '15

Hello everyone, I was looking through the list of bugs milestoned for 7.12 today and stumbled across #4879. This ticket has been with us since 7.0.1 and proposes support for the DEPRECATE pragma on exports. I seem to remember seeing this feature being requested numerous times to help in dealing with transitional issues in the core libraries. If this is the case then we should aim to get this feature in to 7.12. This shouldn't be a difficult task as there is a working patch [1] in need of only a bit of minor refactoring already attached to the ticket. What we need to make this happen is for someone to step up and write a specification (on the GHC Wiki) defining the syntax and its semantics, and then check that the patch faithfully implements that specification. Would any of you be willing to do this? Cheers, - Ben [1] https://phabricator.haskell.org/D638

1 0

IsString [Char] instance
by Dan Doel 13 Aug '15

13 Aug '15

Greetings, Today, someone came into #haskell and asked why they couldn't type the equivalent of: > "hi" ++ "bye" into GHCi with OverloadedStrings enabled. The answer is that it's ambiguous, because (++) only determines the strings to be [a], and not [Char]. I noticed that this could actually be solved by making the instance: instance (a ~ Char) => IsString [a] where ... Which causes [Char] to be inferred as soon as [a] is. I then searched my libraries mail and noticed that we'd discussed this two years ago. The proposal for this instance change was rejected based on ExtendedDefaultRules being beefed up to solve this case. But then no one actually implemented the better defaulting. So, I'm proposing that the issue be fixed for real. I'm not terribly concerned with how it gets fixed, but there's not a great reason for this to not behave better than it currently does. If someone steps up and makes defaulting better, than that's great. But if not, then the libraries committee can fix this very easily for GHC 7.12, and I think it's better to do so than to wait if there are no signs that the alternative is going to happen. I don't think we need to nail down which of the two solutions we're going to choose right now, but it'd be good to resolve that we're going to fix it, one way or another, by some well defined date. Here's a link to the previous discussion: http://comments.gmane.org/gmane.comp.lang.haskell.libraries/20088 Discussion period: 2 weeks -- Dan

8 12

Proposal: newtype for applicatives of monoids
by David Feuer 13 Aug '15

13 Aug '15

Sorry for the terrible title, but I think we should add something like the following to Data.Monoid (I already mentioned this in the discussion of a Monoid instance for ZipList). newtype Appl f m = Appl (f m) instance (Applicative f, Monoid m) => Monoid (Appl f m) where mempty = Appl $ pure mempty mplus (Appl x) (Appl y) = Appl $ liftA2 mplus x y It may be possible to use coercions to improve mplus; I haven't tried it. This type is the same as WrappedApplicative from semigroupoids, do it might be best just to give it that name.

10 13

Re: [core libraries] Re: mapM /= traverse?
by Edward Kmett 04 Aug '15

04 Aug '15

At the very least, it does seem like we're going to need to do a broader survey of the instances out there, as well as fix a lot more Applicative instances to have a better (*>) first as well as thoroughly document what to do, if we want to proceed on this front. If we ultimately want to remove mapM from the class to get it a more permissive type signature, and get mapM_ from Foldable to have the more general signature to boot, then we'll need to figure out how to address these concerns. It still strikes me as the right general direction to go in, but this is troubling. -Edward On Mon, Aug 3, 2015 at 12:33 PM, Ben Gamari <ben(a)well-typed.com> wrote: > Edward Kmett <ekmett(a)gmail.com> writes: > > > On Tue, May 12, 2015 at 3:58 AM, Simon Marlow <marlowsd(a)gmail.com> > wrote: > > > >> > >> Yes, I'm not really concerned that mapM is a method of Traversable > rather > >> than just being an alias for traverse, but I'm wondering why we define > it > >> in the list instance rather than using the default. > >> > > > > We were pretty paranoid about introducing space or time regressions and > > didn't have a proof that we wouldn't introduce them by changing something > > there, so we left it alone. > > > On a related note, D924 [1] proposed that mapM_ be redefined in > terms of traverse_. Unfortunately at least one monad in GHC itself was > adversely affected [2] by this change, resulting in non-linear complexity > in > a previously well-behaved function (a minimal demonstration of this can > be found below). > > We discussed this in the GHC weekly meeting and felt that we should > ensure that the libraries group was aware of this issue. > > Cheers, > > - Ben > > > [1] https://phabricator.haskell.org/D924 > [2] https://ghc.haskell.org/trac/ghc/ticket/10711 > [3] Demonstration of regression in complexity of mapM_ when expressed in > terms of `traverse_`, > > {{{ > module Main where > > import Control.Monad hiding (mapM_) > import Prelude hiding (mapM_) > > -- | Testcase derived from Assembler monad in ByteCodeAsm > data Assembler a > = Thing Int (Int -> Assembler a) > | Pure a > > instance Functor Assembler where > fmap = liftM > > instance Applicative Assembler where > pure = return > (<*>) = ap > > instance Monad Assembler where > return = Pure > Pure x >>= f = f x > Thing i k >>= f = Thing i (k >=> f) > > -- This is traverse_ > mapA_ :: (Foldable t, Monad f) => (a -> f b) -> t a -> f () > mapA_ f = foldr ((*>) . f) (pure ()) > > -- This is the current definition > mapM_ :: (Foldable t, Monad f) => (a -> f b) -> t a -> f () > mapM_ f = foldr ((>>) . f) (pure ()) > > test = map (\i->Thing i (const $ return 2)) [0..10000] > > doTestM = mapM_ id test > doTestA = mapA_ id test > > run :: Assembler a -> a > run (Thing i f) = run (f i) > run (Pure r) = r > {-# NOINLINE run #-} > > main :: IO () > main = print $ run doTestM > }}} > > -- > You received this message because you are subscribed to the Google Groups > "haskell-core-libraries" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-core-libraries+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/d/optout. >

2 1

Re: Proposal: instance MonadIO Q
by Ryan Scott 04 Aug '15

04 Aug '15

Since almost two weeks have passed since I originally started this thread, I'd be willing to submit patches which would 1. Move MonadIO from transformers to base 2. Introduce a MonadIO Q instance I'm not sure what the etiquette for #1 is, however, since that would require a change to a GHC dependency (transformers). Should I first submit a patch that hides Control.Monad.IO.Class from GHC's transformers fork if impl(ghc >= 7.11) (similar to this commit [1]), and then submit an additional patch that adds Control.Monad.IO.Class to base? Or would it suffice to do both in one go? Ryan ----- [1] http://git.haskell.org/packages/transformers.git/commitdiff/refs/heads/wip/…

1 0

Proposal: Allow arr ∧ (first ∨ (***)) as minimal definition of Arrow instance
by M Farkas-Dyck 03 Aug '15

03 Aug '15

Add default definitions of first, second in terms of (***) to let one define an Arrow instance in terms of (***) rather than first, which is sometimes more elegant or convenient. To my knowledge this can not break any code. GHC ticket: 10216

1 0