News aggregator

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

Having problems installing snap using cabal, on Raspberry pi 2

Haskell on Reddit - Sun, 03/22/2015 - 11:46am


I'm trying to setup a project on my Raspberry pi 2, but I'm running into some problems. I'm using arch linux ARM, which got GHC with a working GHCi. Problem occurs when it tries to install snap.

I try to do "cabal install snap" after creating a cabal sandbox, but it always end in either ErrorFailure (-4) or (-11). The install log shows me no error so I got no idea what's going on.

The weird thing is that every package I've installed except snap has worked (I've tried multiple projects). With that said I don't think there is a bug in snap since I can install it fine on my laptop.

Here is the log for "cabal install snap":

Here is my ghc-pkg list:

Can anyone see any problems? I've tried running it with -v2 or -v3 but I can't find any error there either, and the output gets insanely big.

Edit. Here it is with -v2 if that helps:

submitted by Flaiware
[link] [6 comments]
Categories: Incoming News

Getting Haskeline to quit early

haskell-cafe - Sun, 03/22/2015 - 10:09am
(I posted this to Stack Overflow [1], but no luck there so far.) Hi all, I am trying to use Haskeline [2] to write a program which asks the user a sequence of questions, each one optionally with a default value in [brackets], and reads in their responses. I want the user to be able to 1. Press Enter to submit the [default] value; 2. Type in a string, edit it if needed, and then press Enter to submit this value; 3. Press Ctrl-C to reset all values to the defaults and start over; and, 4. Press Ctrl-D or enter "quit" to quit, in which case all the values which they submitted are lost. I have been able to get points 1-3 working, but I cannot get point 4 to work: pressing Ctrl-D (or entering "quit") just brings up the next prompt instead of making the program quit the questioning. Looking at my program (please see below) I understand why this happens, but I am not able to figure out how to fix this so that Ctrl-D (or "quit") actually makes the questioning stop. How do I fix the program to make this happen?
Categories: Offsite Discussion

time and TimeLocale compatibility

haskell-cafe - Sun, 03/22/2015 - 10:03am
Hello all, The `formatTime` function from time-1.4 uses the TimeLocale type from old-locale, whereas time-1.5 provides its own definition of the TimeLocale type. I want to provide `formatTime` with the argument `defaultTimeLocale`. 1.4 requires the version in old-locale whereas 1.5 requires the version it defines itself. Is it possible to use this function in a way that is compatible with both 1.4 and 1.5? If time-1.5 had merely reexported the old-locale version, and then (the future) time-1.6 replaced it completely this would have offered a smoother upgrade path, but as far as I can tell nothing like this was done. What are my options? Tom
Categories: Offsite Discussion

netwire example error message

haskell-cafe - Sun, 03/22/2015 - 5:57am
The error message: time.hs:13:8: No instance for (Show e0) arising from a use of ‘testWire’ The type variable ‘e0’ is ambiguous Note: there are several potential instances: instance Show Double -- Defined in ‘GHC.Float’ instance Show Float -- Defined in ‘GHC.Float’ instance (Integral a, Show a) => Show (GHC.Real.Ratio a) -- Defined in ‘GHC.Real’ 45 others In the expression: testWire clockSession_ pos In an equation for ‘main’: main = testWire clockSession_ pos Failed, modules loaded: none. So here's my type debugging. (netwire sure is convoluted) pos => Wire s e m a Float integral => a -> Wire s e m a a clockSession_ => Session m (Timed NominalDiffTime ()) looks to me like the problem is probably rooted in the interaction of pos with (Timed NominalDiffTime) as it does not seem to have a float instance, but that doesn't seem like it should result in an error about ambiguity. Any help appreciated. Thanks Brian ----
Categories: Offsite Discussion

Keeping argument names around in Haddock?

Haskell on Reddit - Sun, 03/22/2015 - 4:06am


I'm wondering why Haddock is keeping around only the types and not the names of function arguments. For signatures like [1] I always have to go the code to understand what's what. To me this seems like we're throwing away information for no good reason?


generateParams :: CPRG g => g -> Int -> Integer -> (Params, g) generateParams rng bits generator = [...]

submitted by realteh
[link] [42 comments]
Categories: Incoming News

How to use formatTime with time-1.4 and 1.5?

Haskell on Reddit - Sun, 03/22/2015 - 3:10am

Does anyone know how to use defaultTimeLocale in a way that is compatible with both time-1.4 and time-1.5? I am afraid I need a clue.

submitted by tomejaguar
[link] [8 comments]
Categories: Incoming News

wither the Platform

