News aggregator

When is sequenceA an applicative morphism?

Haskell on Reddit - Wed, 04/08/2015 - 8:05pm

Suppose T is traversable and applicative, and F is applicative. We have the map

sequenceA :: T (F a) -> F (T a)

which I'd like to think of as a natural transformation TF -> FT. If you like we can be explicit about this by writing

sequenceC :: Compose T F a -> Compose F T a sequenceC = Compose . sequenceA . getCompose

Since F and T are applicative, Compose F T and Compose T F are as well. When is it the case that sequenceC satisfies the following equations?

sequenceC . pure = pure sequenceC (f <*> x) = sequenceC f <*> sequenceC x

I suspect the first equation always holds, so I'm more interested in the second.

The second equation often fails. For example, for T = Maybe, F = (,) String:

f :: Compose Maybe ((,) String) (a -> Bool) f = Compose $ Just ("a", \_ -> True) x :: Compose Maybe ((,) String) a x = Compose Nothing

and we have

sequenceC (f <*> x) == Compose ("", Nothing) sequenceC f <*> sequenceC x == Compose ("a", Nothing)

As another example, it holds if we take T = (,) String and F = Maybe.

submitted by seriousreddit
[link] [3 comments]
Categories: Incoming News

Haskell logo Keycaps finally up for group-buy

Haskell on Reddit - Wed, 04/08/2015 - 5:41pm

So, we did it! The Haskell Keycap group-buy is finally up! See it here:

Note that you'll initially be charged the 'full' amount, though you'll be refunded if we get more than 50, 75, 100, or 250 keys!

There is also a sub-deal for 1x (normal size), whereas the main deal is for a 1.25x (OS key).

submitted by NFATracker
[link] [5 comments]
Categories: Incoming News

Last CFP Bx'15: 4th International Workshop onBidirectional Transformations

General haskell list - Wed, 04/08/2015 - 5:06pm
LAST CALL FOR PAPERS Fourth International Workshop on Bidirectional Transformations (Bx 2015) L'Aquila, Italy (co-located with STAF, July 24, 2015) Bidirectional transformations (Bx) are a mechanism for maintaining the consistency of at least two related sources of information. Such sources can be relational databases, software models and code, or any other document following standard or ad-hoc formats. Bx are an emerging topic in a wide range of research areas, with prominent presence at top conferences in several different fields (namely databases, programming languages, software engineering, and graph transformation), but with results in one field often getting limited exposure in the others. Bx 2015 is a dedicated venue for Bx in all relevant fields, and is part of a workshop series that was created in order to promote cross-disciplinary research and awareness in the area. A
Categories: Incoming News

Monoid instance for Either that mappends both sides

Haskell on Reddit - Wed, 04/08/2015 - 12:02pm

Does something like this exist somewhere already?

newtype EitherMonoids a b = EitherMonoids (Either a b) deriving (Show) instance (Monoid a, Monoid b) => Monoid (EitherMonoids a b) where mempty = EitherMonoids $ Right mempty (EitherMonoids (Left xs)) `mappend` (EitherMonoids (Left ys)) = EitherMonoids $ Left $ xs `mappend` ys (EitherMonoids (Right xs)) `mappend` (EitherMonoids (Right ys)) = EitherMonoids $ Right $ xs `mappend` ys x@(EitherMonoids (Left _)) `mappend` (EitherMonoids (Right _)) = x (EitherMonoids (Right _)) `mappend` x@(EitherMonoids (Left _)) = x submitted by singpolyma
[link] [11 comments]
Categories: Incoming News

FP Complete: Announcing: monad-unlift

Planet Haskell - Wed, 04/08/2015 - 5:00am

I've released the first version of monad-unlift. From its README:

Typeclasses for providing for unlifting of monad transformers and stacks, and concrete implementations of common transformers implementing this type classes.

This package is a companion to monad-control, providing simplified functions to a common subset of transformers and functionality. I've copied in the content of the README below to give some examples and explanations.

I'd like to thank Erik Hesselink and Hiromi Ishii for providing some brilliant solutions to make this package more useful, based on the constraints package.

