News aggregator

About my commitment to my passions,Haskell and the world

haskell-cafe - Wed, 06/17/2015 - 2:49am
Hi everybody, I have a very important announcement. I’ve decided to dedicate the next big part of my life to improve the world through Haskell. And you can help! (I’m not asking for money…) I plan to go to live at a “poor” village where my grandparents live. Poor because it is very hard to get a higher education. My grandfather founded some time ago some schools nearby the village, but if people wanted to have a bright future, they had to leave the village. My father moved to the nearest capital city. The story repeated. My father and my mother (together with other people) founded a school at the city where I was born. I left this city to get an even higher education at one of the best universities of my continent. At college, I got the opportunity to study a year as an exchange student at one of the best CS universities in the world. Knowing that probably I would never be able to study at such a good university again, I took the hardest subjects I could. The first semester, I took 2 undergrad
Categories: Offsite Discussion

library/framework suggestions for a REST API in Haskell

Haskell on Reddit - Tue, 06/16/2015 - 11:31pm

I am currently writing a REST API in Haskell using Yesod. I really like Yesod (and will continue using it for future projects), but it seems a little heavy for a simple REST API.

I'm currently evaluating other possible solutions. After some research it seems like there are generally two approaches people take.

The first approach is to use a REST library/dsl. There seem to be three popular packages following this approach:

The second approach is to use a lightweight web framework and write the REST API yourself. There seem to be three popular web frameworks often used when following this approach:

What are you using to write your RESTful APIs? I would be very interested in any sort of comparison between rest/servant/restful-snap or spock/snap/scotty.

Also, how are you doing authentication for your REST apis?

Edit: There was a similar thread a couple months ago

submitted by cdep_illabout
[link] [39 comments]
Categories: Incoming News

I'm working on an API wrapper (client) for a REST API web service.

Haskell on Reddit - Tue, 06/16/2015 - 10:14pm

I'm working on an API wrapper for a web REST API service. I've done some of the work, that is created the entities-models and the CRUD methods. They are working properly. Now I have to move on and create an interface for a consumer for my library to actually use it. But I can't figure out

  1. How can I organize the files (hierarchy) better? I mean, should there be the modules such as MyLib/Types/..., MyLib/Client/... and something?

  2. What's the best and easier way to allow a consumer to provide their api key or login/password? The config file? Or something else?

And I have other questions.

I'm looking for decent tutorial explaining how to do all this. I found one at fpcomplete but it was quite small and didn't explain all I wanted.

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

Trying to work with MVars

Haskell on Reddit - Tue, 06/16/2015 - 8:16pm

I am having a problem while using MVars: in short my code that (seemingly) should not leave an MVar empty is failing to do so, and causing an eventual exception.

I have posted this problem on stack overflow, if anyone could take a look it would be greatly appreciated: http://stackoverflow.com/questions/30881229/thread-blocked-indefinately-in-an-mvar-operation

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

Postdoc position in parallel/distributed functionalprogramming