libraries list - Sat, 03/21/2015 - 6:54pm
I'm wondering how we are all feeling about the platform these days.... I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second option) pretty much steers folks away from it. Of the per-OS download pages, only the Windows version even mentions it. Does this mean that we don't want to consider continuing with it? It is a lot of community effort to put out a Platform release - we shouldn't do it if we don't really want it. That said, I note that the other ways to "officially get" Haskell look, to my eye, very ad hoc. Many of the options involve multiple steps, and exactly what one is getting isn't clear. It hardly looks like there is now an "official, correct" way to setup Haskell. The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new fea
Categories: Offsite Discussion

Continuation vs Codensity

haskell-cafe - Sat, 03/21/2015 - 3:32pm
I just saw this Personally, I think the suggested type for callCC newtype ContT m a = ContT { runContT :: forall r. (a -> m r) -> m r } class MonadCont m where callCC :: (forall b. (a -> m b) -> m b) -> m a is much more intuitive and resembles the actual type of ContT much more closely then the current callCC and it can be Fixed. So I was wondering if there was an other reason than convention for not using that type. Silvio
Categories: Offsite Discussion

On adding FlexibleContexts to please GHC 7.10

Haskell on Reddit - Sat, 03/21/2015 - 2:20pm

Switching to GHC 7.10 may cause code which was working fine with GHC 7.8 to fail with an error message which suggests to add the FlexibleContexts extension. Adding the extension will indeed cause the error message to disappear, but I would like to argue that this might not be the fix you want.

First of all, nothing bad will happen if you do choose to add FlexibleContexts and call it a day, in the sense that no new regressions will be introduced. That's because the cause of the error message (thanks /u/bgamari!) isn't that some newly-generalized BBP function is now too generic for your code, it's that your code was already implicitly using FlexibleContexts. More precisely, your code has a function which lacks an explicit type signature, and its inferred type requires FlexibleContexts. GHC now requires language extensions for those inferred types as well.

That being said, I believe that a better fix would be to add an explicit type signature to those functions. In the two cases I have encountered so far, the function's inferred type was more polymorphic than what was intended, ghc's error uncovered that small mistake, and adding FlexibleContexts hid the mistake again.

The first case I encountered (thanks /u/adituv!) was a mistake in my own code. I had an [Either ByteString String], and I wanted to find the elements which begin with "module ". Here's a simplified version of the code:

{-# LANGUAGE OverloadedStrings #-} import Data.List import qualified Data.ByteString.Char8 as B type StringLike = Either B.ByteString String findModuleLines :: [StringLike] -> [StringLike] findModuleLines = filter (beginsWithModule) beginsWithModule (Left s) = "module " `B.isPrefixOf` s beginsWithModule (Right s) = "module " `isPrefixOf` s

What's the inferred type of beginsWithModule?

> :t beginsWithModule beginsWithModule :: (Data.String.IsString [a], Eq a) => Either B.ByteString [a] -> Bool

That's much more polymorphic than I need. I could add FlexibleContext to allow the IsString [a] in the inferred type, but I'd rather simply add a type signature to specify that this [a] is simply String:

beginsWithModule :: StringLike -> Bool beginsWithModule (Left s) = "module " `B.isPrefixOf` s beginsWithModule (Right s) = "module " `isPrefixOf` s

The other case I encountered was in the stringsearch package (again thanks to /u/adituv). Here's a simplified version of the problematic code:

import Data.Array.ST import Data.Array.Unboxed replicateAbc :: Int -> UArray Int Char replicateAbc n = runSTUArray $ do ar <- newArray (1, n) 'a' let fillAbc i _ | i > n = return ar fillAbc i 'a' = writeArray ar i 'a' >> fillAbc (i+1) 'b' fillAbc i 'b' = writeArray ar i 'b' >> fillAbc (i+1) 'c' fillAbc i 'c' = writeArray ar i 'c' >> fillAbc (i+1) 'a' fillAbc 1 'a'

We're creating an array of a given length whose contents is "abcabcabc...", using an imperative loop. The resulting type UArray Int Char is an immutable unboxed array, while inside the runSTUArray block, ar has type STUArray s Int Char, indicating that it is not immutable, as it can be modified inside the ST monad.

What is the type of fillAbc? It's an ST computation which returns ar, so its type is clearly intended to be ST s (STUArray s Int Char), but since we didn't specify a type signature, its inferred type is more polymorphic than that.

There are multiple types of mutable arrays, which can be modified in different monads. For this reason, writeArray is polymorphic in m, subject to a constraint MArray a e m. For fillAbc, this constraint becomes:

fillAbc :: MArray (STUArray s) Char m => Int -> Char -> m (STUArray s Int Char)

Just as [a] was more structured than a simple type variable and thus requires FlexibleContext when it appears in a constraint, so does STUArray s. But there is another problem: fillAbc is not polymorphic in s, it only works with the specific, rigid s which was used to create ar. So this time, it is not sufficient to simply give a type signature to fillAbc, it is also necessary to bind s in the outer scope, using the ScopedTypeVariables extension. Since I want to give fillAbc a more specific type which doesn't need a constraint, I don't need FlexibleContexts.

{-# LANGUAGE ScopedTypeVariables #-} import Control.Monad.ST import Data.Array.ST import Data.Array.Unboxed replicateAbc :: Int -> UArray Int Char replicateAbc n = runSTUArray go where go :: forall s. ST s (STUArray s Int Char) go = do ar <- newArray (1, n) 'a' let fillAbc :: Int -> Char -> ST s (STUArray s Int Char) fillAbc i _ | i > n = return ar fillAbc i 'a' = writeArray ar i 'a' >> fillAbc (i+1) 'b' fillAbc i 'b' = writeArray ar i 'b' >> fillAbc (i+1) 'c' fillAbc i 'c' = writeArray ar i 'c' >> fillAbc (i+1) 'a' fillAbc 1 'a'

I have only encountered those two cases, but since many of us are simply accepting GHC's suggestion and adding FlexibleContexts, I wanted to remind you all to take a moment to verify if that's really the fix you want.

submitted by gelisam
[link] [6 comments]
Categories: Incoming News

Wither the Platform

Haskell on Reddit - Sat, 03/21/2015 - 12:23pm
Categories: Incoming News

Need something like convex hull / alpha shapes / voronoi (but not exactly) in haskell.

Haskell on Reddit - Sat, 03/21/2015 - 11:08am

I'm still a bit of a beginner in Haskell. I've been reading the Real World Haskell book a lot lately, and had quite a bit of fun with the Graham Scan / Convex Hull problem.

Now I've encountered a problem at work where this little bit of experience with Haskell could actually be very useful in "the real world", if it weren't for the fact that the challenge at hand is a bit more convoluted

I have a list of about 12 million coordinate pairs (2D) in a bunch of files (mostly JSON, but I can easily change that), each with a 3rd "class" property. These points lay in contiguous clouds, which do not necessarily form convex hulls... just shapes. They do not cut each other off, but do have various densities, sizes and shapes.

A good metaphor would be the locations of houses with people who speak a certain language, on a planet where countries do not exist yet, and now we have to decide where to draw the country borders between those groups of people.

Or, in terms of a haskell function: I just need to get a list of polygons (which are lists of 2D vertexes) from this data, so something like a [[(x,y)]] type. Although, It would probably also be useful to preserve the classname of the vertexes for every polygon, so probably more something like [([(x,y)],[Char])].

Or, eventually probably just a JSON file with some logical structure so it's easier to visualize in our applications.

Some starting points:
I first found info on alpha shapes, which forms a convex hull and "eats" away some of the bits using a radius parameter. If a convex hull is like spanning an elastic band/balloon around a bunch of points, then an alpha shape is (kind of) like sucking some of the air out so concavity is possible in large enough areas -- the radius parameter just tells you how thorough it's gonna be.

But alpha shapes could also "eat" holes into the polygons (especially in less dense inner areas), and besides that, it would be preferable if polygons shared borders instead of leaving "demilitarized zones" in between.

Maybe something like a voronoi diagram, except merging adjacent polygons which have an identical class?

I'm not specifically asking for anyone to solve this for me (that's no fun), but any input, pointers or similar cases implemented in Haskell would be awesome.

submitted by fx32
[link] [12 comments]
Categories: Incoming News

Thiago Negri: Using Facebook's Flux architectural style for game development in Unity 3D

Planet Haskell - Sat, 03/21/2015 - 9:23am
I decided to work again in an old game project. The game is named "Shotem" and the mechanic is quite simple: coins start falling from the sky and you need to "shot them" (got it?). Tap on a coin to shoot it, you gain score if you hit and you lose score if you miss the shot or if a coin falls off the screen (in case you didn't tap it). You have seven bullets to use, each shot (finger tap) consumes a bullet and you need to shake the mobile device to reload your bullets.

The game is still a work in progress, but I added the following video in order to show that it actually works in real life:

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="" width="420"></iframe>

I'll write the history of the development process of this game. It started in a very naive form, then I converted it to Flux style and left it alone for three months. Now I'm coming back to it and had a pleasant surprise to read the code after forgetting about it. I think Flux style made it easy to continue the project were I left it. This post is 100% opinion based. Please, take a seat.

The first version I coded was very straightforward. Each coin was a GameObject with rendering and game behavior logic. All game state were inside a Singleton and two other objects were responsible for creating coins and handling user taps. Not organized at all.

I was interested in how to code the "reload by shaking" feature. As soon as I got it working, I lost my interest in the game mechanic itself. This happened quite fast actually, Unity 3D has a very nice class to use for dealing with the mobile device gyroscope: Input.gyro.

At the same time, I got in touch with Facebook's Flux architectural style. I tried it in some web projects and had a nice feeling about it. It seemed easier to write, maintain and understand code written in Flux style than the code written in MVC fashion. So, I decided to rewrite the code of Shotem in Flux style.

At first, it didn't seem to fit into Unity's way of doing things. But I worked it out and coded it anyway. It worked fine, then I left the code alone.

Three months later I'm coming back to this project and I didn't remember that I tested Flux style in it. At first I thought: "oh no, I'll need to delete this project and start it over, why did I do it?" Then I did read the code and look at the project structure: I was amazed at how easy it was to get things back on track, I were able to get productive again in less than five minutes! What a pleasant surprise!

Now, I feel that I should share this with the rest of the world. I appreciate feedback, so if you feel that using Flux style in game development is madness or if you feel like giving it a try too, leave a comment.

From now on, I'll use some terms from Flux, e.g. Store, Dispatcher, Action. I won't explain what are their meanings, so feel free to take a little detour and read the official Facebook's Flux website to get a summary of it.

I created a Dispatcher class to register the Stores, dispatch actions, track dependencies between Stores and ensure that the Actions do not cascade. The Dispatcher, in it's full glory, is here:

<script src=""></script>

The core game mechanic is encoded in three Stores: CoinStore, handling all coins in the game; GunStore, handling player's ammunition; ScoreStore, tracking user score.

Player input may dispatch two Actions in the game: ShootAction and ReloadGunAction. To handle the physics of the game (falling coins), one Action is sent every FixedUpdate: PhysicsUpdateAction.

The Stores handle each action according to simple rules:

PhysicsUpdateAction is handled by CoinStore by spawning new coins, moving the coins in the screen and removing coins that are off the screen. ScoreStore waits for the CoinStore to finish and then updates the score by decrementing the amount of coins that were removed from CoinStore, because they have fallen off the screen. GunStore ignores this action.

ShootAction is handled by GunStore by decrementing player's ammunition. CoinStore waits for the GunStore and ignores the action if no ammunition was used, otherwise it checks for overlapping coins in the shot area and removes them. ScoreStore waits for GunStore and CoinStore then increases the score by each coin removed or decreases the score in case an ammunition was used and no coin was removed.

ReloadGunAction is handled by GunStore to reset the player's ammunition to seven. CoinStore and ScoreStore ignores this action.

That's the whole game logic. Each Store is observable, the Views register themselves to receive update notifications. When the Store handles an Action that changes its state, it triggers a notification. I've created an abstract class Store to handle this common behavior:

<script src=""></script>

The listing below is the code of ScoreStore, the other Stores follow the same style:

<script src=""></script>

Setup code is done in a Singleton GameObject's Awake method, I called it StoreHub because I use this to get the reference to the Stores from other Views:

<script src=""></script>

ShotemActionGenerator is a helper class to create Actions and send them to Dispatcher, nothing fancy.

The View classes are also simple, for example, the game may play three different sound effects when the GunStore is updated: when a bullet is shot, when user tries to shot without ammunition left and when the gun is reloaded:

<script src=""></script>

Another view shows the quantity of ammunition remaining, which are just children GameObjects with Renderers that I enable or disable based on the GunStore state:

<script src=""></script>

There is a View to show the score, one to show a tip to remind the player to reload the gun when it's empty, another to handle the renderers of each coin visible in the screen, etc. The entire game is made in the same solid base, or may I say "solid flux". Data always flows in a single direction without cascading, there is always an Action that enters the system and triggers something, nothing happens if no Action is dispatched.

I don't know if this design can scale to a big game project, as the style as it is now depends on it running in a single core. But, none of my games are that intense, so I will try to finish this game with Flux. I guess that using Flux will also make it easier to create automated tests of the game mechanic, as it is self-contained. Maybe I'll post some follow up thoughts on it.

Below is an overview image of the current flux of the game. I decided to call "Inception" the layer that generates the Actions, Flux do not give it a name.

Thanks for your time,
Categories: Offsite Blogs