- Libraries - Haskell.org

DEPRECATED pragma for exports
by Ben Gamari 27 Aug '15

27 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 12 Aug '15

12 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 12 Aug '15

12 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 03 Aug '15

03 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 03 Aug '15

03 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

Re: Proposal: instance MonadIO Q
by Ryan Scott 29 Jul '15

29 Jul '15

It looks like GHC's internal MonadIO was replaced with the one from transformers in 2013 [1], so this is already fixed. Also, +1 on the MonadIO to base suggestion, now that's there's some momentum behind that idea. ---------- [1] http://git.haskell.org/ghc.git/blobdiff/b13d546f9c454e6d2a15c20a3e10ec47328…

3 2

Re: Proposal: genericReplicateM
by Ryan Scott 26 Jul '15

26 Jul '15

This sounds like a good idea to me. This might be a good thing to bundle with a separate proposal [1] to generalize replicateM(_) to use Applicative instead of Monad. [1] https://ghc.haskell.org/trac/ghc/ticket/10168

1 0

Proposal: Add missing Monoid for ZipList
by Christopher Allen 26 Jul '15

26 Jul '15

http://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Applicative.ht… There's a Monoid that matches what the Applicative for ZipList does that seems to be missing. instance Monoid a => Monoid (ZipList a) where mempty = pure mempty mappend = liftA2 mappend It's been brought up before: https://mail.haskell.org/pipermail/haskell-cafe/2009-October/067861.html Not only is it useful when it's the Monoid you want, but it serves an educational purpose for highlighting the relationship between Monoid and Applicative as well. Are there any good reasons not to have it? I'd like to limit discussion to two weeks.

9 16

Re: Improving the "Get Haskell Experience"
by Michael Snoyman 25 Jul '15

25 Jul '15

On Thu, Jul 23, 2015 at 1:15 AM Heinrich Apfelmus <apfelmus(a)quantentunnel.de> wrote: > Mark Lentczner wrote: > > *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop > > shipping pre-built packages, so we banish cabal hell, and have a single > > common way to 'get Haskell' that just works.* > > > > [..] > > > > We think this plan solves many different community needs: > > > > - We have a clear way to "get Haskell" that works for a wide variety > of > > use cases. > > - HP installer gets much smaller, and about as minimal as a working > > installation can get. > > - By leaving most packages out of the global database, users of > > cabal-install, will now have far fewer problems. Sandbox builds > should now > > never give users "cabal hell" like warnings. > > - By building and installing the Platform packages into it's own > package > > db, users get the benefit of building and installing these common > packages > > only once per system, yet can easily bypass them for any given > project if > > desired. > > - Since the Platform packages are now built and installed as needed, > > installing on smaller systems or servers without OpenGL will work. > > Sounds great to me! Personally, I do not mind how the Haskell Platform > achieves these goals; I will simply adapt to whatever tools the platform > happens to install on my machine. > > Hopefully, they come with suitable documentation. For instance, one > thing I don't understand about stack yet is in which location it > "magically" installs GHC and packages, and how I can invoke `ghci` from > these locations. Somehow, I was unable to understand this from the FAQ. > > > > I think this FAQ entry should help[1] on the first question: > Note that stack setup installs GHC into ~/.stack/programs/$platform/ghc-$version/ and not a global location. For the second question: either `stack ghci` or `stack exec ghci` should achieve what you're looking for. The former is a bit more experimental, and does more intelligent stuff at the project level as far as loading up your code. The latter simply runs the ghci command with appropriate PATH and GHC_PACKAGE_PATH environment variables set. [1] https://github.com/commercialhaskell/stack/wiki/FAQ#i-already-have-ghc-inst…

2 3