News aggregator

Splices returning splices

glasgow-user - Mon, 03/23/2015 - 1:47pm
Hello, I'm attempting to write a quasiquoter with relatively full antiquotation support. In doing so, I've arrived at I think an odd problem: the expression grammar in Language.Haskell.TH.Syntax doesn't seem to include splices. This seems to mean that my antiquotations can't themselves include splices, which is quite limiting. Am I misinterpreting? The type system in "Template metaprogramming for Haskell" seems to imply no such restriction on the occurrences of splices. (As an additional complication: what I really need to do is return typed splices; my "quasiquoter" relies on its expected type to determine its behavior. However, this seems like an uninteresting extension of the above problem.) Thanks, /g
Categories: Offsite Discussion

X-Post: Thinking in Types

Haskell on Reddit - Mon, 03/23/2015 - 1:24pm
Categories: Incoming News

Why isn't the cabal install default to reinstall broken packages?

Haskell on Reddit - Mon, 03/23/2015 - 11:48am

When you try to reinstall a package in cabal-install (either directly or because the solver came up with an install plan that requires reinstalls) why is the default to just list broken packages instead of attempting to reinstall them and potentially other packages broken by their reinstall?

Alternatively why doesn't the solver incorporate the information in the world file about the user's desired package set to attempt to find a set of package versions for all those (world and the targets given on the command-line) that would be compatible and then use reinstalls as necessary to get there (if possible)?

Wouldn't either of those solve a large part of the issues outdated packages in the global package database cause today? Of course we might spend some extra time compiling for the reinstalls but we already do that today with sandboxes.

submitted by Taladar
[link] [20 comments]
Categories: Incoming News

99 Haskell - Mon, 03/23/2015 - 10:09am
Categories: Offsite Blogs

Abstract Binding Trees

Haskell on Reddit - Mon, 03/23/2015 - 9:43am
Categories: Incoming News

What's the recommended way of sending Haskell data to a client in the browser without going via XML/Json/Yaml?

Haskell on Reddit - Mon, 03/23/2015 - 8:45am

I currently have a web application based on Node.js. On the server side, there's some Haskell code producing some data, which I need to send to the client. Because the client side is in JavaScript, I have to reimplement the parsing of the data exported to XML and the whole API for manipulating it and suffer all consequences of dealing with the evolution on the Haskell side and having to manually keep the client side processing synchronized.

So I looked around and I was amazed reading Happstack, Fay, & Acid-State: Shared Datatypes are Awesome - that's exactly what I need - take the module from my server-side Haskell code with the data types and API and compile it to JavaScript and integrate into the existing JavaScript on the client-side. Except that I cannot rewrite the whole server Node.js part into Happstack, nor Haste, nor anything else.

So, the question is: how can I gradually generate some JavaScript for my data definitions and API, incorporate it to the client and have the serialization/deserialization problem transparently solved without going via XML/Json/Yaml? Something like what Haste provides.

EDIT: the JavaScript on the server simply calls an executable written in Haskell. So, the executable must somehow serialize the data so that it can be sent to the client and transparently deserialized.

EDIT2: looking into websockets. Fay could receive a Binary message from a websocket, the Haskell executable could serialize the data to Binary, and Node.js server could simply send it. Does anybody have any experience with such an approach?

EDIT3: what looks quite nice and lightweight to me is the example with websockets and fay by /u/ocharles. The first shows server-side with JS client, the second shows to how replace the hand-written client with Fey-generated one.

submitted by mallai
[link] [9 comments]
Categories: Incoming News

Fixing Fix

libraries list - Mon, 03/23/2015 - 4:01am
There are a good number of different packages that define either newtype Fix f = Fix (f (Fix f)) or something equivalent except for naming. Most of the name variation is in the name of the data constructor and/or record selector. This does not look like an ideal situation to me. Most problematically, the only way to convert one to another is with unsafeCoerce. I think it would be rather nice to choose one canonical place for this definition, and let everyone else use it. Ideally, it would be nice to use some GHC pattern magic and such to paper over the differences between the data constructor names, but I don't know if that's possible or not. David Feuer
Categories: Offsite Discussion

ANN: Lambdabot 5.0.1

haskell-cafe - Mon, 03/23/2015 - 3:26am
Dear Haskell users, I'm pleased to announce a minor release of Lambdabot. Lambdabot is an IRC bot that can also be used offline; it provides tools for querying information about and even for producing Haskell code. To install it, use the following command: cabal install lambdabot --constraint 'transformers installed' (the constraint helps cabal-install to find an install plan) * What's new - lambdabot is now smarter about locating its data files. This means that commands like < at >src now work out of the box, without having to copy files into ~/.lambdabot/State - lambdabot-5.0.1 uses (and requires) monad-control 1.0 * Development Development of lambdabot happens on github, where you can also find the bugtracker: Have fun with lambdabot, Bertram
Categories: Offsite Discussion

