News aggregator

Proposal: Dot as Postfix Function Apply

libraries list - Wed, 11/04/2015 - 12:44pm
Dot as Postfix Function Apply ( was originally part of ORF, but dropped to keep the scope/discussion more manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot postfix syntax. The idea is that instead of (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person) we could have person.title ++ " " ++ person.firstName ++ " " ++ person.lastName This is a simple source-to-source translation with no changes to the type system (TDNR is an orthogonal proposal). The advantages are: 1. Code that's easier to read/write. 2. Familiar to users of almost every other programming language. 3. IDE auto-complete - an IDE can suggest functions applicable to the variable after typing . This would be an opt-in extension. I'm posting this to the libraries list because that's where proposals generally go, although this isn't strictly a library issue. If it should be on a different list I'll move it
Categories: Offsite Discussion

Cross-compilation for Win64 on Linux

Haskell on Reddit - Wed, 11/04/2015 - 11:48am

This is significantly harder than it has any reason to be; I'm stalled at what should be the last step.

So far, I have:

  • A GCC for cross-compilation, which works just fine compiling for x86_64 Windows.
  • GHC with Linux as target. This also works fine.
  • GHC source, plus Windows-necessary additional components
  • Renamed with the perf-cross configuration uncommented
  • ./configure --with-gcc=<cross-compile GCC> (this worked, apparently)
  • make. This fails. It gets as far as trying to configure Time- using the inline stage 1 GHC and then it informs me that the dependency 'Win32 - Any" is missing and terminates.

Attempting to add Win32 to my GHC (either of them) fails; cabal tells me I'm missing a header file and a tonne of C libraries. It helpfully suggests I grab the -dev versions, but not which packages might provide them.

This doesn't seem to be a well documented process, and unlike with GCC it's not even slightly obvious. Any pointers in the right direction?

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

Why do people compile javascript from haskell?

Haskell on Reddit - Wed, 11/04/2015 - 11:19am

I'm very new to haskell (started learning a couple of days ago), I am very interested in web development. I saw that a lot of people like to use haskell to write code in js, why? Is it because its easier to write good code in haskell then convert it or is it? Surely anything that one of these compilers can make could be written in pure js,or am I wrong?

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

Streaming a Conduit into a lazy list

haskell-cafe - Wed, 11/04/2015 - 10:59am
Conduits seem like a popular and useful way to compose operations which consume and produce streams at various speeds. I hadn't used them before, so apologies for any obvious mistakes below. Conduits have lots of power in terms of how you can interleave monadic effects with the streaming; but I found that I had a stream with no effects at all and I wanted to convert it back into haskells more simplistic representation, lazy lists. This is probably a well-known trick, but I couldn't find how to do this from googling, so here is the solution I found in case it helps someone else: A source which produces some data and then hangs, to test lazy production. One solution which doesn't work is CL.consume (as its own docs say) - and instead this happens: *Main> :t runIdentity (source123Error $$ CL.consume) runIdentity (source123Error $$ CL.consume) :: [Int] *Main> runIdentity (source123Error $$ CL.consume) *** Exception: error But what we can do instead is push the data out via the Writer monad: *Main> :t s
Categories: Offsite Discussion

Streaming a Conduit into a lazy list

haskell-cafe - Wed, 11/04/2015 - 10:29am
Conduits seem like a popular and useful way to compose operations which consume and produce streams at various speeds. I hadn't used them before, so apologies for any obvious mistakes below. Conduits have lots of power in terms of how you can interleave monadic effects with the streaming; but I found that I had a stream with no effects at all and I wanted to convert it back into haskells more simplistic representation, lazy lists. This is probably a well-known trick, but I couldn't find how to do this from googling, so here is the solution I found in case it helps someone else: A source which produces some data and then hangs, to test lazy production. One solution which doesn't work is CL.consume (as its own docs say) - and instead this happens: *Main> :t runIdentity (source123Error $$ CL.consume) runIdentity (source123Error $$ CL.consume) :: [Int] *Main> runIdentity (source123Error $$ CL.consume) *** Exception: error But what we can do instead is push the data out via the Writer monad: *Main> :t s
Categories: Offsite Discussion

Well-Typed.Com: Implementing a minimal version of haskell-servant

Planet Haskell - Wed, 11/04/2015 - 5:38am

Recently, there was a question on Stack Overflow on how Servant actually works. Others were quick to suggest the Servant paper as a thorough explanation of the approach and the implementation.

As a co-author, I’m obviously happy if the paper is being read, but it’s also 12 pages long in two-column ACM style. And while it explains the implementation, it does not necessarily make it easier to start playing with the code yourself, because it only shows excerpts, and code snippets in a paper are not easily runnable.

At the same time, whenever I want to demonstrate a new concept in the Servant context, or play with new ideas, I find myself not impementing it in the main Servant code base, but rather to create a small library that is “like Servant”, built on the same principles, but much simpler, so that I have less work to do and can evaluate the ideas more quickly. I’ve talked to some other contributors, and at least some of them are doing the same. So I thought it might be useful to develop and present the code of “TinyServant”, which is not exactly tiny, but still small compared to the full Servant code base, strips away a lot of duplication and unessential extras, but is still complete enough so that we can observe how Servant works. Obviously, this still won’t explain everything that one might want to know about the implementation of Servant, but I hope that it will serve as a useful ingredient in that process.

This blog post is a somewhat revised and expanded version of my Stack Overflow answer.

This is not a general tutorial on Servant and using Servant. For learning how to use Servant, the official Servant tutorial or the general documentation section of the Servant home page are better starting points.

The code

The full code that is discussed in this post is 81 lines of Haskell and available separately.

An overview

I’m going to show the following things:

  1. How to define the web API specification language that Servant offers. We are going to define as few constructs as possible: we are not going to worry about content types (just plain text), we are not going to worry about different HTTP methods (just GET), and the only special thing we can do in routes will be that we can capture components of the path. Still, this is enough to show all relevant ideas of the Servant implementation.

  2. How to define an interpretation of the specification language. The point of Servant is that we can define many of these: an API can be interpreted as a web server (for various web backends), a web client (for various frontend languages, such as Haskell or JavaScript), a mock server, as documentation (in various formats) and more. Here, I’m going to implement an interpretation as a simplified Haskell function that can be seen as simulating a primitive web server, but without incurring any actual web dependencies.

  3. How to use TinyServant on an example. We are going to take the very first example of the Servant homepage and adapt it for our examples.


To start, here are the language extensions we’ll need:

{-# LANGUAGE DataKinds, PolyKinds, TypeOperators #-} {-# LANGUAGE TypeFamilies, FlexibleInstances, ScopedTypeVariables #-} {-# LANGUAGE InstanceSigs #-}

The first three are needed for the definition of the type-level DSL itself. The DSL makes use of type-level strings (DataKinds) and also uses kind polymorphism (PolyKinds). The use of the type-level infix operators such as :<|> and :> requires the TypeOperators extension.

The second three are needed for the definition of the interpretation. For this, we need type-level functions (TypeFamilies), some type class programming which will require FlexibleInstances, and some type annotations to guide the type checker which require ScopedTypeVariables.

Purely for documentation purposes, we also use InstanceSigs.

Here’s our module header:

module TinyServant where import Control.Applicative import GHC.TypeLits import Text.Read import Data.Time

The import of Data.Time is just for our example.

API specifications

The first ingredient is to define the datatypes that are being used for the API specifications.

data Get (a :: *) data a :<|> b = a :<|> b infixr 8 :<|> data (a :: k) :> (b :: *) infixr 9 :> data Capture (a :: *)

As I’ve said before, we define only four constructs in our simplified language:

  1. A Get a represents an endpoint of type a (of kind *). In comparison with full Servant, we ignore content types here. We need the datatype only for the API specifications. There are no directly corresponding values, and hence there is no constructor for Get.

  2. With a :<|> b, we represent the choice between two routes. Again, we wouldn’t need a constructor, but it will turn out to be useful later when we define handlers.

  3. With item :> rest, we represent nested routes, where item is the first path component and rest are the remaining components. In our simplified DSL, there are just two possibilities for item: a type-level string, or a Capture. Because type-level strings are of kind Symbol, but a Capture, defined below is of kind *, we make the first argument of :> kind-polymorphic, so that both options are accepted by the Haskell kind system. So in particular, we will be able to write both

    "person" :> Get Person


    Capture Currency :> Get Amount

    and it will be well-kinded.

  4. A Capture a represents a route component that is captured, parsed and then exposed to the handler as a parameter of type a. In full Servant, Capture has an additional string as a parameter that is used for documentation generation. We omit the string here.

Example API

We can now write down a version of the API specification from the Servant home page, adapted to our simplified DSL, and replacing the datatypes used there by actual datatypes that occur in the Data.Time library:

type MyAPI = "date" :> Get Day :<|> "time" :> Capture TimeZone :> Get ZonedTime Interpretation as server

The most interesting aspect is of course what we can do with the API. Servant defines several interpretations, but they all follow a similar pattern. We’ll define only one here, which is inspired by the interpretation as a web server.

In Servant, the serve function has the following type:

serve :: HasServer layout => Proxy layout -> Server layout -> Application

It takes a proxy for the API type (we’ll get back to that in a moment), and a handler matching the API type (of type Server layout) to an Application. The Application type comes from the excellent WAI library that Servant uses as its default backend.

Even though WAI is very simple, it is too complicated for the purposes of this post, so we’ll assume a “simulated server” of type

[String] -> IO String

This server is supposed to receive a request that is just a sequence of path components ([String]). We do not care about request methods or the request body or anything like that. And the response it just a message of type String. We ignore status codes, headers and anything else. The underlying idea is still the same though than that of the Application type used in the actual Servant implementation.

So our serve function has type

serve :: HasServer layout => Proxy layout -> Server layout -> [String] -> IO String

The HasServer class, which we’ll define below, has instances for all the different constructs of the type-level DSL and therefore encodes what it means for a Haskell type layout to be interpretable as an API type of a server.

The Proxy type is defined as follows: It’s defined as

data Proxy a = Proxy

Its only purpose is to help the GHC type checker. By passing an explicitly typed proxy such as Proxy :: Proxy MyAPI to serve, we can explicitly instantiate the serve function to a particular API type. Without the Proxy, the only occurrences of the layout parameter would be in the HasServer class constraint and as an argument of Server, which is a type family. GHC is not clever enough to infer the desired value of layout from these occurrences.

The Server argument is the handler for the API. As just stated, Server itself is a type family (i.e., a type-level function), and computes from the API type the type that the handler(s) must have. This is one core ingredient of what makes Servant work correctly.

From these inputs, we then compute the output function of type [String] -> IO String as explained above.

The Server type family

We define Server as a type family first. (Again, this is somewhat simplified compared to Servant, which defines a monad transformer type family called ServerT as part of the HasServer class and then a top-level type synonym Server in terms of ServerT.)

type family Server layout :: *

The handler for a Get a endpoint is simply an IO action producing an a. (Once again, in the full Servant code, we have slightly more options, such as producing an error with a choice of status codes.)

type instance Server (Get a) = IO a

The handler for a :<|> b is a pair of handlers, so we could just define

type instance Server (a :<|> b) = (Server a, Server b) -- preliminary

But with this definition, nested occurrences of :<|> in the API would lead to nested pairs of handlers, so we’d have to write code like

(handler1, (handler2, handler3))

which looks a bit ugly. Instead, we’re going to make :<|> equivalent to Haskell’s pair type, but with an infix constructor called :<|>, so that we can write

handler1 :<|> handler2 :<|> handler3

for a nested pair. The actual definition of Server for :<|> is then

type instance Server (a :<|> b) = Server a :<|> Server b

It remains to explain how each of the path components is handled.

Literal strings in the routes do not affect the type of the handler:

type instance Server ((s :: Symbol) :> r) = Server r

A capture, however, means that the handler expects an additional argument of the type being captured:

type instance Server (Capture a :> r) = a -> Server r Computing the handler type of the example API

If we expand Server MyAPI, we obtain

Server MyAPI ~ Server ( "date" :> Get Day :<|> "time" :> Capture TimeZone :> Get ZonedTime ) ~ Server ("date" :> Get Day) :<|> Server ("time" :> Capture TimeZone :> Get ZonedTime) ~ Server (Get Day) :<|> Server ("time" :> Capture TimeZone :> Get ZonedTime) ~ IO Day :<|> Server ("time" :> Capture TimeZone :> Get ZonedTime) ~ IO Day :<|> Server (Capture TimeZone :> Get ZonedTime) ~ IO Day :<|> TimeZone -> Server (Get ZonedTime) ~ IO Day :<|> TimeZone -> IO ZonedTime

where ~ is GHC’s syntax for type equality.

Recall that :<|> as defined is equivalent to a pair. So as intended, the server for our API requires a pair of handlers, one that provides a date of type Day, and one that, given a time zone, provides a time (of type ZonedTime). We can define the handler(s) right now:

handleDate :: IO Day handleDate = utctDay <$> getCurrentTime handleTime :: TimeZone -> IO ZonedTime handleTime tz = utcToZonedTime tz <$> getCurrentTime handleMyAPI :: Server MyAPI handleMyAPI = handleDate :<|> handleTime The HasServer class

We still have to implement the HasServer class, which looks as follows:

class HasServer layout where route :: Proxy layout -> Server layout -> [String] -> Maybe (IO String)

The task of the function route is almost like serve. Internally, we have to dispatch an incoming request to the right router. In the case of :<|>, this means we have to make a choice between two handlers. How do we make this choice? A simple option is to allow route to fail, by returning a Maybe. Then in a choice we can just try the first option, and if it returns Nothing, try the second. (Again, full Servant is somewhat more sophisticated here, and version 0.5 will have a much improved routing strategy, which probably at some point in the future deserves to be the topic of its own blog post.)

Once we have route defined, we can easily define serve in terms of route:

serve :: HasServer layout => Proxy layout -> Server layout -> [String] -> IO String serve p h xs = case route p h xs of Nothing -> ioError (userError "404") Just m -> m

If none of the routes match, we fail with a (simulated) 404. Otherwise, we return the result.

The HasServer instances

For a Get endpoint, we defined

type instance Server (Get a) = IO a

so the handler is an IO action producing an a, which we have to turn into a String. We use show for this purpose. In the actual Servant implementation, this conversion is handled by the content types machinery, and will typically involve encoding to JSON or HTML.

instance Show a => HasServer (Get a) where route :: Proxy (Get a) -> IO a -> [String] -> Maybe (IO String) route _ handler [] = Just (show <$> handler) route _ _ _ = Nothing

Since we’re matching an endpoint only, the require the request to be empty at this point. If it isn’t, this route does not match and we return Nothing.

Let’s look at choice next:

instance (HasServer a, HasServer b) => HasServer (a :<|> b) where route :: Proxy (a :<|> b) -> (Server a :<|> Server b) -> [String] -> Maybe (IO String) route _ (handlera :<|> handlerb) xs = route (Proxy :: Proxy a) handlera xs <|> route (Proxy :: Proxy b) handlerb xs

Here, we get a pair of handlers, and we use <|> for Maybe to try both, preferring the first if it matches.

What happens for a literal string?

instance (KnownSymbol s, HasServer r) => HasServer ((s :: Symbol) :> r) where route :: Proxy (s :> r) -> Server r -> [String] -> Maybe (IO String) route _ handler (x : xs) | symbolVal (Proxy :: Proxy s) == x = route (Proxy :: Proxy r) handler xs route _ _ _ = Nothing

The handler for s :> r is of the same type as the handler for r. We require the request to be non-empty and the first component to match the value-level counterpart of the type-level string. We obtain the value-level string corresponding to the type-level string literal by applying symbolVal. For this, we need a KnownSymbol constraint on the type-level string literal, but all concrete literals in GHC are automatically an instance of KnownSymbol.

The final case is for captures:

instance (Read a, HasServer r) => HasServer (Capture a :> r) where route :: Proxy (Capture a :> r) -> (a -> Server r) -> [String] -> Maybe (IO String) route _ handler (x : xs) = do a <- readMaybe x route (Proxy :: Proxy r) (handler a) xs route _ _ _ = Nothing

In this case, we can assume that our handler is actually a function that expects an a. We require the first component of the request to be parseable as an a. Here, we use the Read class, whereas in Servant, we use a special-purpose class called FromText (or FromHttpApiData in version 0.5). If reading fails, we consider the request not to match. Otherwise, we can feed it to the handler and continue.

Testing everything

Now we’re done.

We can confirm that everything works in GHCi:

GHCi> serve (Proxy :: Proxy MyAPI) handleMyAPI ["time", "CET"] "2015-11-01 20:25:04.594003 CET" GHCi> serve (Proxy :: Proxy MyAPI) handleMyAPI ["time", "12"] *** Exception: user error (404) GHCi> serve (Proxy :: Proxy MyAPI) handleMyAPI ["date"] "2015-11-01" GHCi> serve (Proxy :: Proxy MyAPI) handleMyAPI [] *** Exception: user error (404)

We now have a system that we can play with an extend and modify easily. We can for example extend the specification language by a new construct and see what we have to change. We can also make the simulation more faithful (e.g. include request bodies or query parameters). Or we can define a completely different interpretation (e.g. as a client) by following the same scheme.

Categories: Offsite Blogs

Walking a bit stream (very novice question)

Haskell on Reddit - Wed, 11/04/2015 - 4:47am

Suppose I want to walk a bit stream. In this case I am talking about a dwg reading library / app, see libdwg source file. The C version uses two indicators of where the current place in the stream is, one for byte level and one for bit level indicator and from that it reads the various variables, bits, bytes, floats, text and other, with different functions.

Two questions. 1) In Haskell how do you deal with the stream position indicator (which is state) and 2) Is this something for monads and only one bit_read function?

