# News aggregator

### I print myself

[link] [12 comments]

### Fixing a Yesod/Warp/HTTPS performance issue when running on an Openstack VM

### Strange "ambiguity" problems thanks to GADTs

### Better, faster binary serialization :: transferable tricks and tips for other libraries

### Is Greece a Monad?

Is it a monad, in the sense that it binds all the money and returns ()? I am Greek so feel free to write anything you like...

submitted by nikosquant[link] [comment]

### Request for maintainer(s) : language-javascript /hjsmin

### OCL 2015: Final Call for Papers - Only 10 Days Left

### OCL 2015: Final Call for Papers - Only 10 Days Left

### Problems with type families

### New Functional Programming Job Opportunities

### I'd appreciate help figuring out how to use polymorphism in a simple case

I think I know why this code is failing (I'm guessing because the typechecker sees that t can be an Int or a String and thinks I've made a mistake). What I'd like to know is how I can get something like this working. I think the code explains my basic case pretty well, so I'll let it do the work:

data TestMode = A | B data Test = Test { a :: String, b :: Int, mode :: TestMode } getProperty :: Show t => Test -> t getProperty test = case mode test of A -> a test B -> b test main = do let t = Test { a = "yes!", b = 5, mode = A } print $ getProperty tI leave the error in the comments to make this a bit shorter to read. My goal is to not do a lot of duplicate code. The following script works, but if I have to do a lot of print operations like this it gets unwieldy:

data TestMode = A | B data Test = Test { a :: String, b :: Int, mode :: TestMode } main = do let t = Test { a = "yes!", b = 5, mode = A } case mode t of A -> print $ a t B -> print $ b t submitted by benekastah[link] [17 comments]

### Roman Cheplyaka: How Haskell handles signals

How is it possible to write signal handlers in GHC Haskell? After all, the set of system calls allowed inside signal handlers is rather limited. In particular, it is very hard to do memory allocation safely inside a signal handler; one would have to modify global data (and thus not be reentrant), call one of the banned syscalls (brk, sbrk, or mmap), or both.

On the other hand, we know that almost any Haskell code requires memory allocation. So what’s the trick?

The trick is that a Haskell handler is not installed as a true signal handler. Instead, a signal is handled by a carefully crafted RTS function generic_handler (rts/posix/Signals.c). All that function does (assuming the threaded RTS) is write the signal number and the siginfo_t structure describing the signal to a special pipe (called the control pipe, see GHC.Event.Control).

The other end of this pipe is being watched by the timer manager thread (GHC.Event.TimerManager). When awaken by a signal message from the control pipe, it looks up the handler corresponding to the signal number and, in case it’s an action, runs it in a new Haskell thread.

The signal handlers are stored in a global array, signal_handlers (GHC.Conc.Signal). When you install a signal action in Haskell, you put a stable pointer to the action’s code into the array cell corresponding to the signal number, so that the timer thread could look it up later when an actual signal is delivered.

See also https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals.

### Daniel Mlot (duplode): Applicative Archery

It is widely agreed that the laws of the Applicative class are not pretty to look at.

pure id <*> v = v -- identity pure f <*> pure x = pure (f x) -- homomorphism u <*> pure y = pure ($ y) <*> u -- interchange pure (.) <*> u <*> v <*> w = u <*> (v <*> w) -- compositionMonad laws, in comparison, not only look less odd to begin with but can also be stated in a much more elegant way in terms of Kleisli composition (<=<). Shouldn’t there be an analogous nice presentation for Applicative as well? That became a static question in my mind while I was studying applicative functors many moons ago. After finding surprisingly little commentary on this issue, I decided to try figuring it out by myself. 1

Let’s cast our eye over Applicative:

class Functor t => Applicative t where pure :: a -> t a (<*>) :: t (a -> b) -> t a -> t bIf our inspiration for reformulating Applicative is Kleisli composition, the only sensible plan is to look for a category in which the t (a -> b) functions-in-a-context from the type of (<*>) are the arrows, just like a -> t b functions are arrows in a Kleisli category. Here is one way to state that plan in Haskell terms:

