They are so interesting they’ve been described as a disruptive technology in formal methods. They are more automated than interactive theorem provers, while still providing high-end expressive capability.

And they’re growing in use in industrial applications. In the Cryptol toolset, for example, SMT solvers are used to determine if two implementations of a cryptographic function are functionally identical;  Microsoft uses SMT solvers for device driver verification; and they’ve been used for large scale test generation, planning and routing problems.

The challenge now is to make such power easily available to programmers without a formal methods background.

To do this, my approach is to embed the SMT solver into a good programming language, as an embedded DSL. Embedded languages let us hide significant complexity, using the host language’s combining forms to build up complex structures from simple primitives — instead of starting with a complex API in the first place.

If you already know the host language, you can program in the EDSL. If you know Haskell, you can program an SMT solver.

The code is available:

• cabal install yices-painless (depends on an install of Yices from SRI)
• darcs get http://code.haskell.org/~dons/code/yices-painless/
• Haddock documentation (since Hackage won’t generate the docs without Yices headers)

Scripting a Solver

SMT solvers are typically scripted in an imperative fashion: variables are declared, and then facts about those variables are asserted, step by step. The resulting set of declarations is passed to the solver to determine satisifiability (and to find any satisfying values to assign to the variables, if possible). From a programming language perspective, these declarations and assertions look like (typed) (pure) functions with free variables.

The standard SMT-LIB format (accepted by most SMT solvers) looks something like:

(define p::bool)
(define q::bool)
(define r::bool)
(assert (=> (and (=> p q) (=> q r)) (=> p r)))

Which we’ll write in our EDSL in Haskell as:

\p q r -> (p → q && q → r) → (p → r)

Haskell’s type inference can fill in the types in the EDSL, and infix notation also helps clean things up.

Such a proposition may be passed to a solver, like so:

> solve $ \p q r -> (p → q && q → r) → (p → r)


Satisfiable!
r => False
q => True
p => True

We start with something that looks like a Haskell function (but is actually a function in the EDSL), which can be interpreted by a solver, with Haskell’s language machinery filling in types, and checking safety.

In this post I’ll talk about how I designed yices-painless, an EDSL that embeds SMT scripting support deeply into Haskell (deeply, in that the Haskell type system will check the types of the SMT propositions). The work is based on the language embedding approach taken by Chakravarty et al’s, accelerate arrays language (for GPU programming), using higher-order abstract syntax to support elegant variable binding, with a type-preserving translation to a form that can be executed by the underlying solver.

Designing the EDSL

For a client problem at work, I was interested in trying an SMT solver.  The Yices SMT solver from SRI is a high-performance SMT solver with a well-documented C interface, which is a good place to start experimenting. The design challenge was to get from the imperative C interface we have to use, to the typed, pure Haskell embedding that we want to write.

To do this, we build up several layers of abstraction, each one removing redundancy and hiding unnecessary complexity:

1. The base layer, Yices itself, a big blob of compiled C or C++ code, exporting 150+ functions.
2. Yices.Painless.Base.C: Stitching Yices to Haskell via a full (and straightforward) FFI bindings (150+ Haskell functions, and a few types)
3. Yices.Painless.Base: The FFI bindings are just as unsafe as the C layer, so in the next abstraction layer we automate the resource managment, use native Haskell types, and native Haskell abstractions (e.g. lazy lists instead of iteratees). The number of functions exposed is reduced as a result, making the API simpler. This layer is still imperative (all functions are in IO), but relatively useful.
4. Yices.Painless.Language: The AST layers are the big step up in expressive power: we design an abstract syntax tree to represent the embedded language, along with a set of primitive functions and types. This pure data structure will be interpreted (or compiled to SMT-LIB format), generating calls to the imperative layer. We thus have very strong separation between the messy, error-prone imperative model, and the correct-by-construction pure AST.  We have just simple constants, variables, conditions and a handful of (polymorphic) primitive functions, relying on the language to build up complex expressions from a few simple forms.
5. Surface Syntax: Finally, we expose the EDSL language via smart surface syntax, overloaded via Haskell’s type classes: Bits, Num, String. And now programmers need only use Haskell’s native math and bit functions, syntax and types, to build propositions. Type inference and checking works, as well as proper scoping of variables in the propositions. This user-facing layer looks and feels exactly like Haskell, yet it is translated to a form that drives an imperative C library.

