News aggregator

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

(no subject)

General haskell list - Fri, 07/24/2015 - 1:10am
Can u still purchase general admission tkts Sent from my iPhone
Categories: Incoming News

Proposal: genericReplicateM

libraries list - Fri, 07/24/2015 - 12:49am
Overloaded versions of replicateM and replicateM_ for any Integral type: genericReplicateM :: (Monad m, Integral i) => i -> m a -> m [a] genericReplicateM n = sequence . genericReplicate n genericReplicateM_ :: (Monad m, Integral i) => i -> m a -> m () genericReplicateM_ n = sequence_ . genericReplicate n --ken
Categories: Offsite Discussion

Proposal: Migrate Data.Functor.{Sum, Product, Compose} from transformers to base.

libraries list - Fri, 07/24/2015 - 12:18am
As part of GHC 7.10 we moved Data.Functor.Identity from transformers into base. (We'd previously had a private, equivalent definition buried in Data.Traversable that we didn't export.) In a similar vein, I hereby propose moving Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose, and Data.Functor.Classes into base as they exist in transformers, without unduly bikeshedding their APIs. This would effectively reduce the role of transformers to simply supplying actual transformers and continue the general pattern of universal constructions migrating into base. Without bikeshedding their implementations this migration becomes a no-op for existing users. The most awkward of these is the Data.Functor.Classes API, but it affects a number of their instances, and without it, those instances would have to be orphans, so my gut reaction would be to say yes, we should move that as well. There are also some in-flight API changes in the works in the HEAD version of transformers for which a base-based version of
Categories: Offsite Discussion

[LPNMR 2015] EARLY REGISTRATION CLOSING SOON - Call for Participation (student support grants: NEWS)

General haskell list - Thu, 07/23/2015 - 8:23pm
[apologies for possible multiple copies] Call for Participation *** EARLY REGISTRATION CLOSES SOON *** *** NEW INFORMATION ABOUT STUDENT SUPPORT GRANTS *** --------------------------------------------------------------------------- 13th International Conference on Logic Programming and Non-monotonic Reasoning LPNMR 2015 Lexington, KY, USA September 27-30, 2015 (Collocated with the 4th Conference on Algorithmic Decision Theory 2015) --------------------------------------------------------------------------- REGISTRATION Registration procedure is available via Early registration closes before the end of July. AIMS AND SCOPE LPNMR 2015 is the thirteenth in the series of international meetings on logic programming and non-monot
Categories: Incoming News

servant: Pulling a mock server for your APIs out of thin air

Planet Haskell - Thu, 07/23/2015 - 6:00pm
Table of contents <section class="level1" id="summary"> Summary

A couple of days ago, marcushg mentioned on the #servant IRC channel that one could probably easily use the information available from API types to “derive” a mock implementation of your request handlers that just generates random values of whatever the return type of the handlers are. Julian and I discussed this a bit today and I just went ahead and wrote down our thoughts in a new branch. The result will be explained in this post, but in short, it lets us take a type describing a web API, such as:

type API = "user" :> Get '[JSON] User

and generate request handlers that just respond with random values of the appropriate type, User in our case. In servant/wai terms, this means we get a mock function with the type:

mock :: HasMock api => Proxy api -> Server api

i.e “given an API type, please generate a mock server for such an API”. This effectively means “please pull a mock server out of thin air for me”.

Out of thin air, really? Not exactly. But let’s start by clearly stating the problem.

</section> <section class="level1" id="the-problem"> The Problem

servant lets you describe web applications with a Haskell type using the combinators from servant’s type-level EDSL. Such a type would be:

-- In English: -- the API has one endpoint, under /user, which returns -- response bodies in JSON that describe values of type User type API = "user" :> Get '[JSON] User

where User could be defined as:

newtype User = User { username :: String }

The goal would be to “automagically” derive a request handler of the right type that we could use as a placeholder until we properly implement a handler that talks to the database and responds with “the real data”.

For anyone not familiar with servant already, you just need to know that it means we need to somehow automatically implement a computation with the type:

getUser :: EitherT ServantErr IO User

possibly by constraining the user to provide an instance for some random generation class.

</section> <section class="level1" id="the-plan"> The Plan

Just like servant-server, servant-client and others, we need a class whose instances will define the way we interpret each combinator, in a way very specific to this task: we will produce what servant-server takes as input, i.e request handlers! This all means we are basically looking at a class like:

class HasServer api => HasMock api where mock :: Proxy api -> Server api

where Server api just computes the types of the all the request handlers of an API type. In our case, Server api is computed as follows:

-- api = the API type from above in our case Server API = Server ("user" :> Get '[JSON] User) -- static strings in the path do not influence -- the type of a handler = Server (Get '[JSON] User) -- EitherT ServantErr IO is the default monad -- in which handlers run = Either ServantErr IO User

So we have to implement at least support for static string fragments in the path and the Get combinator (i.e handlers for HTTP GET requests).

</section> <section class="level1" id="hasmock-instances"> HasMock instances

Let’s start with the one for static path fragments, it’s the simplest one: we ignore the string bit and move on to what comes after.

instance (KnownSymbol path, HasMock rest) => HasMock (path :> rest) where mock _ = mock (Proxy :: Proxy rest)

Don’t be scared by KnownSymbol, it basically just means “path is a type-level string”, that is, a string that appears in a type.

Next comes the one for Get. This one is trickier: this is the combinator that says what type the handler returns. The returned value then gets encoded into JSON, HTML, CSV or any format of your choice. In our case, the handler returns a User and can only encode it in the JSON format.

Now the heart of the matter really is: we know we need to return an User and our EitherT ServantErr IO monad mentions IO, couldn’t we randomly generate an User? Yes, we can! For the purpose of a mock server, we will simply use QuickCheck’s Arbitrary class, which represents types for which we can generate random values, given a random number generator.

class Arbitrary a where arbitrary :: Gen a -- and another method, but optional

The Gen type provides instances for the Functor, Applicative and Monad classes and Arbitrary comes with instances for many of the types in base.

This essentially means writing an Arbitrary instance for User is as simple as:

instance Arbitrary User where -- we just rely on the arbitrary instance for lists of -- chars, i.e Strings, and use the Functor instance for Gen arbitrary = fmap User arbitrary

If you have multiple fields, you can use the usual combo of <$> (i.e fmap) and <*> (comes with Applicative).

-- a point: x, y coordinates data Point = Point Double Double instance Arbitrary Point where arbitrary = Point <$> arbitrary <*> arbitrary

Once you have an Arbitrary instance, in order to generate a random value using your instance, you have to call a function called… generate!

generate :: Gen a -> IO a

Putting the two together, we get:

generate arbitrary :: Arbitrary a => IO a

All we need to do is just “lift” that up into our EitherT ServantErr IO monad, which is exactly what Control.Monad.IO.Class.liftIO is about in the transformers package.

liftIO (generate arbitrary) :: Arbitrary a => EitherT ServantErr IO a

In order to automatically “fill” request handlers with this expression we just need to write the HasMock instance for Get, shown below.

instance (Arbitrary a, AllCTRender ctypes a) => HasMock (Get ctypes a) where mock _ = liftIO (generate arbitrary)

The AllCTRender constraint just says “we know how to encode values of type a in the formats listed in the Get combinator”.

And that’s it! You can now actually use all of this to put together a mock server for our little API.

</section> <section class="level1" id="using-mock"> Using mock

All we need to do to run the mock server is call servant-server’s serve function. It is illustrated below, along with all of the code you’d have to write if you were to use this mock-generation feature (aside from language pragmas and imports).

-- 1/ define our user type, deriving the Arbitrary instance -- since it's just a newtype and we can use the -- GeneralizedNewtypeDeriving extension. We also -- derive the Generic class to get our JSON encoding -- functions for free. newtype User = User { username :: String } deriving (Arbitrary, Generic) -- 2/ we get the JSON encoding for free instance ToJSON Generic -- 3/ recall our API type type API = "user" :> Get '[JSON] User -- 4/ define this simple Proxy. -- for any given type 'a', there's only one value of type 'Proxy a' -- that is not equivalent to error "foo" and the likes, a real honest value. -- The way to build this value is to use the Proxy constructor. -- In other words, this value lets us target one precise type. Servant -- uses this to tie the type-level information with value-level data. api :: Proxy API api = Proxy -- 5/ we magically derive the mock server. -- the run function comes from the warp webserver, -- -- 'mock' is the method of the `HasMock` class we've -- developed in this post. -- This will run a mock web server with an endpoint at -- http://localhost:8080/user that generates random values -- of type User main :: IO () main = run 8080 (serve api $ mock api)

Our little program in action:

$ curl localhost:8080/user {"username":"Yv\rG\u0014±Ssv\u001e>\u001aVF\u001e\u000fM5ø\u000ctefÚJ\u0001K4"} # yes, a truly original username.

This is really all you have to do to put together a mock server for an API type. You can find the complete code for this in the work-in-progress servant-mock package on github. The example can be found under example/main.hs there.

There are many more HasMock instances than the ones I have shown here of course – there’s one for all the combinators provided by the servant package! So you can take any API type out there and just create a mock server for it, as long as you provide Arbitrary instances for your data types. Nothing too interesting though, but feel free to take a look at src/Servant/Mock.hs in the repository if you want to read the other instances.

I hope this makes clear how simple writing your own servant interpretation can be, and encourages you to try your hand at it!

</section> <section class="level1" id="other-news"> Other news
  • I mentioned in a previous post that we had submitted a paper for the Workshop on Generic Programming, co-located with ICFP’15, in Vancouver this year. Well, the paper has been accepted!
  • Therefore, Julian Arni and/or Andres Löh will be giving a talk about servant there.
  • In addition to this, Julian Arni recently gave a talk about servant at Curry-On!. The video will be uploaded on their Youtube channel in the upcoming days.
  • I have submitted a very hands-on servant talk proposal for the Haskell eXchange 2015 in London, and it has been accepted! See you there, folks.
</section> Posted on July 24, 2015 by Alp Mestanogullari
Categories: Offsite Blogs

Proposal: instance MonadIO Q

libraries list - Thu, 07/23/2015 - 5:16pm
Template Haskell currently has runIO :: IO a -> Q a , which allows you to run IO actions with a guarantee of IO effects' ordering in a single splice (but not necessarily the order in which all the Q splices are run). If runIO is indeed a monad morphism, then there is a law-abiding MonadIO Q instance that could be added to transformers: instance MonadIO Q where liftIO = runIO This would be useful for dealing with monad transformer stacks with Q as the base monad (for an example, see genifunctors ( The only catch is that transformers would have to depend on template-haskell. I think this would be okay since no quasiquotation is involved, but I wanted to hear others' opinions. Ryan
Categories: Offsite Discussion

Mark Jason Dominus: Mystery of the misaligned lowercase ‘p’

Planet Haskell - Thu, 07/23/2015 - 8:53am

I've seen this ad on the subway at least a hundred times, but I never noticed this oddity before:

Specifically, check out the vertical alignment of those ‘p’s:

Notice that it is not simply an unusual font. The height of the ‘p’ matches the other lowercase letters exactly. Here's how it ought to look:

At first I thought the designer was going for a playful, informal logotype. Some of the other lawyers who advertise in the subway go for a playful, informal look. But it seemed odd in the context of the rest of the sign.

As I wondered what happened here, a whole story unfolded in my mind. Here's how I imagine it went down:

  1. The ‘p’, in proper position, collided with the edge of the light-colored box, or overlapped it entirely, causing the serif to disappear into the black area.

  2. The designer (Spivack's nephew) suggested enlarging the box, but there was not enough room. The sign must fit a standard subway car frame, so its size is prescribed.

  3. The designer then suggested eliminating “LAW OFFICES OF”, or eliminating some of the following copy, or reducing its size, but Spivack refused to cede even a single line. “Millions for defense,” cried Spivack, “but not one cent for tribute!”

  4. Spivack found the obvious solution: “Just move the up the ‘p’ so it doesn't bump into the edge, stupid!” Spivack's nephew complied. “Looks great!” said Spivack. “Print it!”

I have no real reason to believe that most of this is true, but I find it all so very plausible.

[ Addendum: Noted typographic expert Jonathan Hoefler says “I'm certain you are correct.” ]

Categories: Offsite Blogs