submitted by sixfootnix
[link] [4 comments]
Categories: Incoming News

Using github url in cabal files as dependencies

Haskell on Reddit - Wed, 11/04/2015 - 12:56am

If you have ever used bundler, you know that it is possible to specify git urls as dependencies:

gem 'nokogiri', :git => ''

I wonder if it is possible to do the same in cabal? That would be a good idea since it allows us to use projects that are not hosted on the cabal repository.

Update 1: Well, my motivation for this question is that we are working on a large Haskell project, some part of which can be open sourced. However, pushing the project to hackage doesn't sound so great for several reasons, e.g., we don't want to muddy the hackage with non mature projects and projects in early stage need a rapid dev/test/deploy cycle. Hackage only introduces an extra layer of complexity that makes this cycle slower.

I am pretty sure there are many companies out there who have the same motivation. So, if cabal has such capability, I guess we will have far more contributions from the companies which are using Haskell.

Update 2: One workaround to this problem would be to write a proxy server that acts like a fake hackage server and downloads the projects from git or wherever. One can add this fake server to the list of cabal repos such that cabal tries to download from this server (before) the hackage server. Hackage protocol seems quite simple to me, but I am not sure about the details. Does anyone has a link to the hackage protocol spec?

submitted by gtab62
[link] [18 comments]
Categories: Incoming News