Synopsisimport Control.Concurrent.Async import Control.Monad.Trans.Unlift import Control.Monad.Trans.RWS.Ref import Control.Monad.IO.Class import Data.Mutable -- Some artbirary data type for the MonadReader data SomeEnv = SomeEnv Int myFunc :: RWSRefT -- The WriterT piece is contained by an IORef IORef -- For efficiency, we store the state in a primitive -- reference for efficiency (PRef RealWorld) SomeEnv -- Reader [String] -- Writer Int -- State IO (String, String) myFunc = do -- Get the unlift function. Due to weaknesses in ImpredicativeTypes, we -- need to use a newtype wrapper. You can also use askRunBase. -- -- If you want to just unwrap one transformer layer, use -- askUnlift/askRun/Unlift. UnliftBase run <- askUnliftBase -- Note that we can use unlift to turn our transformer actions into IO -- actions. Unlike the standard RWST, actions from separate threads are -- both retained due to mutable references. -- -- In real life: you shouldn't rely on this working, as RWST is not thread -- safe. This example is provided as a good demonstration of the type level -- functionality. liftIO $ concurrently (run foo) (run bar) where foo = do tell ["starting foo"] modify (+ 1) tell ["leaving foo"] return "foo is done" bar = do tell ["starting bar"] SomeEnv e <- ask modify (+ e) tell ["leaving bar"] return "bar is done" main :: IO () main = do ((w, x), y, z) <- runRWSRefT myFunc (SomeEnv 5) 6 print w -- foo is done print x -- bar is done print y -- 12 = 6 + 5 + 1 print z -- starting and leaving statements, order ambiguousOverview

A common pattern is to have some kind of a monad transformer, and want to pass an action into a function that requires actions in a base monad. That sounds a bit abstract, so let's give a concrete example:

-- From async concurrently :: IO a -> IO b -> IO (a, b) func1 :: ReaderT Foo IO String func2 :: ReaderT Foo IO Double doBoth :: ReaderT Foo IO (String, Double) doBoth = _

Doing this manually is possible, but a bit tedious:

doBoth :: ReaderT Foo IO (String, Double) doBoth = ReaderT $ \foo -> concurrently (runReaderT func1 foo) (runReaderT func2 foo)

This also doesn't generalize at all; you'll be stuck writing concurrently variants for every monad transformer stack. Fortunately, the monad-control package generalizes this to a large number of transformer stacks. Let's implement our generalized concurrently:

concurrentlyG :: MonadBaseControl IO m => m a -> m b -> m (StM m a, StM m b) concurrentlyG f g = liftBaseWith $ \run -> concurrently (run f) (run g)

Notice how, in the signature for concurrentlyG, we no longer return (a, b), but (StM m a, StM m b). This is because there may be additional monadic context for each thread of execution, and we have no way of merging these together in general. Some examples of context are:

  • With WriterT, it's the values that you called tell on
  • With EitherT, the returned value may not exist at all

In addition to this difficulty, many people find the types in monad-control difficult to navigate, due to their extreme generality (which is in fact the power of that package!).

There is a subset of these transformer stacks that are in fact monad morphisms. Simply stated, these are transformer stacks that are isomorphic to ReaderT. For these monads, there is not context in the returned value. Therefore, there's no need to combine returned states or deal with possibly missing values.

This concept is represented by the monad-unlift package, which provides a pair of typeclasses for these kinds of transformer stacks. Before we dive in, let's see how we solve our concurrentlyG problem with it:

concurrentlyG :: MonadBaseUnlift IO m => m a -> m b -> m (a, b) concurrentlyG f g = do UnliftBase run <- askUnliftBase liftBase $ concurrently (run f) (run g)

Notice how we get (a, b) in the return type as desired. There's no need to unwrap values or deal with context.


MonadTransUnlift is a class for any monad transformer which is isomorphic to ReaderT, in the sense that the environment can be captured and applied later. Some interesting cases in this space are:

  • IdentityT and things isomorphic to it; in this case, you can think of the environment as being ()
  • Transformers which contain a mutable reference in their environment. This allows them to behave like stateful transformers (e.g., StateT or WriterT), but still obey the monad morphism laws. (See below for more details.)

