January 2015 - Haskell-Cafe

ANN: Cabal 1.22 and cabal-install 1.22
by Johan Tibell 05 Jan '15

05 Jan '15

On behalf of the cabal developers, I'm happy to announce the Cabal 1.22 release! To install: cabal update && cabal install Cabal-1.22.0.0 cabal-install-1.22.0.0 Please report bugs at https://github.com/haskell/cabal/issues. Pre-built binaries should be available with a week or so. Non-exhaustive list of changes: * Support GHC 7.10. * Experimental DWARF debug info output on GHC 7.10 (--enable-debug-info). * Preliminary support for relocatable packages. * Cabal can now be used inside a cabal exec environment. * Fix solver bug where the user's manual flag choice was ignored. * Add GHCJS support. * Improved command line documentation. * Build C sources with -fPIC when GHC is using dynamic libraries. * Preliminary support for package keys (a step on the way to NixOS-like packages). * Add a 'user-config' command to help users manage ~/.cabal/config. * HPC support improved. Here are all the contributors to this release, ordered by number of commits: 181 Mikhail Glushenkov 48 Johan Tibell 35 Edward Z. Yang 34 Christiaan Baaij 32 Thomas Tuegel 24 Ben Armston 19 Ian D. Bollinger 17 Lennart Spitzner 12 Luite Stegeman 11 Herbert Valerio Riedel 10 Duncan Coutts 9 Erik de Castro Lopo 8 Andres Loeh 5 Chris Wong 5 Iain Nicol 5 Heather 5 Jake Wheat 4 Daniel Trstenjak 4 Tuncer Ayaz 4 Neil Vice 4 Rudy Matela 2 David Feuer 2 Bertram Felgenhauer 2 Fujimura Daisuke 2 Iustin Pop 2 John Chee 2 Keshav Kini 2 Maxwell Swadling 2 Michael Snoyman 2 Owen Stephens 2 Sergey Vinokurov 2 Thomas Miedema 2 Vincent Hanquez 2 jake 1 Brent Yorgey 1 Maximilian Tagher 1 Anton Dessiatov 1 phischu 1 Bob Ippolito 1 Miëtek Bak 1 Bardur Arantsson 1 Nikita Karetnikov 1 tchakkazulu 1 Peter Trško 1 Austin Seipp 1 Ryan Mulligan 1 RyanGlScott 1 Samuel Gélineau 1 Sergei Trofimovich 1 jpmoresmau 1 Simon Hengel 1 Thomas M. DuBuisson 1 Harry Garrood 1 Isamu Mogi 1 kosmikus 1 David Fox 1 Curtis Gagliardi 1 Antonio Nikishaev 1 Karel Gardas 1 Travis Cardwell 1 Chris Allen 1 Matthew William Cox

1 0

[ANN] Haskell client for Event Store
by Yorick Laupa 04 Jan '15

04 Jan '15

Hi, I'd like to announce my Event Store TCP client. It licensed under BSD3. You can find the source on Github <http://github.com/YoEight/eventstore>. Package is available on Hackage <http://hackage.haskell.org/package/eventstore-0.5.0.0>. Here's a list of supported features: * Single event writes. * Batch writes. * Transactional writes. * Stream deletion. * Single event reads. * Range reads from regular streams and from $all stream (backward and forward). * Volatile subscriptions (regular stream and $all). * Catch-up subscriptions (regular stream and $all). * Authenticated connection. Will be implemented: * Persistent subscriptions. * SSL connection. I originally wrote that library because I need it for a real project. I only implemented features I need first, so feel free to open a ticket (or better a pull request) on Github for something you need or a bug you've experienced. I'll be as fast as I can. Few notes on the code itself. This implementation uses a Functional Reactive Programming (FRP) library named Sodium <https://hackage.haskell.org/package/sodium>. Connection bookkeeping (operation and subscription management for instance) was amazingly easy to implement with it. I only tested that library with EventStore 3.0.1. Hope you enjoy it. Regards, Yorick

1 0

ECMA262 (Javascript) interpreter
by Fabian Bergmark 04 Jan '15

04 Jan '15

I have been implementing an ECMA-262 (Javascript) interpreter over the last few weeks. I have been following http://www.ecma-international.org/ecma-262/5.1 and tried to keep my implementation as close to the specification as possible. The code can be found here https://github.com/fabianbergmark/ECMA-262 So far I have implemented the core language, but has yet to write all the specification functions (Array.splice, String.substring etc.). Before I do this and release it on hackage, I would appreciate feedback on my implementation. The issues I see at the time are: * The parser is slow for deeply nested code * Strict mode is not implemented * Interpret.hs is ~ 6k lines * SubType.hs uses IncoherentInstances, and a better implementation would be nice. At the moment it works but for one case. To test the code, install the cabal package and run ecma262 on a .js file. One host object, console.log is provided and prints to stdout. Fabian Bergmark