The surface layer reveals the power of a good EDSL: hiding unnecessary complexity, increasing expressivity (compare the few functions (and combinators) in the EDSL layer at the top, with the 150+ functions in the C API).

The EDSL reduces the cognitive load on the programmer by an order of magnitude.

Implementation

The Base Layers

The base layers are  the most straightforward part of the system. First, we write  a natural FFI binding to every function exposed by the Yices C API. Each C function gets an FFI import; value types are represented by types defined in the Haskell FFI report (e.g. CInt, CString), while Yices types allocated and controlled by Yices are typed in Haskell with empty data  types (e.g. YExpr), giving us increased type safety (compared to using void pointers).

The FFI layer is then wrapped in resource handling code, hiding a set of functions from an C++ iterator behind a single function returning a lazy list). The FFI bindings are about 350 lines of code; the wrapper layer another 500. Most of this can be generated.

The Typed AST

Following Chakravarty’s approach, we represent the embedded language with a surface syntax (supporting numerical and scalar polymorphic operations), which builds a nameless AST  (variables in the EDSL are represented as Haskell variables). The typed embedding gives us a type checker for the DSL for free. The AST is decorated with type information, so we can resolve overloading (in the EDSL), and do other type-based operations. The EDSL itself is just over 1000 lines of Haskell.

The language is relatively simple: variables (of any scalar type), literals (of any scalar type), conditionals, and a range of built-in functions. Variables are bound/quantified at the top level of the EDSL.

data Exp t where
    Tag         :: (IsScalar t) => Int        -> Exp t
    Const       :: (IsScalar t) => t          -> Exp t
    Cond        :: Exp Bool -> Exp t -> Exp t -> Exp t
    PrimApp     :: PrimFun (a -> r) -> Exp a  -> Exp r

data PrimFun t where
    PrimEq   :: ScalarType a -> PrimFun ((a, a) -> Bool)
    PrimNEq  :: ScalarType a -> PrimFun ((a, a) -> Bool)

    PrimAdd  :: NumType a -> PrimFun ((a, a) -> a)
    PrimSub  :: NumType a -> PrimFun ((a, a) -> a)
    PrimMul  :: NumType a -> PrimFun ((a, a) -> a)
    ...

We can expose these via a type class interface for Exp things, yielding nice surface syntax: (+), (*), (==*), and (/=*). It isn’t possible to write sensible instance of Eq, sadly, as those Haskell type classes wire in return types of Bool (instead of a polymorphic Boolean class). We have to redefine (==) instead.

instance (IsNum t) => Num (Exp t) where
  (+)         = mkAdd
  (-)         = mkSub
  (*)         = mkMul

infix 4 ==*, /=*, <*, <=*, >*, >=*

-- | Equality lifted into Yices expressions.
(==*) :: (IsScalar t) => Exp t -> Exp t -> Exp Bool
(==*) = mkEq

-- |Inequality lifted into Yices expressions.
(/=*) :: (IsScalar t) => Exp t -> Exp t -> Exp Bool
(/=*) = mkNEq

The smart constructors build AST nodes, with type information added:

mkAdd :: (IsNum t) => Exp t -> Exp t -> Exp t
mkAdd x y = PrimAdd numType `PrimApp` tup2 (x, y)

mkMul :: (IsNum t) => Exp t -> Exp t -> Exp t
mkMul x y = PrimMul numType `PrimApp` tup2 (x, y)

mkEq   :: (IsScalar t) => Exp t -> Exp t -> Exp Bool
mkEq   x y = PrimEq  scalarType `PrimApp` tup2 (x, y)

mkNEq  :: (IsScalar t) => Exp t -> Exp t -> Exp Bool
mkNEq  x y = PrimNEq scalarType `PrimApp` tup2 (x, y)

Converting to de Bruijn form

This nameless form (via surface syntax) is convenient to write, and solves all the issues with binders for us, but harder to optimize (as propositions are reprsented as opaque functions). So this form is then converted to a form with explicit variables (represented as de Bruijn indices into a variable environment). The approach is identical to the one taken in the accelerate EDSL, with the change that at the top level we support n-ary functions (to represent propositions with n free variables).

Thanks to Trevor Elliott, and for historical reference, we can convert n-ary functions to their de Bruijn form via a type class, yielding a common type for propositions with arbitrary variables: :: Yices f r => f -> Prop r

Running the Solver

Once we’ve built the AST for the proposition, and replaced all variables with their de Bruijn tags, we can now execute the proposition, recursively calling Yices operations to reconstruct the AST on the Yices side, before asking to solve, finding a satisfying assignment of variables (or not), and returning a model of the bindings.

solve :: (Yices f r) => f -> IO Result
solve q = do
    c <- Yices.mkContext
    Yices.setTypeChecker True
    let t = convertYices q -- convert to de Bruijn form
    (g,e) <- execY c t     -- build a Yices expression representing the AST
    Yices.assert c e       -- register it with Yices
    Yices.check c          -- check for satisfiability, returning the result

Related Work

There’s quite a few bindings to Yices (in particular) in Haskell, but none on Hackage (at the time of writing) done as a deep EDSL (ensuring type safety and lexical scoping). The original inspiration for  the work was yices-easy, which exposes a monadic, shallow DSL — and has a good tutorial.

Significant related work is by my colleague at Galois, Levent Erkok, who simultaneously developed “SBV”, a deep EDSL that does support sharing and SMT-LIB access, via heavy type class use. We’ll be sharing code.

The approach to embedding taken is based on the one found in accelerate, which shares similarities with Atkey, Lindley and Yallop‘s approach. The general idea of de Bruijn/HOAS translations was introduced by McBride and McKinna.

Future Work

At the moment, this is basically a proof of concept. Simple propositions can be solved, but its not ready for large scale problems. A few things need to be done:

• Support for sharing in the AST. The EDSL currently loses sharing information, duplicating terms. This isn’t feasible for large problems.
• Operations that require certain sizes of bit vector should check those sizes (e.g. via Iavor Diatchki’s type level natural support for Haskell).
• Support deriving encodings from new Haskell types into Yices types.
• Support for lists, tuples and arrays of variables (some problems have very large numbers of variables)
• Supporting function types.
• Compile the AST to SMT-LIB statements (instead of Yices FFI calls), making it independent of a particular SMT solver (or solver’s license).
• Use it on some big problems.

I’ll be continuing work on this in 2011, and would welcome patches, feedback and use cases.

Semantics of the Inception computational environment

• “Dream” == thread of control == forkIO
• A thread must stay at each level (thread group) for it not to collapse (dreamer)
• Messages can be sent down (music) – e.g. async message passing
• A kick exits a thread up one level (“die”) – throwTo KillThread
• Time degrades quickly 10, 3 mins , 10 mins , 10 years – so adjust scheduler time slices based on levels
• Groups of threads brought together by the dreamer can enter a new environment together (collaborative dreaming) – shared heap
• Arbitrary effects are allowed, (yep, it has IO at the bottom)
• Under sedation, you can disassociate a thread from its control stack, and it is in limbo (some “init” thread group), until it remembers.
• Tokens are (unique) depth counters (0, many).

Your challenge:

• Improve Claessen’s “poor man’s concurrency monad” to support the Inception environment.
• What notion of `bind` and `return` are used?
• Show that the monad laws are satisfied.
• import Control.Monad.Inception and win!

Refer to the published analysis on the use of the inception monad you need to be able to support.

• The Haskell Platform
• Hackage
• Cabal

You can read the slides as PDF here, or online:

The amount of freely available Haskell code has grown exponentially in the past
two years as Hackage and Cabal have come online. Managing millions of Haskell
code, partitioned thousands of interdependent packages is a serious engineering
challenge that has received little attention from the language research community.
Meanwhile, new adopters of Haskell struggle to deal with the sheer number of
libraries and tools now available.

One pragmatic approach to managing this web is the Haskell Platform (HP), a
project to build a blessed, comprehensive set of libraries meeting objective
quality control criteria, and in doing so make expert recommendations on which
packages to use. In its first six weeks of operation the HP had over forty
thousand downloads.

The challenge with such a project is to manage the many conflict constraints
for diversity, coverage, and quality when assembling the package set. This talk
will outline the state of the Haskell Platform, the technical approaches taken
to build it, and the roadmap ahead.

Shell scripts are often a quick, dirty way to get the job done. You glue
together external tools, maybe do a little error checking and process all data
as strings. This is great for some very simple problems but as requirements
change and more is demanded from the code shell scripts become unwieldy and
fragile. When they get large, they become slow and difficult to maintain. If
you need to write robust code then shell is not the way to go.

In this talk at an alternative: how to use Haskell as a type checked and
natively compiled language for scripting tasks. By refining the semantics of
the problem domain, employing abstraction, we produce shorter and more robust
code, that is more maintainable and scalable.

The specification, along with installers (including Windows, Apple and
Unix installers for a full Haskell environment) are available.

The Haskell Platform is a single, standard Haskell distribution for every system, in the form of a blessed library and tool suite for Haskell distilled from the thousands of libraries on Hackage, along with installers for a wide variety of systems. It saves developers work picking and choosing the best Haskell libraries and tools to use for a task.

When you install the Haskell Platform, you get the latest stable compiler, an expanded set of core libraries, additional development tools, and cabal-install – so you can download anything else you need from Hackage.

What you get is specified here.

– The Platform Infrastructure Team

Abstract

Galois has been building software systems in Haskell for the past decade. This talk describes some of what we’ve learned about in-the-large, commercial Haskell programming in that time. I’ll look at when and where we use Haskell. At correctness, productivity, scalabilty, maintainability, and what language features we like: types, purity, types, abstractions, types, concurrency, types!

We’ll also look at the Haskell toolchain: FFI, HPC, Cabal, compiler, libraries, build systems, etc, and being a commercial entity in a largely open source community.

Previously I’ve had good success exploring multi-variable spaces for optimizations with GAs in Haskell, to find strictness flags and LLVM flag settings, so I was keen to see what the GC space looked like. In this initial GC search, however, I don’t use a GA, instead just measuring time as two variables change over the entire space.

Here’s an example for the binary-trees language shootout benchmark, where the GHC default settings are known to be suboptimal (the benchmark disallows changes to the default runtime GC settings):

Running time of the binary-trees benchmark as -A and -H vary

The flags we use are:

• -A, the size of the initial thread allocation area for the youngest generation.
• -H, the suggested overall heap size

ghc-gc-tune, in the style of ghc-core, wraps a compiled Haskell program, and runs it with varying values of -A and -H, recording various statistics about the program. The output can be rendered interactively, or to png, pdf or svg. It would augment use of heap profiling, ThreadScope and ghc-core for analyzing and improving Haskell program behavior.

In this case, ghc-gc-tune recommends the somewhat surprising -A64k -H32M, and binary-trees runs in 1.12s at N=16, while for the default GC settings it completes in 1.56s. So ghc-gc-tune found settings that improved performance by 28%.  Nice.

I already knew that a large -A setting helped this program (corresponding to the broad plateau for large -A values in the above graph), however, I was surprised to see the best result was with a very small -A setting, and medium sized -H setting, resulting in only 5% of time spent in GC, and 36M total allocated — the narrow valley on the far side of the graph. Very interesting! And is that my L2 cache in the square at x= 2M, y = 2M? Sure looks like it.

Here’s a video of the same graph in the tool’s interactive mode (without any -t flag):

Currently, the sampling is vary simplistic, with a fixed set of logscale values taken. A clever sampling algorithm would measure the heap used in the default case, and compute a range based on that, possibly with cutoffs for very pessimistic GC flags.

Another example: pidigits, with what I would consider far more typical behavior. Though again, a surprisingly small -A setting does well, and there’s an interesting pathological result with extremely large -H and very small -A settings.

PiDigiits GC space

You can get ghc-gc-tune from Hackage, via cabal, and note that it requires gnuplot installed. Let me know if you find it useful, and I welcome patches!

Future work will be to graph the Z axis as space, instead of time (so we can find GC settings that minimize the footprint), as well as adding other variables (such as parallel GC settings, and varying the number of generations).

Hackage is the central repository of open source Haskell libraries and tools. Once they install the Haskell Platform, users get more libraries from Hackage, via “cabal install”.

Headlines

May was the most popular month for Hackage ever, breaking 150k downloads in a single month for the first time.

The 2000th Haskell package was released on April 16.

Total downloads on Hackage since 2006 have passed 2.4 million, with 780 thousand downloads in 2010 so far (double the total from the same time in 2009).

Totals

Total cabal packages: 2182. (+ 208 in Q2).

Total contributing developers: 575 (42 new developers in Q2)

90 day moving average: 12 packages per day uploaded.

Total downloads from Hackage 2007-present: 2.42 million

Average monthly downloads in 2010: 130 thousand.

Top of the Pops

The top 15 most popular libraries in the first half of 2010 were:

1. HTTP
2. parsec (+1)
3. zlib (-1)
4. binary (+1)
5. network (+2)
6. utf8-string (-2)
7. Cabal (+1)
8. QuickCheck (-2)
9. mtl (+1)
10. haskell-src-exts (-1)
11. regex-base
12. deepseq (+6)
13. ghc-paths (+2)
14. hslogger (+6)
15. regex-posix (-2)

Top 15 most popular applications in the first half of 2010:

1. cabal-install
2. xmonad
3. haddock (+1)
4. cpphs (-1)
5. happy
6. darcs (+1)
7. alex (+1)
8. hscolour (-2)
9. pandoc
10. hlint
11. leksah
12. xmobar
13. yi
14. hint
15. agda

Honorable Mentions

• The Galois xml library was more popular in the first half of 2010 than HaXml, dethroning HaXml for the first time.
• text has made it into the top 30 libraries
• HDBC continues to be the most popular database library
• vector has almost surpassed array in downloads (array is part of the Haskell Platform though)
• wxHaskell is still more popular than gtk2hs on Hackage,  though gtk2hs has almost caught up.

You can read all the 2010 data for your favorite packages, and ranked by 2010 popularity.

Top Libraries by Category

• Networking: HTTP, network, network-bytestring, curl
• Parsing: parsec, polyparse, attoparsec
• Compression: zlib, zip-archive
• Binary formats: binary, cereal
• Text formats: utf8-string, text, dataenc
• Markup: pandoc, xhtml, tagsoup, html
• JSON: json
• Atom/RSS: feed
• XML: xml, HaXml, hexpat
• Web services:  happstack, snap
• GUIs: wxHaskell, gtk2hs
• Graphics: SDL, cairo, gd
• Templates: HStringTemplate
• Testing: QuickCheck, HUnit, testpack, hpc
• Control: mtl, transformers, monads-fd
• Languages: haskell-src-exts, haskell-src, HJavaScript
• Regexes: regex-{base,posix,compat,tdfa}, pcre-light
• Logging: hslogger
• Generics: uniplate, syb-with-class, syb
• 3D: OpenGL
• Edit history: haskeline
• Concurrency and parallelism: parallel, stm
• Databases: HDBC
• Arrays: array, vector, hmatrix
• Hashing: pureMD5, SHA
• Data structures: containers, fingertree, dlist
• Science:  statistics
• Benchmarking: criterion
• Storage: hs3

Is there anything else you see in the data?

Here are the slides (::PDF), and the source that accompanied the tutorial:

The abstract for  the session:

Haskell is a functional language built for parallel and concurrent programming. You can take an off-the-shelf copy of GHC and write high performance parallel programs right now. This tutorial will teach you how to exploit parallelism through Haskell on your commodity multicore machine, to make your code faster. We will introduce key parallel programming models, as implemented in Haskell, including:

• semi-explicit parallelism via sparks
• explicit parallelism via threads and shared memory
• software transactional memory

and look at how to build faster programs using these abstractions. We will also look at the engineering considerations when writing parallel programs, and the tools Haskell provides for debugging and reasoning about parallel programs.

This is a hands on tutorial session: bring your laptops, there will be code!

In fact, it’s kind of startling to look back: in 2006, there were only a handful of open source Haskell libraries for developers to use in their projects (just HDBC, zlib, libxml, Crypto…). Today, there are 2121 (more by the time you read this) libraries for Haskell, available as source on http://hackage.haskell.org (only a “cabal install” away), and often 100s of Haskell libraries in binary form on your favorite distro. You can even follow the package flood on Twitter.

Here’s what the growth in available Haskell libraries over the last 4 years looks like:

We passed 1000 libraries in early 2009, and doubled that a year later.

So this is great for the Haskell dev community. In some areas, like database interfacing, we’ve gone from a single option (HDBC) to a full range, including new stuff like, uh, well, Cassandra, CouchDB, Amazon SimpleDB, MongoDB, Tokyo Cabinet, and pure Haskell libs like TCache, or safe, high level libs like HaskellDB.

We’re rapidly running into CPAN-like problems of just managing the weight of so much Haskell code. How do you know which one to use? Should you use, say, Galois’ xml library, or Lemmih’s xml library? . Someone recently said “It is bewildering trying to figure out which ones are actively supported and which ones are zombie projects that stopped working years ago.”

So what are we doing about it?

There are four efforts underway to help Haskellers manage this work, and you can contribute!

1. The Haskell Platform – a easy, one-click installer for the core system, including a blessed set of libraries, with a commercially friendly BSD license (like most of Hackage). At the moment, this means just these libraries, and we need developers to propose new additions to the blessed set.
2. Google Summer of Code: Hackage 2.0 – we have Matt Gruen working this summer to finish the implementation of Hackage 2.0 – an improved Hackage that will allow for many new features to help sort out the wheat from the chaff in Haskell packages: build reports, wiki commenting, and social voting.
3. Google Summer of Code: Cabal Test: we also have Thomas Tuegel working on “cabal test”  – to allow automated testing and reporting of cabalized (and thus, all of Hackage). This is the second plank in the solidifying the quality assurance story for Hackage.
4. Regular regression testing of Hackage: having all that code is great – it means we can do regular regression testing of compilers and tools on a multi-million line Haskell codebase. For the 6.10 GHC release, for example, we were able to narrow breakages of all known open source Haskell to just 5% of Hackage, and post detailed instructions on how to address those changes. This gives us significant stability.

So, the HP to make it simpler to install Haskell and get started with a good set of libraries (several hundred thousand downloads of the installers so far!), a better Hackage to help us rate and rank packages, regression testing against Hackage to keep things stable, and in particular, test reporting support to make it easier to do quality assurance estimates.

How would you like to see changed in the Haskell library world? What libraries do you love? What do you hate? How do you find the packages you need?

And you don’t have to wait for others to solve this. Write tools to pick the best libs. Do your own quality ratings and share them. Write reviews of packages, and compare them, then let everyone know.

This is open source – it is up to you to help make things happen.