> class Applicative t => Starry t where > idA :: t (a -> a) > (.*) :: t (b -> c) -> t (a -> b) -> t (a -> c) > > infixl 4 .* > -- The Applicative constraint is wishful thinking: > -- When you wish upon a star...The laws of Starry are the category laws for the t (a -> b) arrows:

idA .* v = v -- left identity u .* idA = u -- right identity u .* v .* w = u .* (v .* w) -- associativityThe question, then, is whether it is possible to reconstruct Applicative and its laws from Starry. The answer is a resounding yes! The proof is in this manuscript, which I have not transcribed here as it is a little too long for a leisurely post like this one 2. The argument is set in motion by establishing that pure is an arrow mapping of a functor from **Hask** to a Starry category, and that both (<*>) and (.*) are arrow mappings of functors in the opposite direction. That leads to several naturality properties of those functors, from which the Applicative laws can be obtained. Along the way, we also get definitions for the Starry methods in terms of the Applicative ones…

… and vice-versa:

pure x = fmap (const x) idA u <*> v = fmap ($ ()) (u .* fmap const v)Also interesting is how the property relating fmap and (<*>)…

fmap f u = pure f <*> u… now tells us that a Functor results from composing the pure functor with the (<*>) functor. That becomes more transparent if we write it point-free:

fmap = (<*>) . pureIn order to ensure Starry is equivalent to Applicative we still need to prove the converse, that is, obtain the Starry laws from the Applicative laws plus the definitions of idA and (.*) just above. That is not difficult; all it takes is substituting the definitions in the Starry laws and:

For left identity, noticing that (id .) = id.

For right identity, applying the interchange law and noticing that ($ id) . (.) is id in a better disguise.

For associativity, using the laws to move all (.) to the left of the (<*>) and then verifying that the resulting messes of dots in both sides are equivalent.

As a tiny example, here is the Starry instance of Maybe…

instance Starry Maybe where idA = Just id Just g .* Just f = Just (g . f) _ .* _ = Nothing… and the verification of the laws for it:

-- Left identity: idA .* u = u Just id .* u = u -- u = Nothing Just id .* Nothing = Nothing Nothing = Nothing -- u = Just f Just id .* Just f = Just f Just (id . f) = Just f Just f = Just f -- Right identity: u .* idA = u u .* Just id = u -- u = Nothing Nothing .* Just id = Nothing Nothing = Nothing -- u = Just g Just g .* Just id = Just g Just (g .* id) = Just g Just g = Just g -- Associativity: u .* v .* w = u .* (v .* w) -- If any of u, v and w are Nothing, both sides will be Nothing. Just h .* Just g .* Just f = Just h .* (Just g .* Just f) Just (h . g) .* Just f = Just h .* (Just (g . f)) Just (h . g . f) = Just (h . (g . f)) Just (h . g . f) = Just (h . g . f)It works just as intended:

GHCi> Just (2*) .* Just (subtract 3) .* Just (*4) <*> Just 5 Just 34 GHCi> Just (2*) .* Nothing .* Just (*4) <*> Just 5 NothingI do not think there will be many opportunities to use the Starry methods in practice. We are comfortable enough with applicative style, through which we see most t (a -> b) arrows as intermediates generated on demand, rather than truly meaningful values. Furthermore, the Starry laws are not really easier to prove (though they are certainly easier to remember!). Still, it was an interesting exercise to do, and it eases my mind to know that there is a neat presentation of the Applicative laws that I can relate to.

This post is Literate Haskell, in case you wish to play with Starry in GHCi (here is the raw .lhs file ).

> instance Starry Maybe where > instance Starry [] where > instance Starry ((->) a) where > instance Starry IO whereAs for proper implementations in libraries, the closest I found was Data.Semigroupoid.Static, which lives in Edward Kmett’s semigroupoids package. *“Static arrows”* is the actual technical term for the t (a -> b) arrows. The module provides…