Due to weaknesses in GHC's ImpredicativeTypes, we have a helper datatype to allow for getting polymorphic unlift functions, appropriately named Unlift. For many common cases, you can get away with using askRun instead, e.g.:

bar :: ReaderT Foo IO () baz :: ReaderT Foo IO () baz = do run <- askRun liftIO $ void $ forkIO $ run bar

Using Unlift, this would instead be:

Unlift run <- askUnlift liftIO $ void $ forkIO $ run bar

or equivalently:

u <- askUnlift liftIO $ void $ forkIO $ unlift u barMonadBaseUnlift

MonadBaseUnlift extends this concept to entire transformer stacks. This is typically the typeclass that people end up using. You can think of these two typeclasses in exactly the same way as MonadTrans and MonadIO, or more precisely MonadTrans and MonadBase.

For the same ImpredicativeTypes reason, there's a helper type UnliftBase. Everything we just discussed should transfer directly to MonadBaseUnlift, so learning something new isn't necessary. For example, you can rewrite the last snippet as:

u <- askUnliftBase liftIO $ void $ forkIO $ unliftBase u barReference transformers

When playing transformer stack games with a transformer like StateT, it's common to accidentally discard state modifications. Additionally, in the case of runtime exceptions, it's usually impossible to retain the state. (Similar statements apply to WriterT and RWST, both in strict and lazy variants.)

Another approach is to use a ReaderT and hold onto a mutable reference. This is problematic since there's no built in support for operations like get, put, or tell. What we want is to have a MonadState and/or MonadWriter instance.

To address this case, this package includes variants of those transformers that use mutable references. These reference are generic using the mutable-containers package, which allows you to have highly efficient references like PRef instead of always using boxed references like IORef.

Note that, for generality, the reference transformers take type parameters indicating which mutable reference type to use. Some examples you may use are:

  • IORef for boxed references in IO
  • STRef s for boxed references in ST
  • PRef RealWorld for an unboxed reference in IO

See the synopsis for a complete example.


The transPipe function in conduit has caused confusion in the past due to its requirement of provided functions to obey monad morphism laws. This package makes a good companion to conduit to simplify that function's usage.

Other notable instances

Both the HandlerT transformer from yesod-core and LoggingT/NoLoggingT are valid monad morphisms. HandlerT is in fact my first example of using the "enviornment holding a mutable reference" technique to overcome exceptions destroying state.

{-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE TemplateHaskell #-} import Control.Concurrent.Async import Control.Monad.IO.Class import Control.Monad.Logger import Control.Monad.Trans.Unlift main :: IO () main = runStdoutLoggingT foo foo :: (MonadLogger m, MonadBaseUnlift IO m, MonadIO m) => m () foo = do run <- askRunBase a <- liftIO $ async $ run $ $logDebug "Hello World!" liftIO $ wait a
Categories: Offsite Blogs

Dimitri Sabadie: Volumetric Light Shafts

Planet Haskell - Wed, 04/08/2015 - 4:01am
Volumetric light scattering

On the last weekend, I was at the Revision demoparty (Easterparty). It’s a meeting of friends and great people doing graphics, music, code and that kind of fun and pretty stuff. I didn’t release anything, but I’ve been working on a release for a while now, and I was lacking something in my engine: light shafts.

I know a few ways to do that. They almost all fall in one of the two following classes:

  1. screen-space-based;
  2. raymarching-based.

Both the techniques produce interesting images. However, the screen-space-based method produces bad results when you don’t look directly to the light – it may even produce nothing if the light is out of screen – and the raymarching-based is a step process that might generate artifacts and can be slow.

The idea I had is very simple. I haven’t tested it yet, but it’s planned for very soon. I’ll post images with benchmarks as soon as I have something on screen. I’m not sure it’s an unknown way to do it. I just haven’t found anything describing that yet. If you have, please leave a link in the comments below! :)

Volume extraction

The idea is the following. You need a depthmap. If you’re used to shadow mapping you already have a depthmap for your light. In order to simplify this, we’ll use the depthmap used for shadow mapping, but I guess it’s totally okay to use another depthmap – we’ll see that it could be even handier.