Good resources to learn about datatype generic programming?

Haskell on Reddit - Tue, 11/03/2015 - 11:52pm

I'm interested in learning about using Haskell for datatype generic programming (right term?) The kind of programming used to create the Servant API.

The Servant paper describes the implementation as using a combination of type classes with type families and data kinds. Unfortunately, I've found these concepts difficult to approach and lacking in introductory material. A bit of help pointing to useful learning resources would be very useful. Any pointers?

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

CFP: 25th Int'l Conf. on Compiler Construction (CC) -*new deadline*

General haskell list - Tue, 11/03/2015 - 9:22pm
[ Please forward. Apologies for any duplicates. ] ********************************************************************** CALL FOR PAPERS 25th International Conference on Compiler Construction (CC 2016) March 17-18 2016, Barcelona, Spain Co-located with CGO, HPCA, PPoPP, and EuroLLVM ********************************************************************** Important dates --------------- Abstracts due: 23 November 2015 (updated) Papers due: 30 November 2015 (updated) Author notification: 27 January 2016 Camera ready versions: 10 February 2016 Conference: 17-18 March 2016 Information ----------- The International Conference on Compiler Construction (CC) is interested in work on processing programs in the most general sense: analyzing, transforming or executing input that describes how a system operates, including traditional compiler const
Categories: Incoming News