4 7

servant-pandoc
by Matthew Pickering 04 Jan '15

04 Jan '15

Dear list, As a quick and easy way to render API documentation to many more formats I thought it wise to create a new pandoc renderer. For those who don't know, pandoc is a multi-format document conversion tool which currently supports 24 different output formats.[1] The rendering is quite faithful to the current `markdown` renderer, if people find this package useful then I can look to fine tune the representation. Note: The package will not build until servant-docs 0.3 is released which will hopefully be tomorrow or the day after. Below are some examples of the rendering and links to the package. examples: https://github.com/mpickering/servant-pandoc/tree/master/examples github: https://github.com/mpickering/servant-pandoc hackage: http://hackage.haskell.org/package/servant-pandoc [1]: http://pandoc.org/ Matt

1 1

Updating tar for ghc 7.10 FAM compatibility
by Darren Grant 04 Jan '15

04 Jan '15

Hi all, Does anyone know who I can reach out to in order to get the tar hackage updated for ghc 7.10? Unfortunately, Duncan's email bounced. Cheers, Darren Grant

2 1

Proof that scanl can be written as foldr?
by Cristian Ontivero 04 Jan '15

04 Jan '15

Hello, I'm trying to solve the exercise 4.6.5 of Bird's "Introduction to functional programming using Haskell". Let me quote: "Prove that scanl f e can be written as a foldr, if f is associative with unit e. Can scanl f e be written as a foldl without any assumptions on f and e?" So far reasoning by myself and googling a bit I reached to the following scanl definition using foldl (without any assumptions afaik): scanl f e = foldl (\xs next -> xs ++ [f (last xs) next]) [e] Furthermore, previously on the same chapter, it says that: scanl f e = foldr g [e] where g x xs = e : map (f x) xs Using this definition, I tried proving it by induction, but since I got stuck, I tried seeing if I could find some way to use the first duality theorem (with the foldl definition), or fusion, but to no avail. The induction proof I wrote is the following: scanl f e = foldr g [e] where g y ys = e : map (f y) ys By the principle of extensionality, this is equivalent to: scanl f e xs = foldr g [e] xs where g y ys = e : map (f y) ys We prove this equality by induction on xs. Case([]). For the left-hand side we reason scanl f e [] = {scanl.1} [e] For the right-hand side foldr g [e] [] = {foldr.1} [e] Case(x:xs). For the left-hand side we reason scanl f e (x:xs) = {scanl.2} e : scanl f (f e x) xs = {f has unit e} e : scanl f x xs = {induction hypothesis} e : foldr g [x] xs For the right-hand side foldr g [e] (x:xs) = {foldr.2} g x (foldr g [e] xs) = {definition of g} e : map (f x) (foldr g [e] xs) = {definition of map} e : foldr ((:) . (f x)) [] (foldr g [e] xs) I'm not even sure the last step is useful, but I thought maybe I could combine both foldrs into a single one (that's why I thought about the fusion law). Anyway, any help or pointer that can lead me in the right direction is very much appreciated. Thanks in advance.

1 0

Handling Postgresql array types
by Riaan 03 Jan '15

03 Jan '15

This is a question about database query libraries. I am trying to do some analytics on a Postgresql database and up to now have been using Database.HDBC for most of my querying. One of the columns on the database is a two dimensional float8 array. I tried using Database.PostgreSQL.Simple but got stuck on this array as I could not figure out how to extend the built in conversion functions to cater for something like this. So went back to HDBC. But now my queries are starting to get fairly long and I have been looking at libraries like Persistent with Esqualeto, HaskellDB and Groundhog to make my queries a little more composable and type safe. However I have not been able to find any examples of any of these libraries using postgres arrays and given my postgresql-simple experience I worried that I might similarly be unable, because of my low level of haskell ability, to extend the conversion functions. So to my question. Does anyone have experience with one of these libraries in dealing with postgresql arrays and could someone perhaps send me a simple example that I could use as a basis. Failing that, can anyone advise me on which of these libraries have the most haskell newbie (LYAH trained, but still struggling with RWH) friendly approach to writing new conversion functions? Thanks Riaan

6 16

Re: [Haskell-cafe] Yet Another Forkable Class
by oleg＠okmij.org 03 Jan '15

03 Jan '15

