- Libraries - Haskell.org

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

non-ASCII filepaths in a C function
by Henning Thielemann 25 Jul '15

25 Jul '15

In my 'soxlib' package I have written a binding to sox_format_t * sox_open_read( char const * path, sox_signalinfo_t const * signal, sox_encodinginfo_t const * encoding, char const * filetype); I construct the C filepath "path" from a Haskell FilePath using Foreign.C.String.withCString. This works for ASCII and non-ASCII characters in Linux. However, non-ASCII characters let sox_open_read fail on Windows. What is the correct way to convert FilePath to "char *"?

3 4

Proposal: Migrate Data.Functor.{Sum, Product, Compose} from transformers to base.
by Edward Kmett 25 Jul '15

25 Jul '15

As part of GHC 7.10 we moved Data.Functor.Identity from transformers into base. (We'd previously had a private, equivalent definition buried in Data.Traversable that we didn't export.) In a similar vein, I hereby propose moving Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose, and Data.Functor.Classes into base as they exist in transformers, without unduly bikeshedding their APIs. This would effectively reduce the role of transformers to simply supplying actual transformers and continue the general pattern of universal constructions migrating into base. Without bikeshedding their implementations this migration becomes a no-op for existing users. The most awkward of these is the Data.Functor.Classes API, but it affects a number of their instances, and without it, those instances would have to be orphans, so my gut reaction would be to say yes, we should move that as well. There are also some in-flight API changes in the works in the HEAD version of transformers for which a base-based version of the API could exploit DefaultSignatures to ease migration. I'm rather deliberately not including Data.Functor.Constant in this proposal as when it has been discussed in the past, Const from Control.Applicative has effectively grown to subsume that role. That said, we if we bring in the rest of this stuff we could migrate it to Data.Functor.Const and simply re-export it from Control.Applicative to avoid breakage. So, as a concrete proposal I propose that we: 1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose and Data.Functor.Classes into base. 2.) Move Control.Applicative's Const into Data.Functor.Const, but continue to re-export it from Control.Applicative. 3.) Add whatever missing, sensible, instances make sense after the transition that were ruled out by these modules' previous placement. *e.g.* Data, Generic, Generic1. Discussion Period: 2 weeks -Edward Kmett

8 9

Intention to takeover glpk-hs
by Jean-Philippe Bernardy 25 Jul '15

25 Jul '15

Hi, I intend to take over the glpk-hs package from Louis, who did not respond to my direct request, made June 22nd. The last update to the package was made in 2012 and it does not compile with ghc 7.10. Cheers, JP.

3 2

Re: Proposal: Migrate Data.Functor.{Sum, Product, Compose} from transformers to base.
by Ryan Scott 24 Jul '15

24 Jul '15

I really like this proposal, especially since having convenient Eq1, Ord1, Read1, Show1, etc. instances is something I've wanted for a while. I have some questions about some specifics: 1. Just to verify, you're proposing a breaking change in which Data.Functor.Constant no longer exports Constant, but rather Const? 2. You mentioned that the additions to base could use DefaultSignatures. Could you give an example of how this would work?

3 3