For each point in that depthmap is the distance – in a specific space coordinates system – of the corresponding point in world space to the position of the light. If you have the projection and the view matrices of the light, it’s easy to deproject the depthmap. What would we get if we deproject all the depthmap texels into the world space? We’d get the exact lit surfaces.

For a spot light, you can imagine the deprojected version of the depthmap as a cone of light. The “disk” of the cone will deform and shape as the lit environment. That’s the first part of the algorithm.

We have a points cloud. What happens if, for each deprojected texel – i.e. point – we draw a line to the position of the light? We get an actual lines field representing… photons paths! How amazing is that?! Furthermore, because of the depthmap sampling, if you look at the light and that an object is between you and the light, the photons paths won’t go through the obstructing object! Like the following image:

Of course, because of using raw lines, the render might be a bit blocky at first. If you know the laser trick1 – i.e. quad-based lasers, you can apply it to our lines as well, in order to get better results. The first improvement is to disable depth test and enable additive blending.


In the first place, you need to generate the depthmap of the light. Then, you need to extract the volumetric shaft. You’ll need a vertex buffer for that. Allocate w*h elements, where w and h are the depthmap’s width and height. Yeah, a point per texel.

Create a shader and make a render with glDrawArrays(GL_POINTS, 0, w*h) with an attributeless vertex array object. Don’t forget to bind the depthmap for use in the shader.

In your vertex shader, use gl_VertexID to sample from the depthmap. Transform the resulting texel in world-space. You can use something like the following deprojection formula:

vec3 deproject() {
float depth = 2. * texelFetch(depthmap, ivec2(gl_FragCoord.xy), 0).r - 1.;
vec4 position = vec4(vv, depth, 1.);
position = iProjView * position; /= position.w;

Pass that to the next stage, the geometry shader. There, build whatever kind of new primitive you want. In the first place, I’ll go for a simple line connected to the light’s position. In further implementation, I’ll go for lasers-like base shapes, like star-crossed quads.

In the fragment shader, put whatever color you want the shaft to have. You could use interpolation to reduce lighting wherever you want to create nice effects.

Don’t forget to use additive blending, as we do for lasers.


I see two major problems. The first one is the bright aspect the shaft will have if you don’t blend correctly. Play with alpha to reduce more if the fragment is near the light’s position and make the alpha bigger when you’re far away from the light’s position. Because you’ll blend way more photons paths near the light’s position than far from it.

The second issue is the resolution of the extracted volume. For a 512x512 depthmap, you’ll get around 262k points, then 524k lines. That’s a lot for such an object. And that’s only for a simple spot light. An omnidirectional light would require six times more lines. What happens if we don’t use lines, but star-crossed quads an that we want several shafts? You see the problem.

A solution could be to sample from high mipmap level, so that you don’t use the full resolution of the shadow map. That would result in less visual appealing shafts, but I’m pretty sure it’d be still good. You could also branch a blur shader to smooth out the whole thing.


I’ll try to implement that as soon as possible, because I think my idea is pretty interesting compared to raymarching, which is expensive, and way better than screen-space, because the shaft will still be visible if the light goes out of screen.

  1. I’ll write an article about it if you don’t – leave a comment for asking

Categories: Offsite Blogs

Recommendations for a Linux stack for Haskell web dev?

Haskell on Reddit - Wed, 04/08/2015 - 3:32am

As a long-time windows user, and an infrequent "Google Linux bash commands until it works" user, you could say my experience with Linux is limited at best.

All the web work I do ends up on a Linux machine eventually, so I've always run a WAMP or WAPP server locally, then pushing to some pre-configured VPS, having to just set up vhosts. I've never even installed MySQL on a Linux server (though done plenty of configuration via MySQL Workbench).

A friend of mine suggested Bitnami (e.g. and running a Linux instance in a VM. Which I thought was a pretty good idea. I noticed that Bitnami has no Haskell stacks. But I assume (hope) it's not the only catalog of its kind on the web.

I managed to get Yesod to install locally on Windows with GHC 7.10, sans any database connection. But I figured I'd stop there. Considering how much hell I went through getting a simple Haskell app to talk to MySQL on Windows before, I'm not keen on repeating it.

So I figure it's probably a good idea if I do my development in an environment I'll use in production anyway. And I'll probably want to use LTS anyway rather than trying to persevere with GHC 7.10.

With that back story / rant in mind... does anyone have a recommendation for a Linux ISO / Stack? Ideally something with a webserver already configured so that the most I have to do is set up virtual hosts... and even more ideally with Haskell LTS / Yesod already setup like those Bitnami stacks.

submitted by TheCriticalSkeptic
[link] [15 comments]
Categories: Incoming News

What's the current status of ghcjs vs haste?

Haskell on Reddit - Wed, 04/08/2015 - 12:36am

I've been using Haste a bit for small test programs. As I'm planning to write a fairly large web app using haskell, and I want to choose the right compiler for it. Basically, I like Haste's philosophy that it's going to be used in the client side and don't pretend to be a complete GHC environment. But GHCJS can be really good at compiling existing libraries. Though GHCJS's generated code and performance seems not as good as Haste. I've learned a lot from this subreddit on differences between ghcjs and haste. Example threads: But those discussions are at least 1 year ago and before GHC7.8 was released. What's the current status of both compiler and how does GHCJS compared to Haste, especially on code size and performance? Thanks!

submitted by manyoo
[link] [26 comments]
Categories: Incoming News

Anyone interested in taking over network-uri?

haskell-cafe - Tue, 04/07/2015 - 10:18pm
Hi! I find myself with less time to hack lately and I'm trying to reduce the number of libraries I maintain so I can invest time in new things. Would anyone be interested taking over maintenance of network-uri? It should not be much work at all. Bump a few dependencies and fix a bug or two. The package is very widely used so I suggest that the new maintainer should avoid breaking changes whenever possible*. * In other words, if you want to completely rethink network URI handling, this package is probably not the place for it.
Categories: Offsite Discussion

Why should I learn Haskell?

Haskell on Reddit - Tue, 04/07/2015 - 8:31pm

hi /r/haskell,

I get the arguments about functional vs imperative. I get the multithreaded wonderfulness. I get the build speed difference. What I don't get is what I could build in Haskell that would be so tremendous.

I'm not trying to piss on it, I swear. I'm just scratching my head trying to figure out a project that would really and truly benefit from Haskell over some other language.

I do enjoy learning Haskell, I must say. I'm a js dev and it totally helps me see my own work in a new light.

submitted by kingbobofyourhouse
[link] [11 comments]
Categories: Incoming News


General haskell list - Tue, 04/07/2015 - 6:08pm
[apologies for any cross-posting] *** SUBMISSIONS ARE NOW OPEN *** Call for Papers --------------------------------------------------------------------------- 13th International Conference on Logic Programming and Non-monotonic Reasoning LPNMR 2015 Lexington, KY, USA September 27-30, 2015 (Collocated with the 4th Conference on Algorithmic Decision Theory 2015) --------------------------------------------------------------------------- AIMS AND SCOPE LPNMR 2015 is the thirteenth in the series of international meetings on logic programming and non-monotonic reasoning. LPNMR is a forum for exchanging ideas on declarative logic programming, non-monotonic reasoning, and knowledge representation. The aim of the conference is to facilitate interactions between researchers and practition
Categories: Incoming News

help w/ improving custom Stream for parsec

haskell-cafe - Tue, 04/07/2015 - 5:25pm
I need a custom stream that supports insertion of include files and expansions of macros. I also want to be able to give nice error messages (think of clang macro-expansion backtrace), so I cannot use the standard trick of concatenating included files and expanded macros to the current input with setInput/getInput (I think I can't maybe there's a way of keeping a more complex "position" and since the use in producing an error backtrac is rare, it migth be worth exploring; if anybody has ideas here, I'm listening) Assuming I need a more compelx stream, this is what I have (Macro and File both have a string argument, but it will be more compicated, a list of expansions for Macro for instance). Is there a better way for doing this? What are the performance implications with backtracking? I'll be benchmarking it, but if people see obvious problems, let me know. Thanks a lot, Maurizio {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE MultiParamTy
Categories: Offsite Discussion

status of

haskell-cafe - Tue, 04/07/2015 - 5:15pm
The haskell status page says that has been down since mid-February. Are there any plans to bring it back up? -- View this message in context: Sent from the Haskell - Haskell-Cafe mailing list archive at
Categories: Offsite Discussion

Distribution of GHC extensions on Hackage

Haskell on Reddit - Tue, 04/07/2015 - 5:12pm

I decided it would be interesting to see how many files on hackage were using CPP (4473) and whilst I was doing so, it made sense to collect stats for all the other extensions as well. These are the raw figures gathered from parsing the LANGUAGE pragmas, the numbers include any implied flags. The high number for TypeSynonymInstances is a bit confusing but make of it what you want!

(Opt_TraditionalRecordSyntax,62729) (Opt_PatternGuards,62717) (Opt_EmptyDataDecls,62717) (Opt_DoAndIfThenElse,62717) (Opt_RelaxedPolyRec,62717) (Opt_ForeignFunctionInterface,62716) (Opt_NondecreasingIndentation,62649) (Opt_MonomorphismRestriction,62130) (Opt_ImplicitPrelude,60283) (Opt_TypeSynonymInstances,7815) (Opt_FlexibleInstances,7503) (Opt_OverloadedStrings,7050) (Opt_ExplicitForAll,6181) (Opt_ExplicitNamespaces,5852) (Opt_MonoLocalBinds,5471) (Opt_KindSignatures,5408) (Opt_MultiParamTypeClasses,5205) (Opt_TypeFamilies,4654) (Opt_FlexibleContexts,4534) (Opt_Cpp,4473) (Opt_ScopedTypeVariables,4185) (Opt_DeriveDataTypeable,4162) (Opt_GeneralizedNewtypeDeriving,3288) (Opt_RankNTypes,2901) (Opt_TemplateHaskell,2858) (Opt_DisambiguateRecordFields,2654) (Opt_RecordWildCards,2636) (Opt_DeriveGeneric,2236) (Opt_UndecidableInstances,2036) (Opt_BangPatterns,2032) (Opt_TypeOperators,1883) (Opt_DataKinds,1857) (Opt_LambdaCase,1523) (Opt_GADTSyntax,1319) (Opt_ExistentialQuantification,1316) (Opt_GADTs,1316) (Opt_FunctionalDependencies,1309) (Opt_StandaloneDeriving,1080) (Opt_MagicHash,890) (Opt_UnicodeSyntax,852) (Opt_DeriveFunctor,844) (Opt_OverlappingInstances,800) (Opt_ViewPatterns,682) (Opt_TupleSections,645) (Opt_UnboxedTuples,634) (Opt_DeriveFoldable,573) (Opt_DeriveTraversable,553) (Opt_RecursiveDo,539) (Opt_ParallelListComp,536) (Opt_QuasiQuotes,529) (Opt_ImplicitParams,524) (Opt_LiberalTypeSynonyms,459) (Opt_UnliftedFFITypes,455) (Opt_PostfixOperators,441) (Opt_ConstrainedClassMethods,427) (Opt_RecordPuns,407) (Opt_ConstraintKinds,395) (Opt_PackageImports,390) (Opt_IncoherentInstances,307) (Opt_PolyKinds,226) (Opt_Arrows,163) (Opt_DefaultSignatures,161) (Opt_ExtendedDefaultRules,102) (Opt_DatatypeContexts,93) (Opt_ImpredicativeTypes,82) (Opt_RebindableSyntax,67) (Opt_PatternSynonyms,51) (Opt_MultiWayIf,43) (Opt_InstanceSigs,38) (Opt_NPlusKPatterns,14) (Opt_MonadComprehensions,10) (Opt_AutoDeriveTypeable,10) (Opt_AllowAmbiguousTypes,9) (Opt_NullaryTypeClasses,6) (Opt_GHCForeignImportPrim,6) (Opt_TransformListComp,5) (Opt_OverloadedLists,5) (Opt_EmptyCase,4) (Opt_CApiFFI,4) (Opt_ParallelArrays,3) (Opt_NegativeLiterals,2) (Opt_RoleAnnotations,2) (Opt_NumDecimals,2) (Opt_MonoPatBinds,2) submitted by Lossy
[link] [15 comments]
Categories: Incoming News