News aggregator

Proposal: Add missing Monoid for ZipList

libraries list - Sat, 07/25/2015 - 9:50pm There's a Monoid that matches what the Applicative for ZipList does that seems to be missing. instance Monoid a => Monoid (ZipList a) where mempty = pure mempty mappend = liftA2 mappend It's been brought up before: Not only is it useful when it's the Monoid you want, but it serves an educational purpose for highlighting the relationship between Monoid and Applicative as well. Are there any good reasons not to have it? I'd like to limit discussion to two weeks. _______________________________________________ Libraries mailing list Libraries< at >
Categories: Offsite Discussion

Is it possible to run IO action in the QuickCheck Gen monad?

Haskell on Reddit - Sat, 07/25/2015 - 8:10pm

If I have an IO action that generates some random value of type T, is there a way to convert that into the implementation of arbitrary in Arbitrary T?

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

Why does this work?

Haskell on Reddit - Sat, 07/25/2015 - 11:47am

I've got the following function declaration:

grabRange :: Ord a => a -> a -> [a] -> [a] grabRange l u = filter (\x -> l < x && x < u)

And it works with:

grabRange 3 12 [1,2,3,4,5,67,7,8,9,67,6,54,4,56,6,7,7,5,4,12,11] [4,5,7,8,9,6,4,6,7,7,5,4,11]

It doesnt make sense in my limited knowledge of currying:

a -> (a -> ([a]???? -> ([a])))

How come I don't have to name the [a] and where does it get the x from?

Edit: Sorry for the late response. Compliments to the Haskell community. Never have I gotten this many and ellaborate answers to my questions!

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

A problem with the presentation of monads

Haskell on Reddit - Sat, 07/25/2015 - 4:18am

Basically, they aren't clear enough.


  • There is no syntax indicating the code in a do block is being transformed, since it is being hidden.

  • After de sugaring a do block, you find (>>=)s, which is a type class function.

  • Virtually no modules document their implementation of bind.

The consequence is that in order to understand what's actually happening in a do block, you need to read the source code for a module.

In my mind, this is a large factor in making monads seem magical.

Simple solution:

  • Document your bind function.

This should give a sense of how specific monads operate internally.

I think authors should be encouraged to document more class functions in general. Unfortunately, I don't know a natural way to accomplish this outside of a culture shift.


  • Still no obvious indication of a code transformation in a do block.
submitted by fruitbooploops
[link] [44 comments]
Categories: Incoming News

Dimitri Sabadie: Introducing Luminance, a safer OpenGL API

Planet Haskell - Sat, 07/25/2015 - 4:03am

A few weeks ago, I was writing Haskell lines for a project I had been working on for a very long time. That project was a 3D engine. There are several posts about it on my blog, feel free to check out.

The thing is… Times change. The more it passes, the more I become mature in what I do in the Haskell community. I’m a demoscener, and I need to be productive. Writing a whole 3D engine for such a purpose is a good thing, but I was going round and round in circles, changing the whole architecture every now and then. I couldn’t make my mind and help it. So I decided to stop working on that, and move on.

If you are a Haskell developer, you might already know Edward Kmett. Each talk with him is always interesting and I always end up with new ideas and new knowledge. Sometimes, we talk about graphics, and sometimes, he tells me that writing a 3D engine from scratch and release it to the community is not a very good move.

I’ve been thinking about that, and in the end, I agree with Edward. There’re two reasons making such a project hard and not interesting for a community:

  1. a good “3D engine” is a specialized one – for FPS games, for simulations, for sport games, for animation, etc. If we know what the player will do, we can optimize a lot of stuff, and put less details into not-important part of the visuals. For instance, some games don’t really care about skies, so they can use simple skyboxes with nice textures to bring a nice touch of atmosphere, without destroying performance. In a game like a flight simulator, skyboxes have to be avoided to go with other techniques to provide a correct experience to players. Even though an engine could provide both techniques, apply that problem to almost everything – i.e. space partitionning for instance – and you end up with a nightmare to code ;
  2. an engine can be a very bloated piece of software – because of point 1. It’s very hard to keep an engine up to date regarding technologies, and make every one happy, especially if the engine targets a large audience of people – i.e. hackage.

