# News aggregator

### transformers appears to benefit from more inline

### Parsing Bitstreams with haskell

### When are MVars better than STM?

### Webdriver scroll down?

### [ANN] nano-erl

### Servant or other library for a largish API?

### Stack users: multiple executables in one cabal file, or multiple packages in stack.yaml?

### Magnus Therning: Freer play with effects

In the previous posts on my playing with free I got stuck at combining APIs. I recalled reading a paper on extensible effects as an alternatve to monad transformers. I have to admit to not having finished the paper, and not quite understanding the part I did read. When looking it up again I found that the work had continued and that there is a paper on more extensible effects. (I got to it via http://okmij.org/ftp/Haskell/extensible/.)

A quick search of Hackage revealed the package extensible-effects with an implementation of the ideas, including the stuff in the latter paper. So, what would the examples from my previous posts look like using extensible effects?

OpeningThe examples require a few extensions and modules:

{-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeOperators #-}and

import Control.Eff import Control.Eff.Lift import Control.Eff.Operational import Data.Typeable Just an APIThis part was greatly helped by the fact that there is a example in extensible-effects.

I start with defining the SimpleFile API using GADTs

data SimpleFileAPI a where LoadFile :: FilePath -> SimpleFileAPI String SaveFile :: FilePath -> String -> SimpleFileAPI ()The usage of the constructors need to be wrapped up in singleton. To remember that I create two convenience functions

loadFile :: Member (Program SimpleFileAPI) r => FilePath -> Eff r String loadFile = singleton . LoadFile saveFile :: Member (Program SimpleFileAPI) r => FilePath -> String -> Eff r () saveFile fp = singleton . SaveFile fpFor withSimpleFile I only have to modify the type

withSimpleFile :: Member (Program SimpleFileAPI) r => (String -> String) -> FilePath -> Eff r () withSimpleFile f fp = do d <- loadFile fp let result = f d saveFile (fp ++ "_new") resultNow for the gut of it, the interpreter.

runSimpleFile :: (Member (Lift IO) r, SetMember Lift (Lift IO) r) => Eff (Program SimpleFileAPI :> r) a -> Eff r a runSimpleFile = runProgram f where f :: (Member (Lift IO) r, SetMember Lift (Lift IO) r) => SimpleFileAPI a -> Eff r a f (LoadFile fp) = lift $ readFile fp f (SaveFile fp s) = lift $ writeFile fp sRunnnig it is fairly simple after this

> :! cat test.txt Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec a diam lectus. Sed sit amet ipsum mauris. Maecenas congue ligula ac quam viverra nec consectetur ante hendrerit. > runLift $ runSimpleFile $ withSimpleFile (map toUpper) "test.txt" > :! cat test.txt_new LOREM IPSUM DOLOR SIT AMET, CONSECTETUR ADIPISCING ELIT. DONEC A DIAM LECTUS. SED SIT AMET IPSUM MAURIS. MAECENAS CONGUE LIGULA AC QUAM VIVERRA NEC CONSECTETUR ANTE HENDRERIT.Now, that was pretty easy. It looks almost exactly like when using Free, only without the Functor instance and rather more complicated types.

Combining two APIsNow I get to the stuff that I didn’t manage to do using Free; combining two different APIs.

I start with defining another API. This one is truly a play example, sorry for that, but it doesn’t really matter. The type with convenience function looks like this

data StdIoAPI a where WriteStrLn :: String -> StdIoAPI () writeStrLn :: Member (Program StdIoAPI) r => String -> Eff r () writeStrLn = singleton . WriteStrLnThe interpreter then is straight forward

runStdIo :: (Member (Lift IO) r, SetMember Lift (Lift IO) r) => Eff (Program StdIoAPI :> r) a -> Eff r a runStdIo = runProgram f where f :: (Member (Lift IO) r, SetMember Lift (Lift IO) r) => StdIoAPI a -> Eff r a f (WriteStrLn s) = lift $ putStrLn sNow I just need a program that combines the two APIs

verboseWithSimpleFile :: (Member (Program StdIoAPI) r, Member (Program SimpleFileAPI) r) => (String -> String) -> String -> Eff r () verboseWithSimpleFile f fp = writeStrLn ("verboseWithSimpleFile on " ++ fp) >> withSimpleFile f fpThat type is surprisingly clear I find, albeit a bit on the long side. Running it is just a matter of combining runStdIo and runSimpleFile.

> :! cat test.txt Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec a diam lectus. Sed sit amet ipsum mauris. Maecenas congue ligula ac quam viverra nec consectetur ante hendrerit. > runLift $ runSimpleFile $ runStdIo $ verboseWithSimpleFile (map toUpper) "test.txt" verboseWithSimpleFile on test.txt > :! cat test.txt_new LOREM IPSUM DOLOR SIT AMET, CONSECTETUR ADIPISCING ELIT. DONEC A DIAM LECTUS. SED SIT AMET IPSUM MAURIS. MAECENAS CONGUE LIGULA AC QUAM VIVERRA NEC CONSECTETUR ANTE HENDRERIT.Oh, and it doesn’t matter in what order the interpreters are run!

At this point I got really excited about Eff because now it’s obvious that I’ll be able to write the logging “decorator”, in fact it’s clear that it’ll be rather simple too.

The loggingAs before I start with a data type and a convenience function

data LoggerAPI a where Log :: String -> LoggerAPI () logStr :: Member (Program LoggerAPI) r => String -> Eff r () logStr = singleton . LogFor the decorating I can make use of the fact that APIs can be combined like I did above. That is, I don’t need to bother with any *coproduct* (Sum) or anything like that, I can simply just push in a call to logStr before each use of SimpleFileAPI

Of course an interpreter is needed as well

runLogger :: (Member (Lift IO) r, SetMember Lift (Lift IO) r) => Eff (Program LoggerAPI :> r) a -> Eff r a runLogger = runProgram f where f :: (Member (Lift IO) r, SetMember Lift (Lift IO) r) => LoggerAPI a -> Eff r a f (Log s) = lift $ putStrLn sRunning is, once again, a matter of stacking interpreters

> :! cat test.txt Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec a diam lectus. Sed sit amet ipsum mauris. Maecenas congue ligula ac quam viverra nec consectetur ante hendrerit. > runLift $ runLogger $ runSimpleFile $ runProgram logSimpleFileOp $ withSimpleFile (map toUpper) "test.txt" LoadFile test.txt SaveFile test.txt_new > :! cat test.txt_new LOREM IPSUM DOLOR SIT AMET, CONSECTETUR ADIPISCING ELIT. DONEC A DIAM LECTUS. SED SIT AMET IPSUM MAURIS. MAECENAS CONGUE LIGULA AC QUAM VIVERRA NEC CONSECTETUR ANTE HENDRERIT. Closing thoughtsWith Eff I’ve pretty much arrived where I wanted, I can

- define APIs of operations in a simple way (simpler than when using Free even).
- write a definitional interpreter for the operations.
- combine two different APIs in the same function.
- translate from one API to another (or even to a set of other APIs).

On top, I can do this without having to write a ridiculous amount of code.

I’m sure there are drawbacks as well. There’s a mention of some of them in the paper. However, for my typical uses of Haskell I haven’t read anything that would be a deal breaker.

### Haskell code snippets for sqlite access for an NLP project

### Typesafe request/response?

### Help with Reader monad

### Does this exist in base?

### Richard Eisenberg: Haskell as a gradually typed dynamic language

I spent a few days this week at POPL (one day too short due to a massive blizzard currently pounding Philadelphia). As always at conferences, I had a great time and left full of new ideas.

This time, I sat in on a series of talks on gradual typing. Forgive me as I’m nowhere near an expert on gradual typing, but I took away this gist: with a gradual typing system, a type-checker does the best it can to assign static types; anything it can’t do is deferred to runtime in a dynamic type check.

As I nearly always do when considering a type system concept, I thought about how this might apply to Haskell. And I realized with a start that Haskell is only a stone’s throw away from a very spiffy gradually typed dynamic language! Let’s explore how this is the case.

(Disclaimer: I have no plans to implement any idea in this post. I also apologize, specifically, if I’m misusing the term “gradual typing”, which I’m not deeply versed in. This is all meant to be a bit tongue-in-cheek, though I think there’s a proper good idea in all of this.)

First, I wish to address a common fallacy about an existing feature in GHC:

Deferred type errors do not make Haskell a dynamic languageRecent versions of GHC come with a flag -fdefer-type-errors. (Naturally, this feature comes with its own published paper from ICFP’12.) With this flag enabled, type errors become warnings. When you try to run the code that contains a type error, you get a runtime exception. To wit:

> {-# OPTIONS_GHC -fdefer-type-errors #-} > module GradualHaskell where > > import Data.Typeable > > ex1 = not 'x'Compiling produces

/Users/rae/work/blog/011-dynamic/post.lhs:32:13: warning: • Couldn't match expected type ‘Bool’ with actual type ‘Char’ • In the first argument of ‘not’, namely ‘'x'’ In the expression: not 'x' In an equation for ‘ex1’: ex1 = not 'x'Running produces

*** Exception: /Users/rae/work/blog/011-dynamic/post.lhs:32:13: error: • Couldn't match expected type ‘Bool’ with actual type ‘Char’ • In the first argument of ‘not’, namely ‘'x'’ In the expression: not 'x' In an equation for ‘ex1’: ex1 = not 'x' (deferred type error)What’s nice about deferred type errors is that they let you compile a program even with errors. You can then test the type-correct parts of your program while you’re still developing the type-incorrect parts.

However, deferred type errors don’t make Haskell a dynamic language.

Consider

> silly :: a -> b > silly True = False > silly False = "Howdy!" > silly 'x' = 42This, of course, compiles with lots of warnings. But you can’t successfully call silly, even at one of the values matched against. Running silly True produces a runtime type error. This is not what one would expect in a dynamic language, where silly True is perfectly False. The problem in Haskell is that we have no way to know if the type silly is called at is really Bool: all types are erased. All deferred type errors do is to take the normal compile-time type errors and stuff them into thunks that get evaluated when you force the ill-typed expression. Haskell still never does a runtime type check.

Preserving type information to runtimeThe way to make Haskell into a proper dynamic language must be to retain type information to runtime. But we already have a way of doing runtime type checks: Typeable and friends.

The constraint Typeable a means that we know a’s type at runtime. The Typeable interface (from Data.Typeable) includes, for example, the function

cast :: (Typeable a, Typeable b) => a -> Maybe bwhich does a runtime type equality test and, if the test succeeds, casts an expression’s type.

As of GHC 7.10, all statically-known types are Typeable. (Saying deriving Typeable is a no-op.) But type variables might still have a type unrecoverable at runtime.

So, all of this adds up to an interesting idea. I propose a new language extension -XDynamicTypes with two effects:

- All type variables automatically get a Typeable constraint.
- The type-checker behaves quite like it does with -fdefer-type-errors, but instead of putting an unconditional type error in an expression, it does a runtime type check. If the check succeeds, the expression evaluates normally; otherwise, a runtime error is thrown.

Change (1), coupled with the fact that all non-variable types are already Typeable, means that all types are known at runtime. Then, change (2) enabled runtime typing. Under this scenario, my silly function above would elaborate to

> forceCast :: (Typeable a, Typeable b) => a -> b > forceCast x = case cast x of > Just y -> y > Nothing -> error "type error" -- could even print the types if we wanted > > notSilly :: (Typeable a, Typeable b) => a -> b > notSilly true | Just True <- cast true = forceCast False > notSilly false | Just False <- cast false = forceCast "Howdy!" > notSilly x | Just 'x' <- cast x = forceCast (42 :: Int)This definition works just fine. It does do a lot of casting, though. That’s because of silly’s very general type, a -> b, which is necessary due to the differing types of silly’s equations. However, if all the equations of a function have the same type, then the function is inferred with a precise type, and no casting is necessary. Indeed, in a program that is type-correct without -XDynamicTypes, no runtime checks would ever take place.

This idea seems to give you get the flexibility of dynamic types with the speed of static types (if your program is statically type-correct). And this general model seems to fit exactly in the space of possibilities of gradual type systems.

I’ve heard it said that Haskell is the best imperative programming language. Could it also become the best dynamic language?