July 2015 - Libraries

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

27 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 27 Jul '15

27 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 26 Jul '15

26 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 26 Jul '15

26 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 26 Jul '15

26 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

Re: [Haskell-cafe] ANN: haddock-2.16.1
by Chris Wong 24 Jul '15

24 Jul '15

On Fri, Jul 24, 2015 at 10:24 PM, Tomas Carnecky <tomas.carnecky(a)gmail.com> wrote: > Will hackage rebuild all existing documentation or only when I upload a new > version? IIRC, it will only build a package when its documentation is not present. > If not automatically, can I manually tell hackage to rebuild the > docs? Go to the package page, and click the "edit package information" link at the bottom. There should be an option to clear and rebuild the docs. > > On Wed, Jul 22, 2015 at 11:43 PM Matthew Pickering > <matthewtpickering(a)gmail.com> wrote: >> >> The curious can see an example of this new hyperlinked source here[1]. >> >> Great work Łukasz and Mateusz! >> >> [1]: >> https://hackage.haskell.org/package/ghc-exactprint-0.3/docs/src/Language.Ha… >> >> On Wed, Jul 22, 2015 at 11:17 PM, Mateusz Kowalczyk >> <fuuzetsu(a)fuuzetsu.co.uk> wrote: >> > Hi, >> > >> > We're glad to announce Haddock 2.16.1. It is mostly a bugfix release: I >> > inline the changelog at the bottom. It should work fine with 7.10.x GHC >> > family. The packages are already on Hackage: haddock for the executable, >> > haddock-api for the guts and use from Haskell and haddock-library which >> > is the comment parser. >> > >> > It should also be shipping with GHC 7.10.2. >> > >> > I think two things are worth mentioning before: >> > >> > * The pending mathjax PR[1] is going to be included in future release of >> > Haddock. As it is likely to break the interface file version, I am >> > putting it off a bit to bundle with other possibly interface-breaking >> > changes. >> > >> > * Our GSOC student has successfully completed first part of his >> > project[2]. It involves native source code highlighting and perhaps more >> > excitingly, source hyperlinking: you should now be able to click on >> > identifiers to be taken to their definitions. This change is not in >> > 2.16.1 as it is rather recent so we erred on the side of safety when >> > picking what to release with GHC 7.10.2. You can try it by building >> > current Haddock master, should work with 7.10.x family. >> > >> > As usual, if you want to contribute, please do so on GitHub. We're also >> > on IRC under #haddock. >> > >> > Thanks! >> > >> > Changes in version 2.16.1 >> > >> > * Don't default to type constructors for out-of-scope names (#253 and >> > #375) >> > >> > * Fix Hoogle display of constructors (#361) >> > >> > * Fully qualify names in Hoogle instances output (#263) >> > >> > * Output method documentation in Hoogle backend (#259) >> > >> > * Don't print instance safety information in Hoogle (#168) >> > >> > * Expand response files in arguments (#285) >> > >> > * Build the main executable with -threaded (#399) >> > >> > * Use SrcSpan of declarations for inferred type sigs (#207) >> > >> > * Fix cross-module instance locations (#383) >> > >> > * Fix alignment of Source link for instances in Firefox (#384) >> > >> > [1]: https://github.com/haskell/haddock/pull/397 >> > [2]: https://github.com/haskell/haddock/pull/410 >> > >> > -- >> > Mateusz K. >> > _______________________________________________ >> > Libraries mailing list >> > Libraries(a)haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Chris Wong (https://lambda.xyz) "Humans find such fascinating ways to waste their time." -- Steven Universe

1 0

Proposal: genericReplicateM
by Ken T Takusagawa 24 Jul '15

24 Jul '15

Overloaded versions of replicateM and replicateM_ for any Integral type: genericReplicateM :: (Monad m, Integral i) => i -> m a -> m [a] genericReplicateM n = sequence . genericReplicate n genericReplicateM_ :: (Monad m, Integral i) => i -> m a -> m () genericReplicateM_ n = sequence_ . genericReplicate n --ken

1 0

Proposal: instance MonadIO Q
by Ryan Scott 24 Jul '15

24 Jul '15

Template Haskell currently has runIO :: IO a -> Q a , which allows you to run IO actions with a guarantee of IO effects' ordering in a single splice (but not necessarily the order in which all the Q splices are run). If runIO is indeed a monad morphism, then there is a law-abiding MonadIO Q instance that could be added to transformers: instance MonadIO Q where liftIO = runIO This would be useful for dealing with monad transformer stacks with Q as the base monad (for an example, see genifunctors (https://github.com/danr/genifunctors/blob/4677bb57423b1b380ce9b50cc3d765a5c…) The only catch is that transformers would have to depend on template-haskell. I think this would be okay since no quasiquotation is involved, but I wanted to hear others' opinions. Ryan

5 6