Point 2 might be strange to you, but that’s often the case. Building a flexible 3D engine is a very hard and non-trivial task. Because of point 1, you utterly need to restrict things in order to get the required level of performance or design. There are people out there – especially in the demoscene world – who can build up 3D engines quickly. But keep in mind those engines are limited to demoscene applications, and enhancing them to support something else is not a trivial task. In the end, you might end up with a lot of bloated code you’ll eventually zap later on to build something different for another purpose – eh, demoscene is about going dirty, right?! ;)


So… Let’s go back to the basics. In order to include everyone, we need to provide something that everyone can download, install, learn and use. Something like OpenGL. For Haskell, I highly recommend using gl. It’s built against the gl.xml file – released by Khronos. If you need sound, you can use the complementary library I wrote, using the same name convention, al.

The problem with that is the fact that OpenGL is a low-level API. Especially for new comers or people who need to get things done quickly. The part that bothers – wait, no, annoys – me the most is the fact that OpenGL is a very old library which was designed two decades ago. And we suffer from that. A lot.

OpenGL is a stateful graphics library. That means it maintains a state, a context, in order to work properly. Maintaining a context or state is a legit need, don’t get it twisted. However, if the design of the API doesn’t fit such a way of dealing with the state, we come accross a lot of problems. Is there one programmer who hasn’t experienced black screens yet? I don’t think so.

The OpenGL’s API exposes a lot of functions that perform side-effects. Because OpenGL is weakly typed – almost all objects you can create in OpenGL share the same GL(u)int type, which is very wrong – you might end up doing nasty things. Worse, it uses an internal binding system to select the objects you want to operate on. For instance, if you want to upload data to a texture object, you need to bind the texture before calling the texture upload function. If you don’t, well, that’s bad for you. There’s no way to verify code safety at compile-time.

You’re not convinced yet? OpenGL doesn’t tell you directly how to change things on the GPU side. For instance, do you think you have to bind your vertex buffer before performing a render, or is it sufficient to bind the vertex array object only? All those questions don’t have direct answers, and you’ll need to dig in several wikis and forums to get your answers – the answer to that question is “Just bind the VAO, pal.”

What can we do about it?

Several attempts to enhance that safety have come up. The first thing we have to do is to wrap all OpenGL object types into proper types. For instance, we need several types for Texture and Framebuffer.

Then, we need a way to ensure that we cannot call a function if the context is not setup for. There are a few ways to do that. For instance, indexed monads can be a good start. However, I tried that, and I can tell you it’s way too complicated. You end up with very long types that make things barely unreadable. See this and this for excerpts.


In my desperate quest of providing a safer OpenGL’s API, I decided to create a library from scratch called luminance. That library is not really an OpenGL safe wrapper, but it’s very close to being that.

luminance provides the same objects than OpenGL does, but via a safer way to create, access and use them. It’s an effort for providing safe abstractions without destroying performance down and suited for graphics applications. It’s not a 3D engine. It’s a rendering framework. There’s no light, asset managers or that kind of features. It’s just a tiny and simple powerful API.


luminance is still a huge work in progress. However, I can already show an example. The following example opens a window but doesn’t render anything. Instead, it creates a buffer on the GPU and perform several simple operations onto it.

-- Several imports.
import Control.Monad.IO.Class ( MonadIO(..) )
import Control.Monad.Trans.Resource -- from the resourcet package
import Data.Foldable ( traverse_ )
import Graphics.Luminance.Buffer
import Graphics.Luminance.RW
import Graphics.UI.GLFW -- from the GLFW-b package
import Prelude hiding ( init ) -- clash with GLFW-b’s init function

windowW,windowH :: Int
windowW = 800
windowH = 600

windowTitle :: String
windowTitle = "Test"

main :: IO ()
main = do
-- Initiate the OpenGL context with GLFW.
windowHint (WindowHint'Resizable False)
windowHint (WindowHint'ContextVersionMajor 3)
windowHint (WindowHint'ContextVersionMinor 3)
windowHint (WindowHint'OpenGLForwardCompat False)
windowHint (WindowHint'OpenGLProfile OpenGLProfile'Core)
window <- createWindow windowW windowH windowTitle Nothing Nothing
makeContextCurrent window
-- Run our application, which needs a (MonadIO m,MonadResource m) => m
-- we traverse_ so that we just terminate if we’ve failed to create the
-- window.
traverse_ (runResourceT . app) window

-- GPU regions. For this example, we’ll just create two regions. One of floats
-- and the other of ints. We’re using read/write (RW) regions so that we can
-- send values to the GPU and read them back.
data MyRegions = MyRegions {
floats :: Region RW Float
, ints :: Region RW Int

-- Our logic.
app :: (MonadIO m,MonadResource m) => Window -> m ()
app window = do
-- We create a new buffer on the GPU, getting back regions of typed data
-- inside of it. For that purpose, we provide a monadic type used to build
-- regions through the 'newRegion' function.
region <- createBuffer $
<$> newRegion 10
<*> newRegion 5
clear (floats region) pi -- clear the floats region with pi
clear (ints region) 10 -- clear the ints region with 10
readWhole (floats region) >>= liftIO . print -- print the floats as an array
readWhole (ints region) >>= liftIO . print -- print the ints as an array
floats region `writeAt` 7 $ 42 -- write 42 at index=7 in the floats region
floats region @? 7 >>= traverse_ (liftIO . print) -- safe getter (Maybe)
floats region @! 7 >>= liftIO . print -- unsafe getter
readWhole (floats region) >>= liftIO . print -- print the floats as an array

Those read/write regions could also have been made read-only or write-only. For such regions, some functions can’t be called, and trying to do so will make your compiler angry and throw errors at you.

Up to now, the buffers are created persistently and coherently. That might cause issues with OpenGL synchronization, but I’ll wait for benchmarks before changing that part. If benchmarking spots performance bottlenecks, I’ll introduce more buffers and regions to deal with special cases.

luminance doesn’t force you to use a specific windowing library. You can then embed it into any kind of host libraries.

What’s to come?

luminance is very young. At the moment of writing this article, it’s only 26 commits old. I just wanted to present it so that people know it exists will be released as soon as possible. The idea is to provide a library that, if you use it, won’t create black screens because of framebuffers incorrectness or buffers issues. It’ll ease debugging OpenGL applications and prevent from making nasty mistakes.

I’ll keep posting about luminance as I get new features implemented.

As always, keep the vibe, and happy hacking!

Categories: Offsite Blogs

R-like Box plot using Frames and Chart

Haskell on Reddit - Fri, 07/24/2015 - 11:43pm

While I was doing one of those online stats courses I tried to replicate some of the R exploratory things with Haskell. I almost immediately got stuck with doing the box plots. After looking around a bit an being unable to find anything I tried to put something together myself using acowley's Frame library and Chart.

I though I could post it here in case someone finds it helpful and also for some feedback on how to improve it.

Thanks to /u/acowley for some great help in getting this working.

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

non-ASCII filepaths in a C function

libraries list - Fri, 07/24/2015 - 10:52pm
In my 'soxlib' package I have written a binding to sox_format_t * sox_open_read( char const * path, sox_signalinfo_t const * signal, sox_encodinginfo_t const * encoding, char const * filetype); I construct the C filepath "path" from a Haskell FilePath using Foreign.C.String.withCString. This works for ASCII and non-ASCII characters in Linux. However, non-ASCII characters let sox_open_read fail on Windows. What is the correct way to convert FilePath to "char *"?
Categories: Offsite Discussion

Memoization in Haskell

Haskell on Reddit - Fri, 07/24/2015 - 4:28pm

Hi there. I'm kind of a beginner at Haskell but I'm trying to broaden my programming abilities now that I got some time off. I've been trying a bunch of Project Euler problems I haven't solved yet with Haskell and I've run into a program regarding no variables: I don't know how to handle memoization.

Can someone tell me how dynamic programming is possible with Haskell even though there are no variables? I'm sure there must be some way to do this.

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

Intention to takeover glpk-hs

libraries list - Fri, 07/24/2015 - 12:44pm
Hi, I intend to take over the glpk-hs package from Louis, who did not respond to my direct request, made June 22nd. The last update to the package was made in 2012 and it does not compile with ghc 7.10. Cheers, JP.
Categories: Offsite Discussion

mbeddr: an Extensible C-based Programming Language and IDE for Embedded Systems

Lambda the Ultimate - Fri, 07/24/2015 - 10:47am

Markus Voelter, Bernd Kolb1, Daniel Ratiu, and Bernhard Schaetz, "mbeddr: an Extensible C-based Programming Language and IDE for Embedded Systems", SplashCON/Wavefront 2012.

Although embedded systems are an increasingly large part of our lives, and despite the fact that embedded software would undoubtedly benefit from the kind safety guarantees provided by more advanced type systems, most embedded software development is still done in C. That's partly a result of toolchain availability, and partly because many more advanced languages typically impose requirements on memory, dynamic memory allocation, and other runtime infrastructure that simply aren't supportable on a lot of resource-constrained microcontrollers or acceptable in a risk-averse environment. Mbeddr seems to be seeking a middle ground between C, and creating a whole new language. From the paper:

While the C programming language provides very good support for writing efficient, low-level code, it does not offer adequate means for defining higher-level abstractions relevant to embedded software. In this paper we present the mbeddr technology stack that supports extension of C with constructs adequate for embedded systems. In mbeddr, efficient low-level programs can be written using the well-known concepts from C. Higher level domain-specific abstractions can be seamlessly integrated into C by means of modular language extension regarding syntax, type system, semantics and IDE. In the paper we show how language extension can address the challenges of embedded software development and report on our experience in building these extensions. We show that language workbenches deliver on the promise of significantly reducing the effort of language engineering and the construction of corresponding IDEs. mbeddr is built on top of the JetBrains MPS language workbench. Both MPS and mbeddr are open source software

It appears that mbeddr allows multiple DSLs to be built on top of C to provide greater safety and more domain-specific expressions of typical embedded software patterns. Additionally, it provides integration with various analysis tools including model-checkers. Another paper, "Preliminary Experience of using mbeddr for Developing Embedded Software", provides a look at how all of these things fit together in use.

The mbeddr approach seems similar in concept to Ivory and Tower, although mbeddr uses JetBrains MPS as the platform for creating DSLs instead of building an embedded DSL in Haskell.

Categories: Offsite Discussion

broken source link

glasgow-user - Fri, 07/24/2015 - 8:59am
Hi, when trying to look up the original definition for Data.List.transpose in I found that the source link does not work. Could this be fixed? Or should I look elsewhere for the sources? Cheers Christian P.S. my looking up transpose was inspired by
Categories: Offsite Discussion

My first project in Haskell, a ray-tracer, feedback wanted.

Haskell on Reddit - Fri, 07/24/2015 - 4:42am

Hello everyone,

I started learning Haskel about 2 month ago, I learned mainly from the course [1] of Noam Zilberstein from Pennsylvania university.

To get more practice, I started to implement a raytracer since I know of these beasts work. As Haskell is my first functional programming language, I am not sure that I am doing it right so I would greatly appreciate feedback from more experienced Haskellers.

The code is on github : And Some screenshots :

Any feedback will be appreciated, many thanks. By the way, working daily with C++, haskell starts to feel like holidays :)

[1]: Introduction to Haskell

submitted by oilandrust
[link] [24 comments]
Categories: Incoming News

Tidal pattern library

Haskell on Reddit - Fri, 07/24/2015 - 4:18am
Categories: Incoming News