General haskell list - Tue, 06/16/2015 - 5:37pm
Indiana University invites applications for a postdoctoral position in the programming languages research cluster (http://lambda.soic.indiana.edu/) with a possible dual affiliation with the Center for Research on Extreme Scale Technologies (CREST, http://crest.iu.edu/). The position is in Prof. Newton's research group and will emphasize parallel functional programming. Our group works on all aspects of parallel programming libraries and languages. One theme is extending and improving guaranteed-deterministic programming environments. Typical research projects include either (1) improvements to the GHC Haskell compiler, runtime, and library ecosystem or (2) work on domain-specific languages and compilers, frequently embedded in Haskell, and targeting backends like CUDA, LLVM, or OpenCL. Experience with any of the following would be a positive: Haskell development, GHC internals, compiler construction, FRP or stream processing, parallel programming and performance tuning, and purely functional parallelism.
Categories: Incoming News

Skip OS network stacks by using HalVM?

Haskell on Reddit - Tue, 06/16/2015 - 3:30pm

Reading this there seems to be a trend to skip the OS network stack to achieve high package per second ratings. I wonder if someone has tried something like this with HalVM?

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

Dimitri Sabadie: Asset management in a real time 3D engine in Haskell

Planet Haskell - Tue, 06/16/2015 - 1:01pm
Foreword

In a real time rendering system, it’s not uncommon finding constructs about assets. One famous construct is the resource manager. A resource manager is responsible of several tasks, among:

  • providing a simple interface to load objects from disk (1) ;
  • ensuring we don’t try to load the same object twice (2) ;
  • resolving dependencies between resources (3).

The first point is obvious, but the two others are less intuitive. (2) is important when the user might try to load the same object several times – for instance, a car model, or a character or a weapon. The most known strategy to prevent such a situation from happening is by using a software cache.

A software cache – let’s just say cache – is an opaque object that loads the object on the first request, then just returns that object for future same requests. For instance, consider the following requests and the corresponding cache behavior:

  1. load "wood.png" -> not cached ; loading ; return
  2. load "grass.png" -> not cached ; loading ; return
  3. load "wood.png" -> cached ; return
  4. load "metal.png" -> not cached ; loading ; return
  5. load "metal.png" -> cached ; return
  6. etc.

That behavior is very nice because it will spare a lot of computations and memory space.

(3) is about dependencies. For instance, when you load a car model, you might need to load its textures as well. Well, not really load. Consider the following:

  1. load "car.mesh" -> not cached
    1. load "metal_car.png" -> not cached ; loading ; return
    2. loading ; return
  2. load "metal_car.png" -> cached ; return
  3. load "other_car.mesh" -> not cached
    1. load "metal_car.png" -> cached ; return
    2. return
  4. load "car.mesh" -> cached ; return

You got the idea. (3) needs (2) to be efficient.

Possible implementationsSingleton

In imperative languages and especially in those that support template and/or generics, people tend to implement the cache system with an ugly design pattern – which is actually an anti design pattern : singleton. Each type of resource is assigned a manager by using a template parameter, and then if a manager needs to load a dependency, it just has to reference the corresponding manager by stating the type in the template parameter :

Model & getResource<Model>(std::string const &name) {
Texture &dependency = getResource<Texture>(...);
...
}

That way of doing might sound great, but eh, singletons are just global variables with a unicity constraint. We don’t want that.

Explicit pure store

We can use an explicit store object. That is, some kind of map. For instance, the store that holds textures would have a type like (in Haskell):

textureStore :: Map String Texture

A model store would have the following type:

modelStore :: Map String Model

And each stores is assigned a function; loadTexture, loadModel, and so on.

There are several drawbacks if we go that way. First, we have to carry all stores when using their functions. Some functions might need other stuff in order to resolve dependencies. Secondly, because of explicit state, we need to manually accumulate state! A loading function would have such a following type:

loadTexture :: Map String Texture -> String -> m (Texture,Map String Texture)

That will expose a lot of boilerplate to the user, and we don’t want that.

Implicit pure store

We can enhance the explicit store by putting it into some kind of context; for instance, in MonadState. We can then write loadTexture to make it nicer to use:

loadTexture :: (MonadState (Map String Texture) m,...)
=> String
-> m Texture

There is a problem with that. What happens when we add more types? For instance if we want to handle textures and models? MonadState has a type family constraint that forbids two instances for the pair s m. The following is not allowed and will raise a compiler error:

instance MonadState (Map String Texture) MyState where
...

instance MonadState (Map String Model) MyState where
...

The solution to that problem is to have the carried state a polymorphic type and use typeclass constraint to extract and modify the map we want:

class HasMap a s where
extractMap :: s -> Map String a
modifyMap :: (Map String a -> Map String a) -> s -> s

With that, we can do something like this:

loadTexture :: (MonadState s m,HasMap Texture s,...)
=> String
-> m Texture

loadModel :: (MonadState s m,HasMap Texture s,HasMap Model s,...)
=> String
-> m Model

However, we hit a new issue here. What are s and m? Well, m doesn’t really matter. For simplicity, let’s state we’re using a monad transformer; that is, we use StateT s m as monad.

We still need s. The problem is that s has to be provided by the user. Worse, they have to implement all instances we need so that the loading functions may work. Less boilerplate than the explicit store solution, but still a lot of boilerplate. Imagine you provide a type for s, like Cache. Expending the cache to support new types – like user-defined ones – will be more extra boilerplate to write.

Closures

The solution I use in my engine might not be the perfect solution. It’s not referentially transparent, an important concept in Haskell. However, Haskell is not designed to be used in convenient situations only. We’re hitting a problematic situation. We need to make a compromise between elegance and simplicity.

The solution required the use of closures. If you don’t know what a closure is, you should check out the wikipedia page for a first shot.

The idea is that our loading functions will perform some IO operations to load objects. Why not putting the cache directly in that function? We’d have a function with an opaque and invisible associated state. Consider the following:

type ResourceMap a = Map String a

getTextureManager :: (MonadIO m,...)
=> m (String -> m Texture)
getTextureManager = do
ref <- newIORef empty
pure $ \name -> do
-- we can use the ref ResourceMap to insert / lookup value in the map
-- thanks to the closure!

That solution is great because now, a manager is just a function. How would you implement getModelManager? Well:

getModelManager :: (MonadIO m,...)
=> (String -> m Texture)
-> m (String -> m Model)
getModelManager loadTexture = ...

We can then get the loader functions with the following:

loadTexture <- getTextureManager
loadModel <- getModelManager loadTexture

And you just have to pass those functions around. The cool thing is that you can wrap them in a type in your library and provide a function that initializes them all at once – I do that in my engine. Later on, the user can extend the available managers by providing new functions for new types. In my engine, I provide a few functions like mkResourceManager that hides the ResourceMap, providing two functions – one for lookup in the map, one for inserting into the map.

Conclusion

I truly believe that my solution is a good compromise between elegance and ease. It has a lot of advantages:

  • simple to use ;
  • simple to implement; you just have to play around with closures ;
  • dependencies resolving is easy to add and hidden once the functions are generated ;
  • little runtime overhead (due to closures, might be optimized away by the compiler though) ;
  • can be easily extended by the user to support custom/new types ;
  • if correctly used, implementations can replace IORef with TVar or similar objects for thread-safe implementations ;
  • several replicated functions mean several stores (can be useful in certain cases).

The huge drawback I see in that solution is its opacity. There’s also no way to query the state of each cache. Such a feature could be added by proving a new function, for instance. Same thing for deletion.

I’m one of those Haskellers who love purity. I try to keep my code the purest I can, but there are exceptions, and that cache problem fits that kind of exception.

Feel free to comment, and as always, keep the vibe and happy hacking!

Categories: Offsite Blogs

Color map/heat map plotting without gnuplot

Haskell on Reddit - Tue, 06/16/2015 - 10:52am

I looked online and the main two ways to plot and chart in Haskell are the chart package and a wrapper for the gnuplot. I can't seem to get gnuplot to install with its cygwin dependency...

I don't think chart package has any ability to do 2d heat map plotting, so I am out of ideas.

Do you know of any alternatives?

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

Why does mtl violate a law from transformers?

Haskell on Reddit - Tue, 06/16/2015 - 10:15am

Ok, let's take a look at Control.Monad.Cont.Class. We can find that for lifting callCC through StateT the liftCallCC' function is used. Now let's take a look at liftCallCC'. What do we see? It's clearly stated that it violates the unifomity law (unlike liftCallCC defined a few lines before it).

Now, why does mtl use the function that violates this law? What are practical consequences of it? Was it a deliberate decision or is it due to historical reasons?

What's the purpose of having this law if it's violated?

submitted by int_index
[link] [13 comments]
Categories: Incoming News

MonadFail proposal (MFP)

Haskell on Reddit - Tue, 06/16/2015 - 9:12am

The MonadFail proposal has been running for a week now, and I've just posted an update to it to the mailing lists. Since the original thread is long forgotten on Reddit, here's a new version, including the update. We're still looking for new ideas to consider, so if you have one, speak up!

Keep in mind that the main discussion is on the mailing lists (jointly ghc-devs@ and libraries@), so if you want to bring up a good idea, that might be a good place to put it forward as well. (I'm not sure how many of the core GHC people monitor Reddit.)

Links:

submitted by quchen
[link] [53 comments]
Categories: Incoming News

Space leak with replicateM

haskell-cafe - Tue, 06/16/2015 - 8:37am
In the following program, the function "test1" results in huge memory usage, but substituting "test2", which does essentially the same thing, does not. GHC 7.10.1, AMD64. Is there a different implementation of replicateM that avoids the space leak? module Main where { import Control.Monad; numbers :: [Int]; numbers=[1..200];
Categories: Offsite Discussion

Link to BayHac presentation and code files.

haskell-cafe - Tue, 06/16/2015 - 5:27am
Hi all, Great to have seen you all again at BayHac! I couldn’t find any reference to a central repository for presentation/code upload. So, here’s my stuff (“Cracking the Vigenere Cipher in Haskell”): https://github.com/capn-freako/BayHac_2015 Many thanks to Graham Hutton for permission to post his code, along with my own. Cheers, -db _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

Type constraint with RankNTypes gradually slows downfunction?

haskell-cafe - Mon, 06/15/2015 - 11:38pm
When I write a function with the type constraint "embedded" in the function's type declaration, instead of at the beginning, the function takes longer each time it is run. The simplest example I could write is this: http://lpaste.net/134563. "run1" is near instantaneous the first time, but gets marginally slower after each iteration... after thousands of iterations it takes about a millisecond to run (and keeps getting worse). "run2" is always near instantaneous. What is happening in "run1" that makes it slow down? PS: The example is fairly contrived, I know "run1"'s type declaration wouldn't be used in practice. Thanks for any guidance! {-# LANGUAGE RankNTypes #-} {-# LANGUAGE FlexibleContexts #-} module Main where import Control.Monad.State.Strict import qualified Data.Time.Clock as Clock import Control.Exception run1 :: (Int -> (Num Int => State Int Bool)) -> Int -> IO () run1 f state = do t1 <- Clock.getCurrentTime evaluate $ runState (f 1) state t2 <- Clock.getCurrentTime print $ C
Categories: Offsite Discussion

Image Analysis in Haskell

Haskell on Reddit - Mon, 06/15/2015 - 10:56pm

Hey guys! This might be a vague question, but does anyone know any libraries in Haskell for getting data from an image, and storing it in some data structure?

Specifically, I want to see if I can use Haskell to look at a picture of a matrix, and extract the contents and store them so I can perform operations on them. You don't have to do it for me or give me an exact answer, but pointing me in the right direction would be greatly appreciated! Thank you! (If that's too vague, let me know about that too!)

submitted by uncountableB
[link] [10 comments]
Categories: Incoming News

How would you implement a trading card game in Haskell?

Haskell on Reddit - Mon, 06/15/2015 - 10:19pm

One of the first projects I tried to tackle in Haskell was the card game "Coop", but I got lost and didn't make much progress. Then I spent some more time learning Haskell, and feel I understand the language much better now, but I'm still not sure how to go from the abstract ideas I've learned to working code.

I want to make a new attempt at a card game. I found this Stackoverflow question that illustrates what I'm thinking of: http://gamedev.stackexchange.com/q/28074 Basically a card game like Magic The Gathering or Hearthstone.

How would you implement a game like this in Haskell?

In an object oriented language I would make a card object that had various methods to respond to different events. These methods could access and modify the game state as needed, in response to events. For example, when a card is played it might receive a "card played" event, and could then perform a special action like giving all other active cards extra health; etc.

I don't know how to approach this problem in Haskell. Although I can do things like implement the State monad myself, I still don't know how to use it. I'm hoping some design guidelines for this problem that has been on my mind will be helpful and interesting.

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