Perhaps effect libraries (there are several to choose from) could be a better answer to Fork effects than monad transformers. One lesson from the recent research in effects is that we should start thinking what effect we want to achieve rather than which monad transformer to use. Using ReaderT or StateT or something else is an implementation detail. Once we know what effect to achieve we can write a handler, or interpreter, to implement the desired operation on the World, obeying the desired equations. And we are done. For example, with ExtEff library with which I'm more familiar, the Fork effect would take as an argument a computation that cannot throw any requests. That means that the parent has to provide interpreters for all child effects. It becomes trivially to implement: > Another example would be a child that should not be able to throw errors as > opposed to the parent thread. It is possible to specify which errors will be allowed for the child thread (the ones that the parent will be willing to reflect and interpret). The rest of errors will be statically prohibited then. > instance (Protocol p) => Forkable (WebSockets p) (ReaderT (Sink p) IO) where > fork (ReaderT f) = liftIO . forkIO . f =<< getSink This is a good illustration of too much implementation detail. Why do we need to know of (Sink p) as a Reader layer? Would it be clearer to define an Effect of sending to the socket? Computation's type will make it patent the computation is sending to the socket. The parent thread, before forking, has to provide a handler for that effect (and the handler will probably need a socket). Defining a new class for each effect is possible but not needed at all. With monad transformers, a class per effect is meant to hide the ordering of transformer layers in a monad transformer stack. Effect libraries abstract over the implementation details out of the box. Crutches -- extra classes -- are unnecessary. We can start by writing handlers on a case-by-case basis. Generalization, if any, we'll be easier to see. From my experience, generalizing from concrete cases is easier than trying to write a (too) general code at the outset. Way too often, as I read and saw, code that is meant to be reusable ends up hardly usable.

9 12

Modifying a product type generically
by Michael Orlitzky 03 Jan '15

03 Jan '15

I've been playing with generic conversions between simple product types. For example, converting (Bar Int Int) back and forth between (Int,Int). See, https://www.haskell.org/pipermail/haskell-cafe/2014-December/117489.html These save me a *lot* of boilerplate. But naturally, I've gotten greedy. Another transformation I need to make takes one data type, and sticks a new field on the beginning of it. So I'd like to be able to take a, Foo Int Int and construct a, BigFoo String Int Int with as little code as possible. In my real problem, Foo may have 30 fields, and BigFoo 31 -- if you know of a better way, stop me now. And, I actually managed to do it using generics-sop: > prepend "Hello" (Foo 1 2) :: BigFoo BigFoo "Hello" 1 2 But, I had to do something dirty; I used an incomplete pattern match. I don't know enough about what's going on here to handle the other case for prepend_sop. I basically guessed the existing type signatures because it wouldn't work without them. I would like to either, a) Get prepend_sop working for sums of products (the missing case), not just a single product (the one I've got working) b) Restrict prepend_sop to the case that I've got working via the type system, somehow In other words, I don't want it to be crashy, but I'm stuck. Here's the complete working code for the example above. {-# LANGUAGE DataKinds #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module Prepend where import qualified GHC.Generics as GHC import Generics.SOP data Foo = Foo Int Int deriving (Show, GHC.Generic) instance Generic Foo -- A "copy" of Foo, with a String in front of it. data BigFoo = BigFoo String Int Int deriving (Show, GHC.Generic) instance Generic BigFoo prepend_sop :: (xss ~ (x ': xs), (yss ~ ((a ': x) ': xs))) => a -> SOP I xss -> SOP I yss prepend_sop z (SOP (Z rest)) = SOP $ Z ((I z) :* rest) --prepend_sop z (SOP (S rest)) = ??? prepend :: (Generic a, Generic c, Code a ~ (x ': xs), Code c ~ ((b ': x) ': xs)) => b -> a -> c prepend z = to . (prepend_sop z) . from

3 6

Type-directed functions
by Julian Arni 03 Jan '15

03 Jan '15

Hi all, I've been playing around with what might be described as type-directed functions. One example is a list-like structure of phantom-typed values {-# LANGUAGE TypeOperators #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} import GHC.TypeLits infixr 6 ::: data a ::: b = a ::: b deriving (Show, Eq) data Tag b = Tag String deriving (Show, Eq) ex1 :: Tag 5 ::: Tag 3 ::: Tag 7 ex1 = Tag "Alice" ::: Tag "Bob" ::: Tag "Carol" And then sorting 'ex1' based on the Nats, such that sort ex1 :: Tag 3 ::: Tag 5 ::: Tag 7 sort ex1 = Tag "Bob" ::: Tag "Alice" ::: Tag "Carol" Notice how it's the types, not the values, that determine the result, but that the value-level also changes. I know how to do this using classes, but it's a little excruciating - it's like programming in a verbose and very restricted Prolog. With type families it's much easier to get the result *type* (pattern matching is simple, recursive calls are natural, and it all looks a lot more like Haskell), but I haven't yet seen a way of effectively using type families to direct the value-level component of the calculation. Are there any examples of how this might be done? Or are there other alternatives to using type-classes that I am missing? Or, alternatively, are there libraries to reduce the boilerplate of this type-class code? Thanks, Julian

3 3