… which uses the definitions shown here for idA and (.*) as id and (.) of its Category instance.

<section class="footnotes">There is a reasonably well-known alternative formulation of Applicative: the Monoidal class as featured in this post by Edward Z. Yang. While the laws in this formulation are much easier to grasp, Monoidal feels a little alien from the perspective of a Haskeller, as it shifts the focus from function shuffling to tuple shuffling.↩

Please excuse some oddities in the manuscript, such as off-kilter terminology and weird conventions (e.g. consistently naming arguments in applicative style as w <*> v <*> u rather than u <*> v <*> w in applicative style). The most baffling choice was using id rather than () as the throwaway argument to const. I guess I did that because ($ ()) looks bad in handwriting.↩

Post licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

### SPJ's Venn diagram on type-correctness

### Anonymous records in Haskell: Nikita Volkov on his solution to the records problem

### The GHC Team: GHC Weekly News - 2015/07/06

Hi *,

Welcome for the latest entry in the GHC Weekly News. The past week, GHC HQ met up to discuss the status of the approaching 7.10.2 release.

7.10.2 statusAfter quite some delay due to a number of tricky regressions in 7.10.1, 7.10.2 is nearing the finish line. Austin cut release candidate 2 on Friday and so far the only reports of trouble appear to be some validation issues, most of which have already been fixed thanks to Richard Eisenberg.

7.10.2 will include a number of significant bug-fixes. These include,

- #10521, where overlap of floating point STG registers weren't properly accounted for, resulting in incorrect results in some floating point computations. This was fixed by the amazing Reid Barton.
- #10534, a type-safety hole enabling a user to write unsafeCoerce with data families and coerce. Fix due to the remarkable Richard Eisenberg.
- #10538, where some programs would cause the simplifier to emit an empty case, resulting in runtime crashes. Fix due to the industrious Simon Peyton Jones.
- #10527, where the simplifier would expend a great deal of effort simplifying arguments which were never demanded by the callee.
- #10414, where a subtle point of the runtime system's black-holing mechanism resulting in hangs on a carefully constructed testcase.
- #10236, where incorrect DWARF annotations would be generated, resulting in incorrect backtraces. Fixed by Peter Wortmann
- #7450, where cached free variable information was being unnecessarily dropped by the specialiser, resulting in non-linear compile times for some programs.

See the status page for a complete listing of issues fixed in this release.

In the coming days we will being working with FP Complete to test the pre-release against Stackage. While Hackage tends to be too large to build in bulk, the selection of packages represented in Stackage is feasible to build and is likely to catch potential regressions. Hopefully this sort of large-scale validation will become common-place for future releases.

If all goes well, 7.10.2 will mark the end of the 7.10 series. However, there is always the small possibility that a major regression will be found. In this case we will cut a 7.10.3 release which will include a few patches which didn't make it into 7.10.2.

Other mattersIt has been suggested in #10601 that GHC builds should ship with DWARF symbols for the base libraries and runtime system. While we all want to see this new capability in users' hands, 7.10.2 will, like 7.10.1, not be shipping with debug symbols. GHC HQ will be discussing the feasibility of including debug symbols with 7.12 in the future. In the meantime, we will be adding options to build.mk to make it easier for users to build their own compilers with debug-enabled libraries.

In this week's GHC meeting the effort to port GHC's build system to the Shake? build system briefly came up. Despite the volume of updates on the Wiki Simon reports that the project is still moving along. The current state of the Shake-based build system can be found on Github.

While debugging #7540 it became clear that there may be trouble lurking in the profiler. Namely when profiling GHC itself lintAnnots is showing up strongly where it logically should not. This was previously addressed in #10007, which was closed after a patch by Simon Marlow was merged. As it appears that this did not fully resolve the issue I'll be looking further into this.

~ Ben