Loop School - Mon, 03/23/2015 - 2:24am
Categories: Offsite Blogs

Neil Mitchell: Finding a GHC bug

Planet Haskell - Sun, 03/22/2015 - 4:05pm

Summary: I found a nasty bug in GHC 7.10 RC3. It's been fixed.

For Shake, I have an extensive test suite (2500+ lines of tests). I also test on 7 GHC versions, including GHC HEAD. After adding GHC 7.10 Release Candidate 3 to the mix one of the tests started failing. A week later the bug has been simplified, diagnosed and fixed as bug #10176. Below is a tale of how that happened, including a technical explanation of the bug in Step 8.

Step 1: Write a lot of tests

The Shake test that caught this particular bug checks that if the user makes a mistake then the error message must contain certain substrings correctly identifying the problem. With GHC 7.10 RC3 on Travis this test stopped throwing an exception entirely, continuing as though nothing were wrong. Weird.

Step 2: Reproduce locally

I tried to reproduce the failure locally, which ended up spotting a fatal bug in the GHC 7.10 RC3 32bit Windows version. After opting for the 64bit version, at first I couldn't reproduce the error. Eventually I realised that you needed to turn on optimisation (at -O1), and that running through ghci (how I usually develop Haskell) didn't cause the problem. Noticing that -O1 was required gave me a clue, that it was related to an optimisation. The typical cause of programs that work without optimisation but fail with it are programs that raise exceptions in pure code (since the exception can change due to optimisations) or those that call unsafePerformIO (it has unsafe in the name for a reason). I certainly do both those things in Shake, but I wasn't aware of anywhere I did them in a dubious manner.

Step 3: Reduce the test case

I spent a lot of time trying to reduce the test case. By inserting print statements I narrowed the place the difference was happening to Development.Shake.Core.applyKeyValue, which is a pretty core bit of Shake. However, while I was able to chop out a lot of auxiliary features (lint tracking, command tracing) the actual code remained difficult to reduce to any great extent, for two reasons. Firstly, the bug was incredibly fragile - moving a monomorphic NOINLINE function from one module to another made the bug disappear. Secondly, the applyKeyValue function is right in the middle of Shake, and the test required a few successful Shake runs to set up things for the failing test, so I couldn't change its observable semantics too much.

What I did conclude was that Shake didn't seem to be doing anything dodgy in the small patch of code that seemed relevant, giving me the first hint that maybe GHC was at fault, not Shake.

Step 4: Differences at the Core level

At this point, I reached out to the GHC mailing list, asking if anyone had any ideas of a culprit. They didn't, but Simon Peyton Jones suggested finding the smallest breaking change and comparing the generated Core. You can do that by compiling with -ddump-simpl, and adding -dsuppress-all -dsuppress-uniques to get something a bit easier to diff. Fortunately, by this point I had a very small change to make the error appear/disappear (moving a function from one module to another), so the difference in Core was tiny. The change in the problematic version read:

case (\_ -> error "here") of {}

In GHC Core a case always evaluates its scrutinee until it has the outermost value available (aka WHNF). The empty alternatives mean that GHC has proven that the evaluation always results in an exception. However, a lambda already has a value available (namely the lambda) so evaluation never throws an exception. As a result, GHC has violated the rules of Core and bad things happen.

Step 5: Reducing further

In order to reduce the bug further I now had a better test, namely:

ghc Core.hs -O -ddump-simpl | grep -F "case (\\"

With this test I didn't have to keep the internals of Shake working, and in fact didn't even have to provide a runnable entry point - all I had to do was look for the dodgy construction in the Core language. Note that I'm not actually looking for case of a lambda with empty alternatives, reasoning (seemingly correctly) that any case on a lambda with non-empty alternatives would be eliminated by the GHC simplifier, so any case followed by lambda is buggy.

I reduced by having a ghcid Window open in one corner, using the warnings -fwarn-unused-binds and -fwarn-unused-imports. I hacked out some part of the program and then patched everything up so it no longer raised an error using ghcid for rapid feedback. I then ran the grep test. If the bug had gone I put the program back to how it was and tried somewhere else. If the bug remained I then cleaned up the now redundant declarations and imports and checked again, repeating until the code was minimal.

Several hours later I was left with something like:

buggy :: (() -> Bool) -> () -> Bool -> IO ()
buggy fun unit bool =
runReaderT (
(if bool then liftIO $ print () else p) >>
(if fun unit then error2Args unit unit >> p else p)) ()