What is your Haskell workflow? How to easily try stuff when learning?

Haskell on Reddit - Tue, 11/03/2015 - 8:29pm

I am coming from Scala, where I normally have one editor window (vi) where I edit stuff, and SBT shell where it continuously run tests / main or whatever I specify...

I would love to learn haskell but for that I am looking for some nice way how to work. Typing multiline stuff into ghci is pain, so I'd prefer something simmiliar to my scala workflow, where I have a shell / window where I type and another window where it is executed automatically.

Is there anything like it ? How do you use haskell to be productive? I would hope to avoid Emacs and have vim bindings.

submitted by fromscalatohaskell
[link] [14 comments]
Categories: Incoming News

record field names vs. -fwarn-unused-binds

glasgow-user - Tue, 11/03/2015 - 7:47pm
[ ccing haskell-cafe since while it's a ghc flag, I'll bet most compilers have an equivalent ] I really like -fwarn-unused-binds because it frequently finds bugs where I forgot to call something or use some value. If I put an export list on, it can find dead functions I forgot to delete. However, there's one case where it frequently gives false positives, and that's unused record field names. The problem is that I sometimes use record field names as documentation, but the record itself is internal and small, so I'm comfortable using positional pattern matching to open it (and in fact that can be safer, since then warn-unused-binds will make sure I used all the fields). But GHC sees these as unused functions, so it warns about them. I can work around by putting underscores on field names I haven't used yet, but it's a hassle to go edit them when I want to use them. The warning can be useful if it indicates an unused field, but since fields can also be extracted via the positional syntax it's not reliabl
Categories: Offsite Discussion

Who's hiring, HS cafe edition Re: Haskell Engineer Needed for Machine Learning Group

haskell-cafe - Tue, 11/03/2015 - 5:19pm
My team at "megacorp " is hiring. Our main project right now is a domain specific sibling to Agda / idris that runs on top of strongly consistent replicated db that we're also in the process of iterating on. A colleague and I will be at Hac Phi this weekend, and we're also helping sponsor some of the catering costs. Talk to us if you're there! On Tuesday, November 3, 2015, Kim-Ee Yeoh <ky3< at >> wrote: _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion