May 2015 - Libraries - Haskell.org

mapM /= traverse?
by Simon Marlow 28 May '15

28 May '15

I was hoping that in GHC 7.10 we would make mapM = traverse for lists, but it appears this isn't the case: the Traversable instance for lists overrides mapM to be the manually-defined version in terms of foldr. Why is this? Fusion? Unfortunately since I want mapM = traverse (for Haxl) I'll need to continue to redefine it in our custom Prelude. Cheers, Simon

5 11

aeson-utils: aeson-0.9 compatibility package
by Adam Bergmark 25 May '15

25 May '15

Hi folks, aeson-0.9 was released today. It changes the behavior of `decode` and `eitherDecode`: They now both allow atomic values on the top level. Previously the behavior was inconsistent, `encode 1 = "1"` but `decode "1" :: Maybe Int = Nothing`. aeson-utils[1] has the functions `decodeV` and `eitherDecodeV` that work like aeson-0.9's `decode` and `eitherDecode` respectively, also with older aeson versions. If you want to stay backwards compatible without having varying semantics based on dependencies, check it out! [1] http://hackage.haskell.org/package/aeson-utils Regards, Adam

1 0

Proposal: liftData for Template Haskell
by Edward Z. Yang 14 May '15

14 May '15

I propose adding the following function to Language.Haskell.TH: -- | 'liftData' is a variant of 'lift' in the 'Lift' type class which -- works for any type with a 'Data' instance. liftData :: Data a => a -> Q Exp liftData = dataToExpQ (const Nothing) I don't really know which submodule this should come from; since it uses 'dataToExpQ', you might put it in Language.Haskell.TH.Quote but arguably 'dataToExpQ' doesn't belong in this module either, and it only lives there because it is a useful function for defining quasiquoters and it was described in the quasiquoting paper. I might propose getting rid of the 'Lift' class entirely, but you might prefer that class since it doesn't go through SYB (and have the attendant slowdown). This mode of use of 'dataToExpQ' deserves more attention. Discussion period: 1 month Cheers, Edward

9 12

maintaining pre-AMP+FTP-Prelude in external package
by Henning Thielemann 14 May '15

14 May '15

The Prelude of GHC-7.10/base-4.8 introduces several name clashes mostly due to the AMP and FTP: (<*) clashes with Accelerate, (<*>) clashes with NumericPrelude, (and (<>) would clash with HMatrix if added to Prelude), 'join', 'pure', 'traverse', 'fold' clash with custom defined functions. "import Prelude hiding (pure)" is not yet supported by GHC-7.4 (as shipped with Ubuntu 12.04) and in newer GHC versions it generates an annoying warning. The only remaining option is to explicitly import identifiers from Prelude. What about maintaining the pre-AMP+FTP-Prelude in a package on Hackage? Then we could maintain compatibility with a range of GHC versions by disabling import of Prelude and importing preamplified (so to speak) Prelude. The base-compat package seems to support the other way round, that is, providing new 'base' functions to old compilers.

5 6

Proposal: Generalize forever to Applicative
by David Feuer 12 May '15

12 May '15

This looks like a no-brainer to me: forever :: Applicative f => f a -> f b forever a = let x = a *> x in x

8 7

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Dan Doel 11 May '15

11 May '15

vector generates a considerable amount of code using CPP macros. And with regard to other mails, I'm not too eager (personally) to port that to template Haskell, even though I'm no fan of CPP. The code generation being done is so dumb that CPP is pretty much perfect for it, and TH would probably just be more work (and it's certainly more work to write it again now that it's already written). On Wed, May 6, 2015 at 10:21 AM, Bardur Arantsson <spam(a)scientician.net> wrote: > On 06-05-2015 15:05, Alan & Kim Zimmerman wrote: > > Perhaps it makes sense to scan hackage to find all the different CPP > idioms > > that are actually used in Haskell code, if it is a small/well-defined set > > it may be worth writing a simple custom preprocessor. > > > > +1, I'll wager that the vast majority of usages are just for version > range checks. > > If there are packages that require more, they could just keep using the > system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd > want to see real evidence that that's actually worth the > effort/complication. > > Regards, > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

3 2

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Brandon Allbery 09 May '15

09 May '15

On Fri, May 8, 2015 at 7:40 PM, Donn Cave <donn(a)avvanta.com> wrote: > But fatal if compilation is conditional on something that affects the > ability to type check, am I right? Such as different compilers or > versions of same compiler. > Not per the abstract (paper itself seems to be paywalled). They had an earlier work with that issue, the linked one is about how to be robust in the face of such conditionals. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 1

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Malcolm Wallace 08 May '15

08 May '15

On 8 May 2015, at 00:06, Richard A. O'Keefe wrote: > I think it's important that there be *one* > "cpp" used by Haskell. fpp is under 4 kSLOC > of C, and surely Haskell can do a lot better. FWIW, cpphs is about 1600 LoC today. Regards, Malcolm

6 7

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Malcolm Wallace 08 May '15

08 May '15

Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: > That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). > > On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace <malcolm.wallace(a)me.com> wrote: > I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. > > Regards, > Malcolm > > On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: > > > On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: > > > > [...] > > > >> Regarding licensing issues: perhaps we should simply ask Malcolm > >> Wallace if he would consider changing the license for the sake of GHC? > >> Or perhaps he could grant a custom-tailored license to the GHC > >> project? After all, the project page [1] says: " If that's a problem > >> for you, contact me to make other arrangements." > > > > Fyi, Neil talked to him[1]: > > > > | I talked to Malcolm. His contention is that it doesn't actually change > > | the license of the ghc package. As such, it's just a single extra > > | license to add to a directory full of licenses, which is no big deal. > > > > > > [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_pro… > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

1 0

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by wren romano 08 May '15

08 May '15

On Wed, May 6, 2015 at 9:05 AM, Alan & Kim Zimmerman <alan.zimm(a)gmail.com> wrote: > Perhaps it makes sense to scan hackage to find all the different CPP idioms > that are actually used in Haskell code, if it is a small/well-defined set it > may be worth writing a simple custom preprocessor. Conditional imports are far and away the most commonly used idiom. Second most common, I'd say, is specifying GHC-specific vs compiler-generic implementations of top-level functions (e.g., using GHC.Exts.build or not). For both of these it's sufficient to have the #if construction plus everything needed for the conditional expressions. However, while the #if construction covers the vast majority of use cases, it doesn't cover all of them. Macros are also important. For example, a number of low-level libraries will use macros for things like having assertions which are either compiled as runtime checks, or as nothing, depending on a Cabal flag. Of course, there are plenty of other places where we want to use macros in low-level code, either to force inlining, or to have conditional compilation of (non-top-level) expressions that show up over and over. That these idioms aren't more common is just because there aren't more people working on such low-level code. In theory TH should be able to handle this stuff, but TH is a verbose sledgehammer for these sorts of problems, and using TH means restricting yourself to being GHC-only. -- Live well, ~wren

1 0