{-# NOINLINE error2Args #-}
error2Args :: () -> () -> a
error2Args _ _ = error "here"

Note that error2Args must be in a different module to buggy.

Step 6: Bisecting

At this point hvr stepped in and bisected all the changes between GHC 7.10 RC2 and RC3, determining that a large Typeable change introduced the bug in the original shake test case. However, using the minimal program, the bug was also present in GHC 7.10 RC2. That suggested the bug might have been around for a while.

Step 7: Augmenting GHC's Lint Checker

GHC already has a pass in the compiler, enabled with -dcore-lint, which checks for dodgy constructs in the Core language. Enabling it didn't pick up this example (hence I used grep instead), so Joachim Breitner added such a check. He also added the example as a test case, so that if it ever breaks in future things it will be spotted immediately.

Step 8: Diagnose and Fix

Joachim then continued to diagnose and fix the issue, the details of which can be found in the patch. The problem (as I understand it) is that GHC looks at the code:

fun x = error "foo" x

And concludes two facts.

  1. If fun is called with one argument then the code will raise an error. That's true, and allows the compiler to replace fun () () with fun ().
  2. After analysing all calls of fun it spots that fun is always called with two arguments, so it is free to change fun to be fun x y = error "foo" x y.

By applying these two facts, we can make the transformation:

case fun () () of {}
-- apply the first rule
case fun () of {}
-- inline fun after applying the second rule
case (\x y -> error "foo" x y) () of {}
-- beta reduce:
case (\y -> error "foo" () y) of {}

Now we have caused invalid Core to be produced. While the two facts are each individually correct, applying the first fact causes the second fact to stop being true. Joachim fixed this by making the call argument count analysis stop at the first argument that guarantees an error.

Step 9: The Impact

The manifestation of the bug is quite interesting. Essentially GHC decides something is an error, but then fails to actually throw the error. As a result, any code the simplifier places after the error call will be eliminated, and that can remove a large chunk of the program. However, any code the simplifier doesn't manage to hoist next to the code will still get run, even though it should have been skipped due to an error. In essence, given exactly the wrong conditions to trigger the bug, you can write:

main = do
putStrLn "here1"
... error "foo" ...
putStrLn "here2"
putStrLn "here3"

And end up with the program printing here1 followed by here3, without throwing an exception. In the case of my original Shake test it started to compile, should have stopped with an error but instead just skipped compiling altogether and went on to do the bits after compiling. A very weird manifestation.

Disclaimer: I've eliminating many missteps of mine, which included pushing random patches to try and reduce on the Travis machine and installing a Linux VM.

Categories: Offsite Blogs

Template Haskell question, interacting values and types.

Haskell on Reddit - Sun, 03/22/2015 - 3:24pm

I'd like to be able to use Haskell functions evaluated at compile time to create expressions of kind Nat, with the evaluated value. Something like:

$(mkNat (fibonacci 8))

Should create a value for something like (Proxy :: Proxy (13 :: Nat))

Is this possible? If so, any tips on how to do it? My problem lies in convincing GHC to make an Exp into a Type. No tutorial I've seen on TH seem to show how to do something like this.

/Thanks for any help :)

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

Munich Haskell Meeting, 2015-03-25 < at > 19:30

haskell-cafe - Sun, 03/22/2015 - 3:13pm
Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Wednesday, March 25 at Cafe Puck at 19h30. For details see here: If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. Everybody is welcome! cu,
Categories: Offsite Discussion

GSoC Proposal: Refactor program with HLintsuggestions

haskell-cafe - Sun, 03/22/2015 - 2:12pm
Dear Café, I would appreciate any comments on the proposal I have written for this years GSoC. The proposal focuses on an oft-requested feature, the ability for HLint to perform the refactorings which it suggests. I believe this is now possible with the work that Alan Zimmerman has recently completed on ghc-exactprint. More details can be found here - (There is also a pdf version available - Matt _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

Philip Wadler: Status Report 4

Planet Haskell - Sun, 03/22/2015 - 1:44pm

It seemed as if no time had passed: the anaesthetist injected my spine, and next thing I knew I was waking in recovery.  Keyhole surgery to remove my left kidney was completed on Tuesday 17 March, and I expect to leave the Western General on Saturday 21 March. Meanwhile, progress on diagnosing the amyloid spotted in my liver: I had a bone marrow biopsy on Thursday 19 March, and two days of testing at the National Amyloidosis Centre in London are to be scheduled. NHS has provided excellent care all around.

My room was well placed for watching the partial eclipse this morning. A nurse with a syringe helped me jury rig a crude pinhole camera (below), but it was too crude. Fortunately, there was exactly the right amount of cloud cover through which to view the crescent sun. My fellow patients and our nurses all gathered together, and for five minutes it was party time on the ward.

Update: I left the hospital as planned on Saturday 21 March. Thanks to Guido, Sam, Shabana, Stephen, and Jonathan for visits; to Marjorie for soup; to Sukkat Shalom council for a card and to Gillian for hand delivery; and to Maurice for taking me in while my family was away.

Related: Status report, Status report 2, A paean to the Western General, Status report 3.

Categories: Offsite Blogs