diff --git a/.ghci b/.ghci new file mode 100644 --- /dev/null +++ b/.ghci @@ -0,0 +1,1 @@ +:set -isrc diff --git a/.gitignore b/.gitignore new file mode 100644 --- /dev/null +++ b/.gitignore @@ -0,0 +1,45 @@ +dist +cabal-dev +.hsenv +*.md +*.o +*.hi +*.chi +*.chs.h +.virthualenv +*.a +*.cmxa +*.cm[oxai] +*.annot +*.vmap +*.di? +*.native +*.fqout +*.out +*.fq +*.bfq +*.annot +*.cgi +*.log +*.html +*.pyc +build.sh +config.make +*.scalarlog +*.tags +_build +*~ +*.swp +*.swo + +/.stack-work/ +/.vagrant/ +TAGS +a.out +*.json +js/ +css/ + +*.smt2 +.liquid +.dir-locals.el diff --git a/.gitmodules b/.gitmodules new file mode 100644 --- /dev/null +++ b/.gitmodules @@ -0,0 +1,9 @@ +[submodule "liquid-fixpoint"] + path = liquid-fixpoint + url = https://github.com/ucsd-progsys/liquid-fixpoint.git +[submodule "ghc-options"] + path = ghc-options + url = https://github.com/ranjitjhala/ghc-options.git +[submodule "liquiddesugar"] + path = liquiddesugar + url = https://github.com/christetreault/liquiddesugar.git diff --git a/.travis.yml b/.travis.yml new file mode 100644 --- /dev/null +++ b/.travis.yml @@ -0,0 +1,70 @@ +sudo: false +language: c + +# Only build master, develop, and PRs +branches: + only: + - master + - develop + +addons: + apt: + packages: + - libgmp-dev + - z3 + +# Caching so the next build will be fast too. +cache: + directories: + - $HOME/.stack + - .stack-work + +before_install: +# Download and unpack the stack executable +- mkdir -p ~/.local/bin +- export PATH=$HOME/.local/bin:$PATH +- travis_retry curl -L https://www.stackage.org/stack/linux-x86_64 | tar xz --wildcards --strip-components=1 -C ~/.local/bin '*/stack' +- travis_retry stack install cabal-install +# - scripts/travis install_smt "$SMT" + +env: + global: + # - STACK=1.0.0.0 + - SMT=z3 + - GHC=ghc-7.10.3 + matrix: + - TESTS=Unit/ + - TESTS=Benchmarks/text + - TESTS=Benchmarks/bytestring + - TESTS=Benchmarks/esop + - TESTS=Benchmarks/vect-algs + - TESTS=Benchmarks/icfp* + + # ugh... Classify.hs is too slow and makes travis think the build is stalled + # - TESTS=hscolour + +# This line does all of the work: installs GHC if necessary, build the library, +# executables, and test suites, and runs the test suites. --no-terminal works +# around some quirks in Travis's terminal implementation. +#script: +#- stack $ARGS --no-terminal --install-ghc test liquidhaskell --haddock --no-haddock-deps --test-arguments "-j2 -p $TESTS" + +install: + # - scripts/travis install_stack "$STACK" + - scripts/travis configure_stack "$GHC" + - scripts/travis setup_ghc + - scripts/travis install_dependencies + +script: + - scripts/travis do_build && scripts/travis do_test "$TESTS" "$SMT" + +after_failure: + - scripts/travis dump_fail_logs + +notifications: + slack: + rooms: + secure: CPaI+XVTUSM9gLQefB8zSXazawNIaUnClS7FwaujPfM37hNBm5UIoiC80KBEe0KZKBr+Gt/LWq0zv506Zl/vILuPpVmfSi2BQ8zyyKCBbUrE/E0uBTjmT7wjaITf/mn3mqiLLcHbAVXI1bn7HzVvAq4S4eIpttgCapF7pbMhZCk= + on_success: change + on_failure: always + on_start: never diff --git a/AwakeTODO.md b/AwakeTODO.md new file mode 100644 --- /dev/null +++ b/AwakeTODO.md @@ -0,0 +1,6 @@ +- see the Category issue +- set-up atom +- see Jeff's thread on Monoids +- write a prefix checker +- check the parser paper +- check gab's slides diff --git a/CHANGES.md b/CHANGES.md new file mode 100644 --- /dev/null +++ b/CHANGES.md @@ -0,0 +1,169 @@ +# Changes + +## NEXT + +- **breaking change** Remove the `Bool` vs. `Prop` distinction. This means that: + + * signatures that use(d) `Prop` as a type, e.g. + `foo :: Int -> Prop` should just be `foo :: Int -> Bool`. + + * refinements that use(d) `Prop v` e.g. + `isNull :: xs:[a] -> {v:Bool | Prop v <=> len xs > 0}` + should just be `isNull :: xs:[a] -> {v:Bool | v <=> len xs > 0}`. + +- Add `--eliminate={none, some, all}`. Here + * `none` means don't use eliminate at all, use qualifiers everywhere (old-style) + * `some` which is the **DEFAULT** -- means eliminate all the **non-cut** variables + * `all` means eliminate where you can, and solve *cut* variables to `True`. + +- Change `--higherorder` so that it uses *only* the qualifiers obtained from + type aliases (e.g. `type Nat = {v:Int | ... }`) and nothing else. This + requires `eliminate=some`. + +- Add a `--json` flag that runs in quiet mode where all output is + suppressed and only the list of errors is returned as a JSON object to be + consumed by an editor. + +- Add `--checks` flag (formerly `--binders`), which checks a given binder's + definition, assuming specified types for all callees (but inferring types for + callees without signatures.) + +- Add `--time-binds` which is like the above, but checks all binders in a module + and prints out time taken for each. + +## 0.5.0.1 + +- Fixed a bug in the specification for `Data.Traversable.sequence` +- Make interpreted mul and div the default, when `solver = z3` +- Use `--higherorder` to allow higher order binders into the fixpoint environment + +## 0.5.0.0 + +- Added support for building with `stack` + +- Added support for GHC 7.10 (in addition to 7.8) + +- Added '--cabaldir' option that will automatically find a .cabal file in the ancestor + path from which the target file belongs, and then add the relevant source and dependencies + to the paths searched for by LiquidHaskell. + + This means we don't have to manually do `-i src` etc. when checking large projects, + which can be tedious e.g. within emacs. + + +## 0.4.0.0 + +- Bounds as an alternative for logical constraints see `benchmarks/icfp15/pos/Overview.lhs` + +## 0.3.0.0 + +- Logical constraints: add extra subtyping constraints to signatures, e.g. + + {-@ + (.) :: forall

c -> Prop, q :: a -> b -> Prop, r :: a -> c -> Prop>. + {x::a, w::b |- c

<: c} + (y:b -> c

) + -> (z:a -> b) + -> x:a -> c + @-} + (.) f g x = f (g x) + +- Inlining haskell functions as predicates and expressions, e.g. + + {-@ inline max @-} + max x y = if x >= y then x else y + +- Refining class instances. For example + + {-@ instance Compare Int where + cmax :: Odd -> Odd -> Odd @-} + +- Major restructuring of internal APIs + +## 0.2.1.0 +- Experimental support for lifting haskell functions to measures +If you annotate a Haskell function `foo` with {-@ measure foo @-}, LiquidHaskell will attempt to derive an equivalent measure from `foo`'s definition. This should help eliminate some boilerplate measures that used to be required. + +## 0.2.0.0 + +- Move to GHC-7.8.3 +LiquidHaskell now *requires* ghc-7.8.3. + +- Termination +LiquidHaskell will now attempt to prove all recursive functions terminating. It tries to prove that some parameter (or combination thereof) decreases at each recursive callsite. By default, this will be the first parameter with an associated size measure (see Size Measures), but can be overridden with the `Decreases` annotation or a termination expression (see Termination Expressions). + +If proving termination is too big of burden, it can be disabled on a per-module basis with the `--no-termination` flag, or on a per-function basis with the `Lazy` annotation. + +- Size Measures +Data declarations now optionally take a *size measure*, which LiquidHaskell will use to prove termination of recursive functions. The syntax is: + + {-@ data List a [len] = Nil | Cons a (List a) @-} + +- Termination Expressions +Termination Expressions can be used to specify the decreasing metric of a recursive function. They can be any valid LiquidHaskell expression and must be placed after the function's LiquidHaskell type, e.g. + + {-@ map :: (a -> b) -> xs:[a] -> [a] / [len xs] @-} + +- Type Holes +To reduce the annotation burden, LiquidHaskell now accepts `_` as a placeholder for types and refinements. It can take the place of any base Haskell type and LiquidHaskell will query GHC to fill in the blanks, or it can take the place of a refinement predicate, in which case LiquidHaskell will infer an appropriate refinement. For example, + + {-@ add :: x:_ -> y:_ -> {v:_ | v = x + y} @-} + add x y = x + y + +becomes + + {-@ add :: Num a => x:a -> y:a -> {v:a | v = x + y} @-} + add x y = x + y + +- Assumed Specifications +The `assume` annotation now works as you might expect it to, i.e. LiquidHaskell will *not* verify that the implementation is correct. Furthermore, `assume` can be used to locally override the type of an imported function. + +- Derived Measure Selectors +Given a data definition + + {-@ data Foo = Foo { bar :: Int, baz :: Bool } @-} + +LiquidHaskell will automatically derive measures + + {-@ measure bar :: Foo -> Int @-} + {-@ measure baz :: Foo -> Bool @-} + +- Type-Class Specifications +LiquidHaskell can now verify prove that type-class instances satisfy a specification. Simply use the new `class` annotation + + {-@ class Num a where + (+) :: x:a -> y:a -> {v:a | v = x + y} + (-) :: x:a -> y:a -> {v:a | v = x - y} + ... + @-} + +and LiquidHaskell will attempt to prove at each instance declaration that the implementations satisfy the class specification. + +When defining type-class specifications you may find the need to use overloaded measures, to allow for type-specific definitions (see Type-Indexed Measures). + +- Type-Indexed Measures +LiquidHaskell now accepts measures with *type-specific* definitions, e.g. a measure to describe the size of a value. Such measures are defined using the `class measure` syntax + + {-@ class measure size :: forall a. a -> Int @-} + +and instances can be defined using the `instance measure` syntax, which mirrors the regular measure syntax + + {-@ instance measure size :: [a] -> Int + size ([]) = 0 + size (x:xs) = 1 + size xs + @-} + {-@ instance measure size :: Tree a -> Int + size (Leaf) = 0 + size (Node l x r) = 1 + size l + size r + @-} + +- Parsing +We have greatly improved our parser to require fewer parentheses! Yay! + +- Emacs/Vim Support +LiquidHaskell now comes with syntax checkers for [flycheck](https://github.com/flycheck/flycheck) in Emacs and [syntastic](https://github.com/scrooloose/syntastic) in Vim. + +- Incremental Checking +LiquidHaskell has a new `--diffcheck` flag that will only check binders that have changed since the last run, which can drastically improve verification times. + +- Experimental Support for Z3's theory of real numbers with the `--real` flag. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,4 @@ +Contributing +------------ + +Pull requests should be created against *develop* branch. diff --git a/FAILING_TESTS.txt b/FAILING_TESTS.txt new file mode 100644 --- /dev/null +++ b/FAILING_TESTS.txt @@ -0,0 +1,18 @@ + +Language/Haskell/HsColour/Anchors.hs: FAIL (683.88s) + Wrong exit code + expected: ExitSuccess + but got: ExitFailure 1 + +Language/Haskell/HsColour/ACSS.hs: FAIL (1.70s) + Wrong exit code + expected: ExitSuccess + but got: ExitFailure 2 + +FindRec.hs: FAIL (9.65s) + --eliminate crashes due to `cannot unify Tuple with FHandle error`. + A cons-gen bug tickled by --eliminate? + +CopyRec.hs: FAIL (42.90s) + --eliminate seems to blow up (lack of pattern-inline)? + diff --git a/HLint.hs b/HLint.hs new file mode 100644 --- /dev/null +++ b/HLint.hs @@ -0,0 +1,5 @@ +import "hint" HLint.Default +import "hint" HLint.Dollar + +ignore "Eta reduce" +ignore "Use ." diff --git a/INSTALL.md b/INSTALL.md new file mode 100644 --- /dev/null +++ b/INSTALL.md @@ -0,0 +1,77 @@ +# Install LiquidHaskell + +To run `liquid` you need to install: + +1. An SMT solver +2. The `liquid` binary via package manager *or* source. + + +## Step 1: Install SMT Solver + +Download and install *at least one* of + ++ [Z3](https://github.com/Z3Prover/z3/releases) ++ [CVC4](http://cvc4.cs.nyu.edu/) ++ [MathSat](http://mathsat.fbk.eu/download.html) + + +## Step 2: Install `liquid` via Package Manager + +Simply do: + + cabal install liquidhaskell + +We are working to put `liquid` on `stackage`. + +Note: Currently, LiquidHaskell on hackage does not compile against GHC 8. +Please make sure you are installing with GHC version less than 8. You can +designate a specific version of LiquidHaskell to ensure that the correct +GHC version is in the environment. As an example, + + cabal install liquidhaskell-0.6.0.0 + +## Step 2: Install `liquid` from Source + +If you want the most recent version, you can build from source as follows, +either using `stack` (recommended) or `cabal`. In either case: *recursively* +clone the repo and then build: + +### Build with `stack` (recommended) + +This requires that you have installed [stack][stack] (which we strongly recommend!) + + git clone --recursive git@github.com:ucsd-progsys/liquidhaskell.git + cd liquidhaskell + stack install + +## Build with `cabal` + + git clone --recursive git@github.com:ucsd-progsys/liquidhaskell.git + cd liquidhaskell + + cabal sandbox init + cabal sandbox add-source ./liquid-fixpoint + cabal sandbox add-source ./liquiddesugar + cabal install + +## Troubleshooting + + +1. If you're on Windows, please make sure the SMT solver is installed + in the **same** directory as LiquidHaskell itself (i.e. wherever + `cabal` or `stack` puts your binaries). That is, do: + + ``` + which liquid + ``` + + and make sure that `z3` or `cvc4` or `mathsat` are in the `PATH` + returned by the above. + +2. If you installed via `stack` and are experiencing path related woes, try: + + ``` + stack exec -- liquid path/to/file.hs + ``` + +[stack]: https://github.com/commercialhaskell/stack/blob/master/doc/install_and_upgrade.md diff --git a/Makefile b/Makefile new file mode 100644 --- /dev/null +++ b/Makefile @@ -0,0 +1,110 @@ +THREADS=1 +SMTSOLVER=z3 + +FASTOPTS=-O0 +DISTOPTS=-O2 +PROFOPTS=-O2 --enable-library-profiling --enable-executable-profiling +LIQUIDOPTS= + +CABAL=cabal +CABALI=$(CABAL) install +CABALP=$(CABAL) install --enable-library-profiling + +# to deal with cabal sandboxes using dist/dist-sandbox-xxxxxx/build/test/test +# TASTY=find dist -type f -name test | head -n1 +TASTY=./dist/build/test/test + +DEPS=--dependencies-only + +############################################################################## +############################################################################## +############################################################################## + +fast: + $(CABAL) install -fdevel $(FASTOPTS) + +first: + $(CABAL) install $(FASTOPTS) --only-dependencies --enable-tests --enable-benchmarks + +dist: + # $(CABAL) install $(DISTOPTS) + $(CABAL) configure -fdevel --enable-tests --disable-library-profiling -O2 + $(CABAL) build + +prof: + $(CABAL) install $(PROFOPTS) + +igotgoto: + $(CABAL) build $(OPTS) + cp dist/build/liquid/liquid ~/.cabal/bin/ + +clean: + cabal clean + +docs: + $(CABAL) hscolour + $(CABAL) haddock --hoogle + +deps: + $(CABALI) $(DEPS) + +pdeps: + $(CABALP) $(DEPS) + +all-test-py: + cd tests && ./regrtest.py -a -t $(THREADS) && cd ../ + +test-py: + cd tests && ./regrtest.py -t $(THREADS) && cd ../ + +test: + $(CABAL) configure -fdevel --enable-tests --disable-library-profiling -O2 + $(CABAL) build + $(CABAL) exec $(TASTY) -- --smtsolver $(SMTSOLVER) --hide-successes --rerun-update -p 'Unit/' -j$(THREADS) +RTS -N$(THREADS) -RTS + # $(CABAL) exec $(TASTY) -- --smtsolver $(SMTSOLVER) --liquid-opts='$(LIQUIDOPTS)' --hide-successes --rerun-update -p 'Unit/' -j$(THREADS) +RTS -N$(THREADS) -RTS + +test710: + $(CABAL) configure -fdevel --enable-tests --disable-library-profiling -O2 + $(CABAL) build + $(TASTY) --smtsolver $(SMTSOLVER) --hide-successes --rerun-update -p 'Unit/' -j$(THREADS) +RTS -N$(THREADS) -RTS + + +retest: + cabal configure -fdevel --enable-tests --disable-library-profiling -O2 + cabal build + cabal exec $(TASTY) -- --smtsolver $(SMTSOLVER) --hide-successes --rerun-filter "exceptions,failures,new" --rerun-update -p 'Unit/' -j$(THREADS) +RTS -N$(THREADS) -RTS + +all-test: + cabal configure -fdevel --enable-tests --disable-library-profiling -O2 + cabal build + cabal exec $(TASTY) -- --smtsolver $(SMTSOLVER) --hide-successes --rerun-update -j$(THREADS) +RTS -N$(THREADS) -RTS + +all-test-710: + cabal configure -fdevel --enable-tests --disable-library-profiling -O2 + cabal build + $(TASTY) --smtsolver $(SMTSOLVER) --hide-successes --rerun-update -j$(THREADS) +RTS -N$(THREADS) -RTS + + + +all-retest: + cabal configure -fdevel --enable-tests --disable-library-profiling -O2 + cabal build + cabal exec $(TASTY) -- --smtsolver $(SMTSOLVER) --hide-successes --rerun-filter "exceptions,failures,new" --rerun-update -j$(THREADS) +RTS -N$(THREADS) -RTS + +all-retest-710: + cabal configure -fdevel --enable-tests --disable-library-profiling -O2 + cabal build + $(TASTY) --smtsolver $(SMTSOLVER) --hide-successes --rerun-filter "exceptions,failures,new" --rerun-update -j$(THREADS) +RTS -N$(THREADS) -RTS + + + +lint: + hlint --colour --report . + +tags: + hasktags -x -c src/ + # hasktags -c src/ + # hasktags -e src/ + +ghcid: + ghcid --command "stack ghci --main-is liquidhaskell:exe:liquid" diff --git a/NVTODO.md b/NVTODO.md new file mode 100644 --- /dev/null +++ b/NVTODO.md @@ -0,0 +1,12 @@ +- Gradual Refinement Types + - [x] clean up code + - [x] compare numbers + - [x] pull request + - [ ] without elimination Interpratations.f has an bad/interesting result + - [ ] Implement Eric's validity with measures + - [x] Check how elimination interacts with graduals (eg Interpretation fails with elimination now) + - [ ] Find interesting application + - [ ] Present weakest result + + +- Proof by Symbolic Evaluation diff --git a/README.md b/README.md new file mode 100644 --- /dev/null +++ b/README.md @@ -0,0 +1,1250 @@ +![LiquidHaskell](/resources/logo.png) + + +[![Hackage](https://img.shields.io/hackage/v/liquidhaskell.svg)](https://hackage.haskell.org/package/liquidhaskell) [![Hackage-Deps](https://img.shields.io/hackage-deps/v/liquidhaskell.svg)](http://packdeps.haskellers.com/feed?needle=liquidhaskell) [![Build Status](https://img.shields.io/circleci/project/ucsd-progsys/liquidhaskell/master.svg)](https://circleci.com/gh/ucsd-progsys/liquidhaskell) + +Main Web site +------------- + +The UCSD web site for liquid haskell is [here](https://ucsd-progsys.github.io/liquidhaskell-blog/) + +Examples +-------- + +Jump to examples here [TODO] + + + +Contributing Guide +------------------ + +Please see the [contributing guide](CONTRIBUTING.md) + +Requirements +------------ + +LiquidHaskell requires (in addition to the cabal dependencies) + +- SMTLIB2 compatible solver + +How To Clone, Build and Install +------------------------------- + +See [install instructions](INSTALL.md) + +How To Run +---------- + +To verify a file called `foo.hs` at type + + $ liquid foo.hs + +How to Run inside GHCi +---------------------- + +To run inside `ghci` e.g. when developing do: + + $ stack ghci liquidhaskell + ghci> :m +Language.Haskell.Liquid.Liquid + ghci> liquid ["tests/pos/Abs.hs"] + +How To Run Regression Tests +--------------------------- + + $ stack test + +To use threads to speed up the tests + + $ make THREADS=30 test + +Or your favorite number of threads, depending on cores etc. + +You can directly extend and run the tests by modifying + + tests/test.hs + +To run the regression test *and* the benchmarks run + + $ make all-test + +How to Profile +-------------- + +1. Build with profiling on + + ``` + $ make pdeps && make prof + ``` + +2. Run with profiling + + ``` + $ time liquid range.hs +RTS -hc -p + $ time liquid range.hs +RTS -hy -p + ``` + + Followed by this which shows the stats file + + ``` + $ more liquid.prof + ``` + + or by this to see the graph + + ``` + $ hp2ps -e8in -c liquid.hp + $ gv liquid.ps + ``` + + etc. + +How to Get Stack Traces On Exceptions +------------------------------------- + +1. Build with profiling on + + ``` + $ make pdeps && make prof + ``` + +2. Run with backtraces + + ``` + $ liquid +RTS -xc -RTS foo.hs + ``` + +Working With Submodules +----------------------- + + - To update the `liquid-fixpoint` submodule, run + + ``` + cd ./liquid-fixpoint + git fetch --all + git checkout / + cd .. + ``` + + This will update `liquid-fixpoint` to the latest version on `` + (usually `master`) from `` (usually `origin`). + + - After updating `liquid-fixpoint`, make sure to include this change in a + commit! Running + + ``` + git add ./liquid-fixpoint + ``` + + will save the current commit hash of `liquid-fixpoint` in your next commit + to the `liquidhaskell` repository. + + - For the best experience, **don't** make changes directly to the + `./liquid-fixpoint` submodule, or else git may get confused. Do any + `liquid-fixpoint` development inside a separate clone/copy elsewhere. + + - If something goes wrong, run + + ``` + rm -r ./liquid-fixpoint + git submodule update --init + ``` + + to blow away your copy of the `liquid-fixpoint` submodule and revert to the + last saved commit hash. + + - Want to work fully offline? git lets you add a local directory as a remote. + Run + + ``` + cd ./liquid-fixpoint + git remote add local /path/to/your/fixpoint/clone + cd .. + ``` + + Then to update the submodule from your local clone, you can run + + ``` + cd ./liquid-fixpoint + git fetch local + git checkout local/ + cd .. + ``` + +Command Line Options +==================== + +LiquidHaskell supports several command line options, to configure the +checking. Each option can be passed in at the command line, or directly +added to the source file via: + + {-@ LIQUID "option-within-quotes" @-} + +for example, to disable termination checking (see below) + + {-@ LIQUID "--notermination" @-} + +You may also put command line options in the environment variable +`LIQUIDHASKELL_OPTS`. For example, if you add the line: + + LIQUIDHASKELL_OPTS="--diff" + +to your `.bashrc` then, by default, all files will be +*incrementally checked* unless you run with the overriding +`--full` flag (see below). + +Incremental Checking +-------------------- + +LiquidHaskell supports *incremental* checking where each run only checks +the part of the program that has been modified since the previous run. + + $ liquid --diff foo.hs + +Each run of `liquid` saves the file to a `.bak` file and the *subsequent* +run + + does a `diff` to see what has changed w.r.t. the `.bak` file + + only generates constraints for the `[CoreBind]` corresponding to the + changed top-level binders and their transitive dependencies. + +The time savings are quite significant. For example: + + $ time liquid --notermination -i . Data/ByteString.hs > log 2>&1 + + real 7m3.179s + user 4m18.628s + sys 0m21.549s + +Now if you go and tweak the definition of `spanEnd` on line 1192 and re-run: + + $ time liquid -d --notermination -i . Data/ByteString.hs > log 2>&1 + + real 0m11.584s + user 0m6.008s + sys 0m0.696s + +The diff is only performed against **code**, i.e. if you only change +specifications, qualifiers, measures, etc. `liquid -d` will not perform +any checks. In this case, you may specify individual definitions to verify: + + $ liquid -b bar -b baz foo.hs + +This will verify `bar` and `baz`, as well as any functions they use. + +If you always want to run a given file with diff-checking, add +the pragma: + + {-@ LIQUID "--diff" @-} + + +Full Checking (DEFAULT) +----------------------- + +To force LiquidHaskell to check the **whole** file (DEFAULT), use: + + $ liquid --full foo.hs + +to the file. This will override any other `--diff` incantation +elsewhere (e.g. inside the file.) + + +If you always want to run a given file with full-checking, add +the pragma: + + {-@ LIQUID "--full" @-} + +Specifying Different SMT Solvers +-------------------------------- + +By default, LiquidHaskell uses the SMTLIB2 interface for Z3. + +To run a different solver (supporting SMTLIB2) do: + + $ liquid --smtsolver=NAME foo.hs + +Currently, LiquidHaskell supports + ++ [CVC4](http://cvc4.cs.nyu.edu/) ++ [MathSat](http://mathsat.fbk.eu/download.html ) + +To use these solvers, you must install the corresponding binaries +from the above web-pages into your `PATH`. + +You can also build and link against the Z3 API (faster but requires more +dependencies). If you do so, you can use that interface with: + + $ liquid --smtsolver=z3mem foo.hs + + +Short Error Messages +-------------------- + +By default, subtyping error messages will contain the inferred type, the +expected type -- which is **not** a super-type, hence the error -- and a +context containing relevant variables and their type to help you understand +the error. If you don't want the above and instead, want only the +**source position** of the error use: + + --short-errors + +Short (Unqualified) Module Names +------------------------------- + +By default, the inferred types will have fully qualified module names. +To use unqualified names, much easier to read, use: + + --short-names + + +Totality Check +-------------- + +LiquidHaskell can prove the absence of pattern match failures. +Use the `totality` flag to prove that all defined functions are total. + + liquid --totality test.hs + +For example, the definition + + fromJust :: Maybe a -> a + fromJust (Just a) = a + +is not total and it will create an error message. +If we exclude `Nothing` from its domain, for example using the following specification + + {-@ fromJust :: {v:Maybe a | (isJust v)} -> a @-} + +`fromJust` will be safe. + +Termination Check +----------------- + +By **default** a termination check is performed on all recursive functions. + +Use the `no-termination` option to disable the check + + liquid --no-termination test.hs + +In recursive functions the *first* algebraic or integer argument should be decreasing. + +The default decreasing measure for lists is length and Integers its value. + +The user can specify the decreasing measure in data definitions: + + {-@ data L [llen] a = Nil | Cons (x::a) (xs:: L a) @-} + +Defines that `llen` is the decreasing measure (to be defined by the user). + +For example, in the function `foldl` + + foldl k acc N = acc + foldl k acc (Cons x xs) = foldl k (x `k` acc) xs + +by default the *second* argument (the first non-function argument) will be +checked to be decreasing. However, the explicit hint + + {-@ Decrease foo 3 @-} + +tells LiquidHaskell to instead use the *third* argument. + +Apart from specifying a specific decreasing measure for an Algebraic Data Type, +the user can specify that the ADT follows the expected decreasing measure by + + {-@ autosize L @-} + +Then, LiquidHaskell will define an instance of the function `autosize` for `L` that decreases by 1 at each recursive call and use `autosize` at functions that recurse on `L`. + +For example, `autosize L` will refine the data constructors of `L a` with the `autosize :: a -> Int` information, such that + + Nil :: {v:L a | autosize v = 0} + Cons :: x:a -> xs:L a -> {v:L a | autosize v = 1 + autosize xs} + +Also, an invariant that `autosize` is non negative will be generated + + invariant {v:L a| autosize v >= 0 } + +This information is all LiquidHaskell needs to prove termination on functions that recurse on `L a` (on ADTs in general.) + + +To *disable* termination checking for `foo` that is, to *assume* that it +is terminating (possibly for some complicated reason currently beyond the +scope of LiquidHaskell) you can write + + {-@ Lazy foo @-} + +Some functions do not decrease on a single argument, but rather a +combination of arguments, e.g. the Ackermann function. + + ack m n + | m == 0 = n + 1 + | m > 0 && n == 0 = ack (m-1) 1 + | m > 0 && n > 0 = ack (m-1) (ack m (n-1)) + +In all but one recursive call `m` decreases, in the final call `m` +does not decrease but `n` does. We can capture this notion of "x +normally decreases, but if it does not, y will" with an extended +annotation + + {-@ Decrease ack 1 2 @-} + +An alternative way to express this specification is by annotating +the function's type with the appropriate *numeric* decreasing expressions. +As an example, you can give `ack` a type + + {-@ ack :: m:Nat -> n:Nat -> Nat / [m,n] @-} + +stating that the *numeric* expressions `[m, n]` are lexicographically decreasing. + +Decreasing expressions can be arbitrary refinement expressions, e.g., + + {-@ merge :: Ord a => xs:[a] -> ys:[a] -> [a] / [(len xs) + (len ys)] @-} + +states that at each recursive call of `merge` the sum of the lengths +of its arguments will be decreased. + +When dealing with mutually recursive functions you may run into a +situation where the decreasing parameter must be measured *across* a +series of invocations, e.g. + + even 0 = True + even n = odd (n-1) + + odd n = not $ even n + +In this case, you can introduce a ghost parameter that orders the *functions* + + even 0 _ = True + even n _ = odd (n-1) 1 + + odd n _ = not $ even n 0 + +thus recovering a decreasing measure for the pair of functions, the +pair of arguments. This can be encoded with the lexicographic +termination annotation `{-@ Decrease even 1 2 @-}` (see +[tests/pos/mutrec.hs](tests/pos/mutrec.hs) for the full example). + + + +Total Haskell +-------------- + +LiquidHaskell provides a total Haskell flag that checks both totallity and termination of the program, +overriding a potential no-termination flag. + + liquid --total-Haskell test.hs + + +Lazy Variables +-------------- + +A variable can be specified as `LAZYVAR` + + {-@ LAZYVAR z @-} + +With this annotation the definition of `z` will be checked at the points where +it is used. For example, with the above annotation the following code is SAFE: + + foo = if x > 0 then z else x + where + z = 42 `safeDiv` x + x = choose 0 + +By default, all the variables starting with `fail` are marked as LAZY, to defer +failing checks at the point where these variables are used. + +No measure fields +------------------ + +When a data type is refined, Liquid Haskell automatically turns the data constructor fields into measures. +For example, + + {-@ data L a = N | C {hd :: a, tl :: L a} @-} + +will automatically create two measures `hd` and `td`. +To deactivate this automatic measure definition, and speed up verification, you can use the `no-measure-fields` flag. + + liquid --no-measure-fields test.hs + + + +Prune Unsorted Predicates +------------------------- + +Consider a measure over lists of integers + + sum :: [Int] -> Int + sum [] = 0 + sum (x:xs) = 1 + sum xs + +This measure will translate into strengthening the types of list constructors + + [] :: {v:[Int] | sum v = 0 } + (:) :: x:Int -> xs:[Int] -> {v:[Int] | sum v = x + sum xs} + +But what if our list is polymorphic `[a]` and later instantiate to list of ints? +The hack we do right now is to strengthen the polymorphic list with the `sum` information + + [] :: {v:[a] | sum v = 0 } + (:) :: x:a -> xs:[a] -> {v:[a] | sum v = x + sum xs} + +But for non numeric `a`s, expressions like `x + sum xs` is unsorted causing the logic to crash. +We use the flag `--prune-unsorted` to prune away unsorted expressions (like `x + sum xs`) in the logic. + + + liquid --prune-unsorted test.hs + + +Case Expansion +------------------------- + +By default LiquidHaskell expands all data constructors to the case statements. +For example, +if `F = A1 | A2 | .. | A10`, +then LiquidHaskell will expand the code +`case f of {A1 -> True; _ -> False}` +to `case f of {A1 -> True; A2 -> False; ...; A10 -> False}`. +This expansion can lead to more precise code analysis +but it can get really expensive due to code explosion. +The `no-case-expand` flag prevents this expansion and keeps the user +provided cases for the case expression. + + liquid --no-case-expand test.hs + + +Higher order logic +------------------- +The flag `--higherorder` allows reasoning about higher order functions. + + +Restriction to Linear Arithmetic +--------------------------------- +When using `z3` as the solver, LiquidHaskell allows for non-linear arithmetic: +division and multiplication on integers are interpreted by `z3`. To treat division +and multiplication as uninterpreted functions use the `linear` flag + + liquid --linear test.hs + +Counter examples (Experimental!) +-------------------------------- +When given the `--counter-examples` flag, LiquidHaskell will attempt to produce +counter-examples for the type errors it discovers. For example, see +[tests/neg/ListElem.hs](https://github.com/ucsd-progsys/liquidhaskell/blob/master/tests/neg/ListElem.hs) + +``` +% liquid --counter-examples tests/neg/ListElem.hs + +... + +tests/neg/ListElem.hs:12:1-8: Error: Liquid Type Mismatch + + 12 | listElem _ [] = False + ^^^^^^^^ + + Inferred type + VV : {VV : Bool | VV == True} + VV = True + + not a subtype of Required type + VV : {VV : Bool | Prop VV <=> Set_mem ?b (listElts ?a)} + + In Context + ?a : {?a : [a] | len ?a >= 0} + ?a = [1] + + ?b : a + ?b = 0 +``` + +The `--counter-examples` flag requires that each type in the context be +an instance of `GHC.Generics.Generic` or `Test.Targetable.Targetable` +(provided as part of LiquidHaskell). LiquidHaskell cannot generate +counter-examples for polymorphic types, but will try (naively) to +instantiate type variables with `Int` (as seen in the example above). + +Writing Specifications +====================== + +Modules WITHOUT code +-------------------- + +When checking a file `target.hs`, you can specify an _include_ directory by + + liquid -i /path/to/include/ target.hs + +Now, to write specifications for some **external module** `Foo.Bar.Baz` for which +you **do not have the code**, you can create a `.spec` file at: + + /path/to/include/Foo/Bar/Baz.spec + +See, for example, the contents of + ++ [include/Prelude.spec](https://github.com/ucsd-progsys/liquidhaskell/blob/master/include/Prelude.spec) ++ [include/Data/List.spec](https://github.com/ucsd-progsys/liquidhaskell/blob/master/include/Data/List.spec) ++ [include/Data/Vector.spec](https://github.com/ucsd-progsys/liquidhaskell/blob/master/include/Data/Vector.spec) + +**Note**: + ++ The above directories are part of the LH prelude, and included by + default when running `liquid`. ++ The `.spec` mechanism is *only for external modules** without code, + see below for standalone specifications for **internal** or **home** modules. + + +Modules WITH code: Data +----------------------- + +Write the specification directly into the .hs or .lhs file, +above the data definition. See, for example, [tests/pos/Map.hs](tests/pos/Map.hs) + + {-@ + data Map k a k -> Prop, r :: k -> k -> Prop> + = Tip + | Bin (sz :: Size) + (key :: k) + (value :: a) + (left :: Map (k ) a) + (right :: Map (k ) a) + @-} + data Map k a = Tip + | Bin Size k a (Map k a) (Map k a) + +You can also write invariants for data type definitions +together with the types. For example, see [tests/pos/record0.hs](tests/pos/record0.hs) + + {-@ data LL a = BXYZ { size :: {v: Int | v > 0 } + , elems :: {v: [a] | (len v) = size } + } + @-} + +Finally you can specify the variance of type variables for data types. +For example, see [tests/pos/Variance.hs](tests/pos/Variance.hs), where data type `Foo` has four +type variables `a`, `b`, `c`, `d`, specified as invariant, bivariant, +covariant and contravariant, respectively. + + data Foo a b c d + {-@ data variance Foo invariant bivariant covariant contravariant @-} + + +Modules WITH code: Functions +---------------------------- + +Write the specification directly into the .hs or .lhs file, +above the function definition. [For example](tests/pos/spec0.hs) + + {-@ incr :: x:{v: Int | v > 0} -> {v: Int | v > x} @-} + incr :: Int -> Int + incr x = x + 1 + +Modules WITH code: Type Classes +------------------------------- + +Write the specification directly into the .hs or .lhs file, +above the type class definition. [For example](tests/pos/Class.hs) + + {-@ class Sized s where + size :: forall a. x:s a -> {v:Int | v = (size x)} + @-} + class Sized s where + size :: s a -> Int + +Any measures used in the refined class definition will need to be +*generic* (see [Specifying Measures](#specifying-measures)). + + +As an alternative, you can refine class instances. +[For example](tests/pos/LiquidClass.hs) + +~~~~ +instance Compare Int where + +{-@ instance Compare Int where + cmax :: Odd -> Odd -> Odd + @-} + +cmax y x = if x >= y then x else y +~~~~ + +When `cmax` method is used on `Int`, liquidHaskell will give it +the refined type `Odd -> Odd -> Odd`. + +Note that currently liquidHaskell does not allow refining instances of +refined classes. + +Modules WITH code: QuasiQuotation +--------------------------------- + +Instead of writing both a Haskell type signature *and* a +LiquidHaskell specification for a function, the `lq` +quasiquoter in the `LiquidHaskell` module can be used +to generate both from just the LiquidHaskell specification. + +```haskell +module Nats (nats) where + +{-@ nats :: [{v:Int | 0 <= v}] @-} +nats :: [Int] +nats = [1,2,3] +``` + +can be written as + +```haskell +{-# LANGUAGE QuasiQuotes #-} +module Nats (nats) where + +import LiquidHaskell + +[lq| nats :: [{v:Int | 0 <= v}] |] +nats = [1,2,3] +``` + +and the `lq` quasiquoter will generate the plain `nats :: [Int]` when GHC +compiles the module. + +Refined type aliases (see the next section) can also be written inside `lq`; for +example: + +```haskell +{-# LANGUAGE QuasiQuoters #-} +module Nats (Nat, nats) where + +[lq| type Nat = {v:Int | 0 <= v} |] + +[lq| nats :: [Nat] |] +nats = [1,2,3] +``` + +Here, the `lq` quasiquoter will generate a plain Haskell +type synonym for `Nat` as well as the refined one. + +Note that this is still an experimental feature, and +currently requires that one depend on LiquidHaskell +as a build dependency for your project; the quasiquoter +will be split out eventually into an independent, +dependency-light package. Also, at this time, writing +a type inside `lq` which refers to a refined type alias +for which there is not a plain Haskell type synonym of the +same name will result in a "not in scope" error from GHC. + +Standalone Specifications for Internal Modules +---------------------------------------------- + +Recall that the `.spec` mechanism is only for modules whose +code is absent; if code is present then there can be multiple, +possibly conflicting specifications. Nevertheless, you may want, +for one reason or another, to write (assumed) specifications +outside the file implementing the module. + +You can do this as follows. + +`Lib.hs` + +```haskell +module Lib (foo) where + +foo a = a +``` + +now, instead of a `.spec` file, just use a haskell module, e.g. `LibSpec.hs` + +```haskell +module LibSpec ( module Lib ) where + +import Lib + +-- Don't forget to qualify the name! + +{-@ Lib.foo :: {v:a | false} -> a @-} +``` + +and then here's `Client.hs` + +```haskell +module Client where + +import Lib -- use this if you DON'T want the spec +import LibSpec -- use this if you DO want the spec, in addition to OR instead of the previous import. + +bar = foo 1 -- if you `import LibSpec` then this call is rejected by LH +``` +Refinement Type Aliases +----------------------- + +#### Predicate Aliases + +Often, the propositions in the refinements can get rather long and +verbose. You can write predicate aliases like so: + + {-@ predicate Lt X Y = X < Y @-} + {-@ predicate Ge X Y = not (Lt X Y) @-} + +and then use the aliases inside refinements, [for example](tests/pos/pred.hs) + + {-@ incr :: x:{v:Int | (Pos v)} -> { v:Int | ((Pos v) && (Ge v x))} @-} + incr :: Int -> Int + incr x = x + 1 + +See [Data.Map](benchmarks/esop2013-submission/Base.hs) for a more substantial +and compelling example. + +**Syntax:** The key requirements for type aliases are: + +- Value parameters are specified in **upper**case: `X`, `Y`, `Z` etc. + + +#### Type Aliases + + +Similarly, it is often quite tedious to keep writing + + {v: Int | v > 0} + +Thus, LiquidHaskell supports refinement-type aliases of the form: + + {-@ type Gt N = {v: Int | N < v} @-} + {-@ type GeNum a N = {v: a | N <= v} @-} + +or + + {-@ type SortedList a = [a]<{\fld v -> (v >= fld)}> @-} + +or + + {-@ type OMap k a = Map <{\root v -> v < root}, {\root v -> v > root}> k a @-} + +or + + {-@ type MinSPair a = (a, OSplay a) <\fld -> {v : Splay {v:a|v>fld} | 0=0}> @-} + +and then use the above in signatures like: + + {-@ incr: x: Int -> GeNum Int x @-} + +or + + {-@ incr: x: Int -> Gt x @-} + +and: + + {-@ assert insert :: (Ord a) => a -> SortedList a -> SortedList a @-} + +see [tests/pos/ListSort.hs](tests/pos/ListSort.hs) + +and: + + {-@ assert insert :: (Ord k) => k -> a -> OMap k a -> OMap k a @-} + +see [tests/pos/Map.hs](tests/pos/Map.hs) + +**Syntax:** The key requirements for type aliases are: + +1. Type parameters are specified in **lower**case: `a`, `b`, `c` etc. +2. Value parameters are specified in **upper**case: `X`, `Y`, `Z` etc. + + +Infix Logic Operators +--------------------- + +You can define infix operators in logic, following [Haskell's infix notation](Build in Haskell ops https://www.haskell.org/onlinereport/decls.html#fixity). +For example, if (+++) is defined as a measure or reflected function, you can use it infix by declaring + + {-@ infixl 9 +++ @-} + + +Note: infix operators cannot contain the dot character `.`. + + +Specifying Measures +------------------- + +Can be placed in .spec file or in .hs/.lhs file wrapped around `{-@ @-}` + +Value measures: [include/GHC/Base.spec](include/GHC/Base.spec) + + measure len :: forall a. [a] -> GHC.Types.Int + len ([]) = 0 + len (y:ys) = 1 + len(ys) + +Propositional measures: [tests/pos/LambdaEval.hs](tests/pos/LambdaEval.hs) + + {-@ + measure isValue :: Expr -> Bool + isValue (Const i) = true + isValue (Lam x e) = true + isValue (Var x) = false + isValue (App e1 e2) = false + isValue (Plus e1 e2) = false + isValue (Fst e) = false + isValue (Snd e) = false + isValue (Pair e1 e2) = ((? (isValue(e1))) && (? (isValue(e2)))) + @-} + +Raw measures: [tests/pos/meas8.hs](tests/pos/meas8.hs) + + {-@ measure rlen :: [a] -> Int + rlen ([]) = {v | v = 0} + rlen (y:ys) = {v | v = (1 + rlen(ys))} + @-} + +Generic measures: [tests/pos/Class.hs](tests/pos/Class.hs) + + {-@ class measure size :: a -> Int @-} + {-@ instance measure size :: [a] -> Int + size ([]) = 0 + size (x:xs) = 1 + (size xs) + @-} + {-@ instance measure size :: Tree a -> Int + size (Leaf) = 0 + size (Node x l r) = 1 + (size l) + (size r) + @-} + +**Note:** Measure names **do not** have to be the same as +field name, e.g. we could call the measure `sz` in the above +as shown in [tests/pos/Class2.hs](tests/pos/Class2.hs). + + +Haskell Functions as Measures (beta): [tests/pos/HaskellMeasure.hs](tests/pos/HaskellMeasure.hs) + +Inductive Haskell Functions from Data Types to some type can be lifted to logic + + {-@ measure llen @-} + llen :: [a] -> Int + llen [] = 0 + llen (x:xs) = 1 + llen xs + +The above definition + - refines list's data constructors types with the llen information, and + - specifies a singleton type for the haskell function + `llen :: xs:[a] -> {v:Int | v == llen xs}` + If the user specifies another type for llen, say + `llen :: xs:[a] -> {v:Int | llen xs >= 0}` + then the auto generated singleton type is overwritten. + +Self-Invariants +=============== + +Sometimes, we require specifications that allow *inner* components of a +type to refer to the *outer* components, typically, to measure-based +properties of outer components. For example, the following invariant +about `Maybe` values + + {-@ type IMaybe a = {v0 : Maybe {v : a | ((isJust v0) && v = (fromJust v0))} | 0 = 0 } @-} + +states that the *inner* `a` enjoys the property that the *outer* container +is definitely a `Just` and furthermore, the inner value is exactly the same +as the `fromJust` property of the outer container. + +As another example, suppose we have a [measure](include/Data/Set.spec): + + measure listElts :: [a] -> (Set a) + listElts([]) = {v | (? Set_emp(v))} + listElts(x:xs) = {v | v = Set_cup(Set_sng(x), listElts(xs)) } + +Now, all lists enjoy the property + + {-@ type IList a = {v0 : List {v : a | (Set_mem v (listElts v0)) } | true } @-} + +which simply states that each *inner* element is indeed, a member of the +set of the elements belonging to the entire list. + +One often needs these *circular* or *self* invariants to connect different +levels (or rather, to *reify* the connections between the two levels.) See +[this test](tests/pos/maybe4.hs) for a simple example and `hedgeUnion` and +[Data.Map.Base](benchmarks/esop2013-submission/Base.hs) for a complex one. + +Abstract and Bounded Refinements +================================ + +This is probably the best example of the abstract refinement syntax: + ++ [Abstract Refinements](tests/pos/Map.hs) ++ [Bounded Refinements](benchmarks/icfp15/pos/Overview.lhs) + +Unfortunately, the best documentation for these two advanced features +is the relevant papers at + ++ [ESOP 2013](https://ranjitjhala.github.io/static/abstract_refinement_types.pdf) ++ [ICFP 2015](https://arxiv.org/abs/1507.00385) + +The bounds correspond to Horn implications between abstract refinements, +which, as in the classical setting, correspond to subtyping constraints +that must be satisfied by the concrete refinements used at any call-site. + +Invariants +========== + +LH lets you locally associate invariants with specific data types. + +For example, in [tests/pos/StreamInvariants.hs](tests/pos/StreamInvariants.hs) every +list is treated as a Stream. To establish this local invariant one can use the +`using` declaration + + {-@ using ([a]) as {v:[a] | (len v > 0)} @-} + +denoting that each list is not empty. + +Then, LiquidHaskell will prove that this invariant holds, by proving that *all +calls* to List's constructors (ie., `:` and `[]`) satisfy it, and +will assume that each list element that is created satisfies +this invariant. + +With this, at the [above](tests/neg/StreamInvariants.hs) test LiquidHaskell +proves that taking the `head` of a list is safe. +But, at [tests/neg/StreamInvariants.hs](tests/neg/StreamInvariants.hs) the usage of +`[]` falsifies this local invariant resulting in an "Invariant Check" error. + + +**WARNING:** There is an older _global_ invariant mechanism that +attaches a refinement to a datatype globally. +Do not use this mechanism -- it is *unsound* and about to +deprecated in favor of something that is [actually sound](https://github.com/ucsd-progsys/liquidhaskell/issues/126) + +Forexample, the length of a list cannot be negative + + {-@ invariant {v:[a] | (len v >= 0)} @-} + +LiquidHaskell can prove that this invariant holds, by proving that all List's +constructors (ie., `:` and `[]`) satisfy it.(TODO!) Then, LiquidHaskell +assumes that each list element that is created satisfies +this invariant. + +Formal Grammar of Refinement Predicates +======================================= + +(C)onstants +----------- + + c := 0, 1, 2, ... + +(V)ariables +----------- + + v := x, y, z, ... + + +(E)xpressions +------------- + + e := v -- variable + | c -- constant + | (e + e) -- addition + | (e - e) -- subtraction + | (c * e) -- multiplication by constant + | (v e1 e2 ... en) -- uninterpreted function application + | (if p then e else e) -- if-then-else + +(R)elations +----------- + + r := == -- equality + | /= -- disequality + | >= -- greater than or equal + | <= -- less than or equal + | > -- greater than + | < -- less than + + +(P)redicates +------------ + + p := (e r e) -- binary relation + | (v e1 e2 ... en) -- predicate (or alias) application + | (p && p) -- and + | (p || p) -- or + | (p => p) -- implies + | (not p) -- negation + | true + | false + + +Specifying Qualifiers +===================== + +There are several ways to specify qualifiers. + +By Separate `.hquals` Files +--------------------------- + +You can write qualifier files e.g. [Prelude.hquals](include/Prelude.hquals) + +If a module is called or imports + + Foo.Bar.Baz + +Then the system automatically searches for + + include/Foo/Bar/Baz.hquals + +By Including `.hquals` Files +---------------------------- + +Additional qualifiers may be used by adding lines of the form: + + {-@ include @-} + +to the Haskell source. See, [this](tests/pos/meas5.hs) for example. + + +In Haskell Source or Spec Files +------------------------------- + +Finally, you can specifiers directly inside source (.hs or .lhs) or spec (.spec) +files by writing as shown [here](tests/pos/qualTest.hs) + + {-@ qualif Foo(v:Int, a: Int) : (v = a + 100) @-} + + +**Note** In addition to these, LiquidHaskell scrapes qualifiers from all +the specifications you write i.e. + +1. all imported type signatures, +2. measure bodies and, +3. data constructor definitions. + + +Generating HTML Output +====================== + +The system produces HTML files with colorized source, and mouseover +inferred type annotations, which are quite handy for debugging failed +verification attempts. + +- **Regular Haskell** When you run: `liquid foo.hs` you get a file + `foo.hs.html` with the annotations. The coloring is done using + `hscolour`. + +- **Markdown + Literate Haskell** You can also feed in literate haskell files + where the comments are in [Pandoc markdown](http://johnmacfarlane.net/pandoc/demo/example9/pandocs-markdown.html). + In this case, the tool will run `pandoc` to generate the HTML from the comments. + Of course, this requires that you have `pandoc` installed as a binary on + your system. If not, `hscolour` is used to render the HTML. + + It is also possible to generate *slide shows* from the above. + See the [slides directory](docs/slides) for an example. + +Editor Integration +================== + ++ [Emacs/Flycheck](https://github.com/ucsd-progsys/liquid-types.el) ++ [Vim/Syntastic](https://github.com/ucsd-progsys/liquid-types.vim) + +Command Line Options +==================== + +To see all options, run `liquid --help`. Here are some common options: + +- `--cabaldir` will automatically find a .cabal file in the ancestor + path from which the target file belongs, and then add the relevant + source and dependencies to the paths searched for by LiquidHaskell. + + This means we don't have to manually do `-i src` etc. when checking + large projects, which can be tedious e.g. within emacs. + +- `--diff` performs differential checking, i.e. only checks those binders + that have transitively affected by edits since the previous check. + Can speed things up greatly during editing. + +- `--short-names` prints out non-qualified names i.e. `Int` instead of + `GHC.Types.Int` for inferred type annotations and error messages. + +**Pragmas** are useful for embedding options directly within the source file, +that is, somewhere in the file (perhaps at the top) put in: + + {-@ LIQUID "--diff" @-} + {-@ LIQUID "--short-names" @-} + {-@ LIQUID "--cabaldir" @-} + +to have the relevant option be used for that file. + +Generating Performance Reports +------------------------------ + +We have set up infrastructure to generate performance reports using [Gipeda](https://github.com/nomeata/gipeda). + +Gipeda will generate a static webpage that tracks the performance improvements +and regressions between commits. To generate the site, first ensure you have the +following dependencies available: + +* Git +* Cabal >= 1.18 +* GHC +* Make +* Bash (installed at `/bin/bash`) + +After ensuring all dependencies are available, from the Liquid Haskell +directory, execute: + + cd scripts/performance + ./deploy-gipeda.bash + +This will download and install all the relevant repositories and files. Next, to +generate the performance report, use the `generate-site.bash` script. This script +has a few options: + +* `-s [hash]`: Do not attempt to generate performance reports for any commit +older than the commit specified by the entered git hash +* `-e [hash]`: Do not attempt to generate performance reports for any commit +newer than the commit specified by the entered git hash +* `-f`: The default behavior of `generate-site.bash` is to first check if logs +have been created for a given hash. If logs already exist, `generate-site.bash` +will not recreate them. Specify this option to skip this check and regenerate +all logs. + +You should expect this process to take a very long time. `generate-site.bash` +will compile each commit, then run the entire test suite and benchmark suite +for each commit. It is suggested to provide a manageable range to `generate-site.bash`: + + ./generate-site.bash -s [starting hash] -e [ending hash] + +...will generate reports for all commits between (inclusive) [starting hash] +and [ending hash]. + + ./generate-site.bash -s [starting hash] + +... will generate reports for all commits newer than [starting hash]. This command +can be the basis for some automated report generation process (i.e. a cron job). + +Finally, to remove the Gipeda infrastructure from your computer, you may execute: + + ./cleanup-gipeda.bash + +...which will remove any files created by `deploy-gipeda.bash` and `generate-site.bash` +from your computer. + + +Configuration Management +------------------------ + +It is very important that the version of Liquid Haskell be maintained properly. + +Suppose that the current version of Liquid Haskell is `A.B.C.D`: + ++ After a release to hackage is made, if any of the components `B`, `C`, or `D` are missing, they shall be added and set to `0`. Then the `D` component of Liquid Haskell shall be incremented by `1`. The version of Liquid Haskell is now `A.B.C.(D + 1)` + ++ The first time a new function or type is exported from Liquid Haskell, if any of the components `B`, or `C` are missing, they shall be added and set to `0`. Then the `C` component shall be incremented by `1`, and the `D` component shall stripped. The version of Liquid Haskell is now `A.B.(C + 1)` + ++ The first time the signature of an exported function or type is changed, or an exported function or type is removed (this includes functions or types that Liquid Haskell re-exports from its own dependencies), if the `B` component is missing, it shall be added and set to `0`. Then the `B` component shall be incremented by `1`, and the `C` and `D` components shall be stripped. The version of Liquid Haskell is now `A.(B + 1)` + ++ The `A` component shall be updated at the sole discretion of the project owners. + +Proof Automation +---------------- +The `liquidinstances` automatically generates proof terms using symbolic evaluation. [See](https://github.com/ucsd-progsys/liquidhaskell/blob/develop/benchmarks/proofautomation/pos/MonoidList.hs). + +``` +{-@ LIQUID "--automatic-instances=liquidinstances" @-} +``` + +This flag is **global** and will symbolically evaluation all the terms that appear in the specifications. + +As an alternative, the `liquidinstanceslocal` flag has local behavior. [See](https://github.com/ucsd-progsys/liquidhaskell/blob/develop/benchmarks/proofautomation/pos/Unification.hs) + +``` +{-@ LIQUID "--automatic-instances=liquidinstanceslocal" @-} +``` + +will only evaluate terms appearing in the specifications of the function `theorem`, in the function `theorem` is annotated +for automatic instantiation using the following liquid annotation + +``` +{-@ automatic-instances theorem @-} +``` diff --git a/Setup.hs b/Setup.hs --- a/Setup.hs +++ b/Setup.hs @@ -1,9 +1,11 @@ import Distribution.Simple + main = defaultMain --- main = defaultMainWithHooks fixpointHooks +-- +-- --- main = defaultMainWithHooks fixpointHooks -- -- fixpointHooks = defaultUserHooks { postInst = cpFix } -- where diff --git a/Syntax.md b/Syntax.md new file mode 100644 --- /dev/null +++ b/Syntax.md @@ -0,0 +1,40 @@ +- Niki Vazou + +| | Current Syntax | Future Syntax | +|----------------------|-------------------------------|-------------------------------| +| Abstract Refinements | `List <{\x v -> v >= x}> Int` | `List Int (\x v -> v >= x)` | +| | `[a

]<{\x v -> v >= x}>` | `[a p] (\x v -> v >= x) (??)` | +| | `Int

` | `Int p` | +| | `Int<\x -> x >=0>` | `Int (\x -> x >= 0)` | +| | `Maybe <

> (a) (?)` | `Maybe (a q) p` | +| | `Map <

> k v (?)` | `Maybe k v l r p` | +| Type Arguments | `ListN a {len xs + len ys}` | `ListN a (len xs + len ys)` | + +Q: How do I distinguish `Int p` with `ListN a n`? +(`p` is a abstract refinement and `n` is an `Integer`) + +A: From the context! +Use simple kinds, i.e. +`ListN :: * -> Int -> *` +`Int :: ?AR -> *` + +---------------------------- + +- Chris Tetreault + +Currently for specifications, we write them as such: + +`{-@ unsafeLookup :: n:Nat -> {v:Vector a | n < (vlen v)} -> a @-}` + +... where we bind `n` as a `Nat` and `v` as a `Vector a` _such that_ `[stuff]`. As a Haskeller, I find it strange to put logic into something that appears to be a function signature. I propose: + +``` +{-@ + unsafeLookup :: Nat -> Vector a -> a + unsafeLookup n v _ | n < vlen v +@-} +``` + +Here we have a "function" that takes a refined type `Nat` and a Haskell type `Vector a` and returns a Haskell type `a`. The definition of this refinement binds the `Nat` to `n` and the `Vector a` to `v`, and doesn't care about the `a`. Next, it specifies that `n < vlen v`. + +We could mix the syntax up a bit more to address my previous concern that it not look "too much like haskell", presuably drawing from the list of symbols that get used elsewhere, but I'm more concerned with getting this sort of "function syntax" than with what specific glyphs get used. diff --git a/TODO.EASY.md b/TODO.EASY.md new file mode 100644 --- /dev/null +++ b/TODO.EASY.md @@ -0,0 +1,22 @@ +- Verification of Libraries + - [zlib](https://hackage.haskell.org/package/zlib) + - [probability](https://github.com/nikivazou/probability) + +- fix parser error message + - Parse Errors [#241](https://github.com/ucsd-progsys/liquidhaskell/issues/241) + - Liquid Haskell doesn't accept Haskell names containing ' (single-quote) [#273](https://github.com/ucsd-progsys/liquidhaskell/issues/273) + - Error messages [#400](https://github.com/ucsd-progsys/liquidhaskell/issues/400) + - Add list of reserved tokens + +- Parse Propositional Variables in Refinements [#338](https://github.com/ucsd-progsys/liquidhaskell/issues/338) + +- Combine GHC and Liquid Type Aliases [#381](https://github.com/ucsd-progsys/liquidhaskell/issues/381) + +- Applying data type with wrong number of abstract refinement params could give better errors [#297](https://github.com/ucsd-progsys/liquidhaskell/issues/297) + +- Export qualifiers from measure types [#302](https://github.com/ucsd-progsys/liquidhaskell/issues/302) + +- systematically remove all error calls + + NV: Not sure how easy this is, as it requires deep understanding of the code + to distinguish dead code from our errors. diff --git a/TODO.markdown b/TODO.markdown new file mode 100644 --- /dev/null +++ b/TODO.markdown @@ -0,0 +1,1216 @@ +- Reader + - Applicative crashing + - Functor crashing + - Functor.NoEx + - Monad (...) + +TODO +==== + +Prune Unsorted Refs +------------------- + +* mergeDataConTypes +* makeMeasureSpec' +* meetDataConSpec + +The below gives a nice SORT error + +```haskell +import Data.Set + +data RBTree a = Leaf | Node + +{-@ measure isB :: RBTree a -> (Set a) + isB (Leaf) = 1 + isB (Node) = (Set_empty 0) + @-} +``` + +rjhala@borscht ~/r/s/liquidhaskell (prune-unsorted-error)> stack exec -- liquid tests/todo/prune.hs + + /Users/rjhala/research/stack/liquidhaskell/tests/todo/prune.hs:7:13-15: Error: Bad Type Specification + measure isB :: (RBTree a b) -> (Set a) + Type constructor Prune.RBTree expects a maximum 1 arguments but was given 2 arguments + + /Users/rjhala/research/stack/liquidhaskell/tests/todo/prune.hs:14:13: Error: Bad Measure Specification + measure isB + The sort (Set_Set @(42)) is not numeric + because + Cannot unify (Set_Set @(42)) with int in expression: 1 + because + Cannot cast 1 of sort int to incompatible sort func(1, [(Set_Set @(0))]) + +now put another SORT CHECK for measures: + + * Input type should be "isGeneric" + + isGeneric T if + + * T is a TyConApp `c [t1...tn]` + + where t1 .. tn are DISTINCT type variables. + +If the above SORT CHECK fails for any measure print an ERROR message saying: + + please rerun with --prune-unsorted + +```haskell + +(:) :: Int -> [Int] -> [Int] + +sum :: [Int] -> Int +sum [] = 0 +sum (x:xs) = x + sum xs + + +sum :: Tree Int a -> Int +sum Leaf = 0 +sum Node k _ l r = k + sum l + sum r +``` + +Check Covariance +---------------- + +See https://github.com/ucsd-progsys/liquidhaskell/blob/master/tests/todo/kmpMonad.hs#L55 +It is safe is 100 is changed to 0. WHY? + +LAZYVAR +------- + +Restore LAZYVARS in `Data/Text.hs`, `Data/Text/Unsafe.hs` + + +Automatically refine *inductors* +-------------------------------- + +Proposed by Valentine: in dependent languages (Coq) +inductors (like our `loop` for natural numbers) +automatically get types abstracted over properties. +Traversal should create such functions. +Maybe we can automatically refine them. + +benchmarks +----------- + +* benchmarks: Data.Bytestring + ? readsPrec + ? big constants issue : _word64 34534523452134213524525 due to (deriving Typeable) + - see others below + +* hmatrix + +* error messages (see issues on github) + +Benchmarks +========== + + time(O|N|C) TOTAL(O|N) solve (O|N) refines iterfreq + Map.hs : 54/50/32/10 21/15/8.7 14/8/4.3 9100/4900/2700 16/28/7 + ListSort.hs : */7.5/5.5/2 */2.5/1.8 */1.5/1.0 */1100/600 */9/7 + GhcListSort.hs : 23/22/17/5 7.3/7.8/5 4.5/5.0/2.7 3700/4400/1900 10/23/6 + LambdaEval.hs : 36/32/25/12 17/12/10 11.7/6.0/5 8500/3100/2400 12/5/5 + Base.hs : 26mi/2m + + +Benchmarks +========== + +[OK] Data.KMeans +[OK] GHC.List (../benchmarks/ghc-7.4.1/List.lhs) +[OK] bytestring +[OK] text + +[??-PP] Data.Map (supersedes set) + - ordering [OK] + - size + - key-set-properties + - key-dependence + - balance (NO) + +- vector-algorithms "vector bounds checking" + - e.g. "unsafeSlice" + - maybe only specify types for Vector? + +- vector +- repa +- repa-algorithms +- xmonad (stackset) +- snap/security +- hmatrix + > http://hackage.haskell.org/packages/archive/hmatrix/0.12.0.1/doc/html/src/Data-Packed-Internal-Matrix.html#Matrix + > http://hackage.haskell.org/packages/archive/hmatrix/0.12.0.1/doc/html/src/Data-Packed-Internal-Vector.html#fromList + +Other Benchmarks +================ + +-> FingerTrees (containers / Data.Seq) +-> Union-Find (PLDI09 port if necessary?) +-> BDD (PLDI09 port if necessary?) + +[NO] Data.Set (Map redux) + > ordering + > size + > set-properties + > balance (NO) + +[NO] Data.IntSet + > tricky bit-level operations/invariants + +Paper #2 + +-> Haskell + DB / Yesod / Snap +-> NDM/catch benchmarks (with refinements) + +Known Bugs +========== + +-> tests/todo/fft.hs + +-> binsearch crashes because you have chains like: + + x1 = 2 + x2 = x1 + x3 = x2 + z = x3 / 2 + + so I guess you need some constprop inside the constraint simplification. + +- tests/pos/data-mono0.hs + partial pattern match desugars into exception syntax with unhandled + casts. Throws an error in fixpoint. At least throw error in Constraint Gen? + (\ _ -> + (Control.Exception.Base.irrefutPatError + @ () "pos/data-mono0.hs:8:9-23|(Test.Cons x _)") + `cast` (UnsafeCo () GHC.Types.Int :: () ~ GHC.Types.Int)) + GHC.Prim.realWorld#; + + +Xmonad Case Study +================= + +Theorems (from Wouter Swierstra's Coq Development) + + - Invariant: NoDuplicates + + - prop_empty_I : new : ? -> {v | invariant(v)} + - prop_view_I : view : ? -> {v | invariant(v)} + - prop_greedyView_I : view : ? -> {v | invariant(v)} + - prop_focusUp_I + - prop_focusMaster_I + - prop_focusDown_I + - prop_focus_I + - prop_insertUp_I + - prop_delete_I + - prop_swap_master_I + - prop_swap_left_I + - prop_swap_right_I + - prop_shift_I + - prop_shift_win_I + +[prop_FOO_I] check that various functions outputs satisfy "invariant" + + FOO :: ??? -> {v: StackSet | invariant(v)} + + > Theorem prop_swap_master_I (s : StackSet.stackSet i l a sd) : + > Theorem prop_view_I (l a sd : Set) (n : nat) (s : StackSet.stackSet nat l a sd) : + > Theorem prop_greedyView_I (l a sd : Set) (n : nat) (s : StackSet.stackSet nat l a sd) : + > Theorem prop_focusUp_I (l a sd : Set) (n : nat) (s : StackSet.stackSet nat l a sd) : + > Theorem prop_focusDown_I (l a sd : Set) (n : nat) (s : StackSet.stackSet nat l a sd) : + > Theorem prop_focusMaster_I (l a sd : Set) (n : nat) (s : StackSet.stackSet nat l a sd) : + > Theorem prop_empty_I (m : l) (wids : {wids : list i | wids <> nil}) + > Theorem prop_empty (m : l) (wids : {wids : list i | wids <> nil}) + > Theorem prop_differentiate (xs : list a) : + +[prop_FOO_local] check that various functions preserve a [hidden_spaces] MEASURE + + FOO :: x: StackSet -> {v: StackSet | hidden_spaces(v) = hidden_spaces(x) } + + > Theorem prop_focus_down_local (s : stackSet i l a sd) : + > Theorem prop_focus_up_local (s : stackSet i l a sd) : + > Theorem prop_focus_master_local (s : stackSet i l a sd) : + > Theorem prop_delete_local (s : stackSet i l a sd) (eq_dec : forall x y, {x = y} + {x <> y}) : + > Theorem prop_swap_master_local (s : stackSet i l a sd) : + > Theorem prop_swap_left_local (s : stackSet i l a sd) : + > Theorem prop_swap_right_local (s : stackSet i l a sd) : + > Theorem prop_shift_master_local (s : stackSet i l a sd) : + > Theorem prop_insert_local (x : stackSet i l a sd) (eq_dec : forall x y, {x = y} + {x <> y}) : + + +BAD: these check that: forall x: foo (bar x) == x + + > Theorem prop_focus_right (s : StackSet.stackSet i l a sd) : + > Theorem prop_focus_left (s : StackSet.stackSet i l a sd) : + +[prop_swap_*_focus] check that various functions preserve a [peek] MEASURE + > Theorem prop_swap_master_focus (x : StackSet.stackSet i l a sd) : + > Theorem prop_swap_left_focus (x : StackSet.stackSet i l a sd) : + > Theorem prop_swap_right_focus (x : StackSet.stackSet i l a sd) : + + +BAD? forall x. swapMaster (swapMaster x) == x + > Theorem prop_swap_master_idempotent (x : StackSet.stackSet i l a sd) : + +BAD? forall x. view i (view i x) == (view i x) + > Theorem prop_focusMaster_idem (x : StackSet.stackSet i l a sd) : + + NO. Prove: view :: i -> x -> {v: focus(v) = i} + :: i -> x -> {v: focus(x) = i => x = v } + + To prove foo_IDEMPOTENT, find a property P such that: + + foo :: x:t -> {v:t | P(v)} + foo :: x:t -> {v:t | P(x) => v = x } + +SETS: + > Theorem prop_screens (s : stackSet i l a sd) : + + +TRIV/HARD: (function definition) + > [TRIV] Theorem prop_screens_work (x : stackSet i l a sd) : + > Theorem prop_mapWorkspaceId (x : stackSet i l a sd) : + > Theorem prop_mapLayoutId (s : stackSet i l a sd) : + > Theorem prop_mapLayoutInverse (s : stackSet i nat a sd) : + > Theorem prop_mapWorkspaceInverse (s : stackSet nat l a sd) : + +Theorem prop_lookup_current (x : stackSet i l a sd) : +Theorem prop_lookup_visible (x : stackSet i l a sd) : + + +Random Links +============ + +- Useful for DIGRAPH VIZ: http://arborjs.org/halfviz/# + + +Benchmark Tags +============== + +- LIQUIDFAIL : impossible to do verify the spec here +- LIQUIDTODO : possible with some further hacking + + + +---------------------------------------------------------------------------- + +http://www.cs.st-andrews.ac.uk/~eb/writings/fi-cbc.pdf + +McBride's Stack Machine youtube mcbride icfp 2012 monday keynote agda-curious + + data Instr = Push Val | Add + type Val = Int + + measure needs :: [Instr] -> Int + needs (Add : is) = min (2, 1 + needs(is)) + needs (Push v : is) = 0 + + run :: is:[Instr] -> {v:[Val] | len(v) >= needs(is)} -> [Val] + run (Add:is) (x1:x2:vs) = run is (x1 + x2 : vs) + run (Push v : is) vs = run is (v : vs) + +PROJECT: Termination for Combinator-based Parsers +------------------------------------------------- + +btw, did you guys see this: + +http://www.reddit.com/r/haskell/comments/1okcmh/odd_space_leak_when_using_parsec/ + +the poster probably feels silly, but I have, on several occasions, hit +this issue with parsec. Wonder whether our termination checker could be used... hmm... + +Sure! You just have to give + +type GenParser tok st = Parsec [tok] st + +a size, I guess (len [tok]). The hard part will be to prove it when the size is actually decreasing... + +Hmm... Surely we need to track somehow the "effect" of executing a single parsing action. + +For example, + + chars :: Char -> Parser [Char] + chars c = do z <- char c + zs <- chars c + return (z:zs) + +What is the machinery by which the "recursive call" is run on a "smaller" GenParser? +Does it help if we remove the `do` block? + + chars :: Char -> Parser [Char] + chars c = char c >>= \z -> + chars c >>= \zs -> + return (z:zs) + +I guess the question becomes, how/where do we specify (let alone verify) that the function +`char c` *consumes* one character, hence causing the `chars` to run on a *smaller* input? + + +Phew, after banging my head against this all day, this is what I came up with. + +You need a measure + + measure eats :: Parser a -> Nat + +which describes (a lower bound) on the number of tokens consumed by the action `Parser a`. + +Now, you give + + return :: a -> {v: Parser a | (eats v) = 0} + +and most importantly, + + (>>=) :: forall Prop> + x: Parser a + -> f:{v: a -> Parser b | (rec v) => (eats x) > 0} + -> exists z:Parser b . {v:Parser b | (eats v) = (eats z) + (eats x)} + +(Of course you have to give appropriate signatures for the parsec combinators +-- perhaps one can even PROVE the `eats` measure. However, note that + + type Parser a = [Char] -> (a, [Char]) + +roughly speaking, and here `eats` is actually the DIFFERENCE of the lengths of +the input and output [Char] ... so I'm not sure how exactly we would reason about +the IMPLEMENTATION of `eats` but certainly we should be able to USE it in clients +of parsec. + +Note that you need a refinement ON the function type, the idea being that: + +1. the BODY of a recursive function is checked in the termination-strengthened +environment that constrains the function to satisfy the predicate `rec` + +2. whenever you use >>= on a recursive function, the PRECEDING action must have +consumed some tokens. + +3. the number of tokens consumed by the combined action equals the sum of the two +actions (all the business about exists z and Q is to allow us to depend on the output +value of `f` (c.f. tests/pos/cont1.hs) + + +PROJECT: HTT style ST/IO reasoning with Abstract Refinements +------------------------------------------------------------ + ++ Create a test case: `tests/todo/Eff*.hs` + ++ Introduce a new sort of refinement `Ref` (with alias `RTProp`) + + Types.hs: Add to `Ref` -- in addition to `RMono` [---> `RPropP`] and `RPoly` [---> `RProp`] + + Types.hs: Add a `World t` for SL formulas... + + ++ Allow `PVar` to have the sort `HProp` + + CHANGE `ptype :: PVKind t` where `data PVKind t = PVProp t | PVHProp` + + Can we reuse `RAllP` to encode `HProp`-quantification? (YES) + + Update `RTyCon` to store `HProp` vars + +- Update consgen + + Can we reuse type-application sites for `HProp`-instantiation? (Yes) + - Constraint.hs :1642: = errorstar "TODO:EFFECTS:freshPredRef" + - PredType.hs : go _ (_, RHProp _ _) = errorstar "TODO:EFFECTS:replacePreds" + +- Write cons-solve + - eliminate/solve `HProp` constraints prior to subtype splitting. + +- Index `IO` or `State` by `HProp` + - Parse.hs: Update `data` parser to allow `TyCon` to be indexed by abstract `HProp` + - Bare.hs :482 : addSymSortRef _ (RHProp _ _) = errorstar "TODO:EFFECTS:addSymSortRef" + +**TODO:EFFECTS:ASKNIKI** ++ What is `isBind`,`pushConsBind` in Constraint.hs? + + +3. Suitable signatures for monadic operators + +### RHProp + +a. Following `RProp` we should have + + * RHProp := x1:t1,...,xn:tn -> World + +b. Where `World` is a _spatial conjunction_ of + + * WPreds : (h v1 ... vn), h2, ... + * Wbinds : x1 := T1, x2 := T2, ... + +c. Such that each `World` has _at most one_ `WPred` (that is _not rigid_ i.e. can be solved for.) + +**Problem:** rejigger _inference_ to account for parameters in heap variables. + + + +### RPoly (---> RProp) + +Per Niki: + + RProp := x1:t1,...,xn:tn -> RType + +with the 'predicate' application implicitly buried as a `ur_pred` inside the RType + +For example, we represent + + [a]

+ +as + + RApp [] a (RPoly [(h:a)] {v:a

}) true + +which is the `RTycon` for lists `[]` applied to: + ++ Tyvar `a` + ++ RPoly with: + * _params_ `h:a` + * _body_ `{v:a

| true}` which is really, `RVar a {ur_reft = true, ur_pred = (Predicate 'p' with params 'h')}` + ++ Outer refinement `true` + + + + + + + +**Heap Propositions** `HProp` + +```haskell +CP := l :-> T * CP -- Concrete Heap + | emp + +HP := CP + | CP * H -- Heap Variable +``` + +That is, an `HProp` is of the form: + + H * l1 |-> T1 * ... * ln |-> Tn + +or + + l1 |-> T1 * ... * ln |-> Tn + +I am disallowing multiple variables because it causes problems... + + +**Abstractly Refined ST/IO** + +```haskell +data IO a 

 HProp>
+```
+
+**Refined Monadic Operators**
+
+```haskell
+return :: forall a, .
+            a -> IO  H> a
+
+(>>=)  :: forall a, b, 
 HProp, R :: b -> HProp>.
+            IO a -> (x:a -> IO b) -> IO b
+```
+
+**Q1.** How does LH *reason* about `HProp`?
+
+Via subtyping as always, so:
+
+         forall i. Γ |- Ti <: Ti'
+    -----------------------------------
+    Γ |- *_i li :-> Ti <: *_i li -> Ti'
+
+For this, we need to put in explicit `HProp` instantiations, just like
+tyvar (α) and  predvar (π) instinstatntiations. This is doable with a
+pre-pass that generates and solves `HProp` constraints as follows:
+
+1. At each instantiation, make up _fresh_ variables `h`
+2. Treat _bound_ heap-variables as **constants**
+3. Instantiation yields a set of constraints over `h`
+4. Solve constraints via algorithm below.
+
+**Q2.** Can you _name_ values inside `HProp`?
+
+Nope. There's no reason for this, but its tedious to have to make up
+new heap binders and what not. Clutters stuff. This is _slightly_
+problematic. For example, how do you write a function of the form:
+
+```haskell
+incr :: p:IORef Int -> IO Int
+```
+
+which _increments_ the value stored at the reference? Solution is slightly
+clunky: rather than the _implicit_ heap binder, add an explicit pure parameter:
+
+```haskell
+incr :: p:IORef Int -> i:Int -> IO {v:Int| v = i} 
 {v = i}, p |-> {v = i + 1}>
+```
+
+**Q3.** How to relate `Post`-condition to the `Pre`-conditions?
+
+Note that the `Post`-condition is a unary predicate -- i.e. _does not_
+refer to the input world. How then do we relate the input and output heaps?
+As above: _name_ the values of the input heap that you care about, and then
+relate `Post` to `Pre` via the name.
+
+**Q4.** How to _read_ values off the heap?
+
+Given that we don't have heap binders, this might seem like a problem? Not
+really. Just write signatures like:
+
+    read :: IORef a -> IO a
+
+aha, but there's a problem: the `a` is too _coarse_ or flow-insensitive: it
+holds a supertype of all the values written at the location, as opposed to the
+_current_ value. No matter, abstract refinements to the rescue:
+
+    read :: forall  Prop>.
+              p:IORef a -> IO 
 a, p |-> a> a
+
+**Q5.** How do you do _subtyping_ on heaps/frame rule?
+
+Wait, how do I write _compositional_ signatures that only talk about a
+particular part of the state but allow me to say _other_ parts are unmodified
+etc? Don't you need heap subtyping? No: we can make the frame rule explicit by
+abstracting over heaps:
+
+    read :: forall  Prop, H :: HProp>.
+              p:IORef a -> IO 
 a * H, p |-> a * H> a
+
+**Q6.** How to solve heap constraints?
+
+Heap constraints are of the form:
+
++ (C0)  `ch1      = ch2`        -- constants
++ (C1)  `H1 * ch1 = ch2`        -- 1-variable
++ (C2)  `H1 * ch1 = H2 * ch2`   -- 2-variable
+
+Here, each `ch` is of the form:
+
+    l1 |-> τ1 * ... * ln -> τn * A1 * ... * An
+
+where each `Ai` is a _rigid_ or quantified heap var that is atomic,
+i.e. cannot be further solved for. For solving, we throw away _all_
+refinements, and just use the shape τ.
+
+```
+solve :: Sol -> [Constraint] -> Maybe Sol
+solve σ []     
+  = Just σ
+solve σ (c:cs)
+  = case c of
+      C0 ch1 ch2 ->
+        if ch1 `equals` ch2  then
+          -- c is trivially SAT,
+          solve σ cs
+        else
+          -- c and hence all constraints are unsat
+          Nothing
+
+      C1 (H1 * ch1) ch2 ->
+        if ch1 `subset` ch2 then
+          let σ' = [H1 := c2 `minus` c1]
+          solve (σ . σ') (σ' <$> cs)
+        else
+          -- c and hence all constraints are unsat
+          Nothing
+
+      C2 (H1 * ch1) (H2 * ch2) ->
+        let H = fresh heap variable
+        let σ'  = [H1 := H * ch2, H2 := H * ch1]
+        solve (σ . σ') (σ' <$> cs)
+```
+
+
+
+PROJECT: (OLD) HTT style ST/IO reasoning with Abstract Refinements
+------------------------------------------------------------------
+
+
+Can we use abstract refinements to do "stateful reasoning",
+e.g. about stuff in `IO` ? For example, to read files, this
+is the API:
+
+    open  :: FilePath -> IO Handle
+    read  :: Handle   -> IO String
+    write :: Handle   -> String -> IO ()
+    close :: Handle   -> IO ()
+
+The catch is that:
+
++ `read` and `write` require the `Handle` to be in an "open" state,
++ which is the state of the `Handle` returned by `open`,
++ while `close` presumably puts the `Handle` in a "closed" state.
+
+So, suppose we parameterize IO with two predicates a `Pre` and `Post` condition
+
+    data IO a 
 Prop>  World -> World -> Prop>
+
+where `World` is some abstract type denoting the global machine state.
+Now, it should be possible to give types like:
+
+   (>>=)  :: IO a  -> (x:a -> IO b) -> IO b
+   return :: a -> IO a 
+
+which basically state whats going on with connecting the conditions, and then,
+give types to the File API:
+
+   open  :: FilePath -> IO Handle <\_ -> True> <\h _ w -> (IsOpen h w)>
+   read  :: h:Handle -> IO String <\w -> (IsOpen h w)> <\_ _ w -> (IsOpen h w)>
+   close :: h:Handle -> IO ()     <\w -> (IsOpen h w)> <\_ _ w -> not (IsOpen h w)>
+
+Wonder if something like this would work?
+
+Niki:
+My question is how do you make Q from a post-condition (Q :: a -> Word -> Word -> Prop)
+to a pre-condition.
+I guess you need to apply a value x :: a and a w :: Word to write (a -> IO b).
+
+I think the problem is that the "correct" values x and w are not "in scope"
+
+
+So assume
+
+    data IO a 
 Prop, Q: a -> Word -> Word -> Prop>
+      = IO (x:Word
 -> (y:a, Word))
+
+and you want to type
+
+    bind :: IO a  -> (a -> IO b ) -> IO b 
+    bind (IO m) k = IO $ \s -> case m s of
+                                 (a, s') -> unIO (k a) s'
+
+
+You have
+
+    IO m :: IO a  => m :: xx:Word 
 -> (y:a, Word )
+
+you can assume
+
+    s:: Word 

+
+so
+
+    m s         :: (y:a, Word )
+    k a         :: IO b 
+    uniIO (k a) :: z:Word  -> (xx:b, Word )
+
+and we want
+
+    (uniIO k a) s :: (xx:b , Word )
+
+so basically we need
+
+    P  => Q x w
+
+to be able to make the final application
+
+**Ranjit**
+You are right. We need to convert the "post" of the first action into the "pre"
+of the second, which is a problem since the former takes three, parameters while
+the latter takes only one.
+
+BUT, how about this (basically, all you need is an EXISTS).
+
+   -- | the type for `return` says that the output world satisfies
+   --   whatever predicate the input world satisfied.
+
+   return :: a -> IO a  (P w')}>
+
+   -- | the type for `bind` says that its action requires as input a world that satisfies
+   --   Q (for SOME input world w0) and produces as output an R world.
+   (>>=)  :: IO a 
+          -> (x:a -> \exists w0:World. IO b<{\w -> (Q x w0 w)}, R>)
+          -> IO b \exists xa:a w0:World.(R xb w0 w')}>
+
+
+
+Basically, I am using exists in the same way as in the "compose"
+
+https://github.com/ucsd-progsys/liquidhaskell/blob/master/tests/pos/funcomposition.hs
+
+to name the intermediate worlds and results (after all, this seems
+like a super fancy version of `.` ) -- may have not put them in the
+right place...
+
+Btw, the existential is also how the HOARE rule for strongest postcondition works,
+if you recall:
+
+   {P} x := e {exists x'. P[x'/x] /\ x = e[x'/x]}
+
+
+
+
+One of the hardest steps seem to type the monad function (>>=):
+
+
+So, suppose we parameterize IO with two predicates a `Pre` and `Post` condition
+
+    data IO a 
 Prop>  World -> World -> Prop>
+
+where `World` is some abstract type denoting the global machine state.
+Now, it should be possible to give types like:
+
+   (>>=)  :: IO a  -> (a -> IO b) -> IO b
+   return :: a -> IO a 
+
+
+
+My question is how do you make Q from a post-condition (Q :: a -> Word -> Word -> Prop)
+to a pre-condition.
+I guess you need to apply a value x :: a and a w :: Word to write (a -> IO b).
+
+I think the problem is that the "correct" values x and w are not "in scope"
+
+
+So assume
+data IO a 
 Prop, Q: a -> Word -> Word -> Prop> = IO (x:Word
 -> (y:a, Word))
+
+and you want to type
+
+bind :: IO a  -> (a -> IO b ) -> IO b 
+bind (IO m) k = IO $ \s -> case m s of (a, s') -> (unIO (k a)) s'
+
+You have
+
+IO m :: IO a   
+             => m :: xx:Word 
 -> (y:a, Word )
+
+you can assume
+s:: Word 

+
+so
+m s :: (y:a, Word )
+
+k a :: IO b 
+
+uniIO (k a) :: z:Word  -> (xx:b, Word )
+
+and we want
+(uniIO k a) s :: (xx:b , Word )
+
+so basically we need
+P  => Q x w
+to be able to make the final application
+
+
+bind :: ST a  -> (a -> ST b ) -> ST b 
+bind (ST f1) k = ST $ \s0 -> let (x, s1) = f1 s0  
+                                 ST f2   = k x
+                                 (y, s2) = f2 s1
+                             in
+                                 (y, s2)
+
+
+PROJECT: Using `Dynamic` + Refinements for Mixed Records
+--------------------------------------------------------
+
+Haskell has a class (and related functions)
+
+    toDyn   :: (Typeable a) => a -> Dynamic
+    fromDyn :: (Typeable a) => Dynamic -> Maybe a
+
+Q: How to encode *heterogenous* maps like:
+
+    d1 = { "name"  : "Ranjit"
+         , "age"   : 36
+         , "alive" : True
+         }
+
+   and also:
+
+    d2 = { "name"    : "Jupiter"
+         , "position": 5
+         }
+
+   so that you can write generic *duck-typed* functions like
+
+    showName :: Dict -> String
+
+   and write
+
+    showName d1
+    showName d2
+
+   or even
+
+    map showName [d1, d2]
+
+Step 1: Encode dictionary as vanilla Haskell type
+
+    type Dict  Dynamic -> Prop> = Map String Dynamic 
+    empty :: Dict
+    put   :: (Dynamic a) => String -> a -> Dict -> Dict
+    get   :: (Dynamic a) => String -> Dict -> Dict
+
+Step 2: **Create** dictionaries
+
+    d1 = put "name"   "RJ"
+       $ put "age"    36
+       $ put "alive"  True
+       $ empty
+
+    d1 = put "name"   "Jupiter"
+       $ put "pos"    5
+       $ empty
+
+Step 3: **Lookup** dictionaries
+
+    showName :: Dict -> String
+    showName d = get "name" d
+
+    -- TODO: how to support
+    showName :: Dict -> Dict
+    incrAge d = put "age" (n + 1) d
+      where
+            n = get "age" d
+
+    -- TODO: how to support
+    concat :: Dict -> Dict -> Dict
+
+Step 4: Can directly, without any casting nonsense, call
+
+    showName d1
+    showName d2
+
+Need to reflect *Haskell Type* (or at least, `TypeRep` values)
+inside logic, so you can write measures like
+
+    measure TypeOf :: a -> Type
+
+and use it to define refinements like
+
+    (TypeOf v = Int)
+
+(TODO: too bad we don't have relational measures... or multi-param measures ... yet!)
+
+which we can macro up thus.
+
+    predicate HasType V T = (TypeOf V = T)
+
+    predicate Fld K V N T = (K = N => (HasType V T))
+
+Step 5: Refined Signatures for `Dict` API
+
+    put :: (Dynamic a) => key:String
+                       -> {value:a | (Q key value)}
+                       -> d:Dict  k /= key}>
+                       -> Dict  (Fld k v key a)}>
+
+    get :: (Dynamic a) => key:String
+                       -> d:Dict <{\k v -> (Fld k v key a)}>
+                       -> a
+
+Step 6: Now, for example, we should be able to type our dictionaries as
+
+    {-@ d1 :: Dict @-}
+
+where
+
+    Q1 == \k v -> Fld k v "name"  String /\
+                  Fld k v "age"   Int    /\
+                  Fld k v "alive" Bool   
+
+and
+
+    {-@ d2 :: Dict @-}
+
+where
+
+    Q2 == \k v -> Fld k v "name"  String /\
+                  Fld k v "pos"   Int    /\
+
+**TODO:**
+
++ add support for `Type` inside logic
+  + needed for `TypeOf` measure, equality checks
+  + requires doing type-substitutions inside refinements
+
++ add support for
+  + update [isn't that just `put`?]
+  + concat
+
++ add support traversals (cf. *Ur*)
+  - Fold   (over all fields, eg. to serialize into a String)
+  - Map?   (transform all fields to serialize) toDB?
+  - Filter (takes a predicate that should only read valid columns of the record)
+
+
+PROJECT: Equational Reasoning
+-----------------------------
+
+e.g. Type class laws.
+
+Many type-classes come with a set of laws that instances are expected
+to abide by, e.g.
+
+```
+fmap id  ==  id
+
+fmap (f . g)  ==  fmap f . fmap g
+```
+
+```
+mappend mempty x = x
+
+mappend x mempty = x
+
+mappend x (mappend y z) = mappend (mappend x y) z
+```
+
+**Strategy**
+
+**1. Representing Proofs**
+
+```
+data Proof  = Proof           -- void, pure refinement
+
+type Pf P   = {v:Proof | P}
+
+type Eq X Y = Pf (X == Y)
+```
+
+**2. Combining Proofs**
+
+```
+bound Imp P Q R = P => Q => R
+
+eq, imp :: (Imp P Q R) => Pf P -> Pf Q -> Pf R
+
+refl    :: x:a -> Eq a x x
+```
+
+**3. Axiomatizing arithmetic**
+
+```
+add :: x:Int -> y:Int -> {z:Int | z = x + y} -> Eq (x + y) z
+add x y z = auto
+```
+
+
+**Example 1: Arithmetic**
+
+Lets drill in: how to represent the following "equational" proof in LH?
+
+```
+     (1 + 2) + (3 + 4)       -- e0
+
+     { 1 + 2 == 3}
+
+  == 3 + (3 + 4)             -- e1
+
+     { 3 + 4 == 7}
+
+  == 3 + 7                   -- e2
+
+     { 3 + 7 == 10}
+
+  == 10                      -- e3
+```
+
+Now the above proof looks like this:
+
+```
+e0 :: Int
+e0 = (1 + 2) + (3 + 4)
+
+prop :: Eq e0 10
+prop = (((refl e0  `imp` (add 1 2 3))   -- :: Eq e0 (3 + (3 + 4))
+
+                   `imp` (add 3 4 7))   -- :: Eq e0 (3 + 7)
+
+                   `imp` (add 3 7 10))  -- :: Eq e0 10  
+```
+
+
+**Example 2: Lists**
+
+A more interesting example: Lets prove `prop_app_nil`:
+
+    prop_app_nil: forall xs. append xs [] = xs
+
+The definition of
+
+```
+append []     ys = ys
+append (x:xs) ys = x : append xs ys
+```
+
+yields the *axioms*
+
+```
+append_nil  :: ys:_ -> Eq (append [] ys) ys
+append_cons :: x:_ -> xs:_ -> ys:_ -> Eq (append (x:xs) ys) (x : append xs ys)
+```
+
+Code on left, "equations" on right.
+
+```
+prop_app_nil    :: xs:[a] -> Eq (append xs []) xs
+
+prop_app_nil []     = refl (append [] [])             
+                                                   -- append [] []
+                       `by` (append_nil [])        -- { append_nil [] }    
+                                                   -- == []  
+
+prop_app_nil (x:xs) = refl (append (x:xs) [])       
+                                                   -- append (x:xs) []
+                       `by` (append_cons x xs [])  -- { append_cons x xs [] }
+                                                   -- == x : append xs []
+                       `by` (prop_app_nil xs)      -- { IH: prop_app xs }
+                                                   -- == x : xs
+```
+
+**Example 4: Append Associates**
+
+
+```
+prop_app_assoc :: xs:_ -> ys:_ -> zs:_ ->
+                     Eq ((xs ++ ys) ++ zs) (xs ++ (ys ++ zs))
+
+prop_app_assoc [] ys zs
+  ([] ++ ys) ++ zs
+  { append_nil _ }    
+  == ys ++ zs
+  { append_nil _ }
+  == [] ++ (ys ++ zs)
+
+prop_app_assoc (x:xs) ys zs
+  ((x:xs) ++ ys) ++ zs
+  { append_cons _ _ _ }    
+  == (x : (xs ++ ys)) ++ zs
+  { append_cons _ _ _ }
+  == x : ((xs ++ ys) ++ zs)
+  { prop_app_assoc _ _ _ }
+  == x : (xs ++ (ys ++ zs))
+  { append_cons _ _ _ }
+  == (x : xs) ++ (ys ++ zs)
+```
+
+
+**Example 4: Map Fusion**
+
+Lets go fancier:
+
+
+    forall xs. map (f . g) xs = (map f . map g) xs
+
+Here's the classical (?) equational proof:
+
+```
+map (f . g) []   
+   { map_nil (f . g) }
+   == []
+   { map_nil f }
+   == map f []
+   { map_nil g }
+   == map f (map g [])
+   { dot f g }
+   == (map f . map g) []
+
+map (f . g) (x:xs)  
+   { map_cons (f . g) x xs }
+   == (f . g) x : map (f . g) xs
+   { map_dot f g xs }
+   == (f . g) x : (map f . map g) xs
+   { dot (map f) (map g) }
+   == (f . g) x : map f (map g xs)
+   { dot f g }
+   == f (g x) : map f (map g xs)
+   {map_cons f (g x) (map g xs) }
+   == map f (g x : map g xs)
+   {map_cons g x xs}
+   == map f (map g (x : xs))
+   { dot (map f) (map g) }
+   ==  (map f . map g) (x : xs)
+```
+
+Formalize thus (with functions/axioms)
+
+```
+map f []     = []               -- map_nil
+map f (x:xs) = f x  : map f xs  -- map_cons
+
+(f . g) x    =  f (g x)         -- dot
+```
+
+Now, we formalize map-fusion as:
+
+```
+map_fusion :: f:_ -> g:_ -> xs:_ ->
+              Eq (map (f . g) xs) (map f . map g) xs
+
+map_fusion f g []     = map_dot_nil f g
+map_fusion f g (x:xs) = map_dot_cons f g x xs
+```
+
+The hard work happens in the two "lemmas"
+
+```
+map_dot_nil :: f:_ -> g:_ ->
+               Eq (map (f . g) []) ((map f . map g) [])
+map_dot_nil f g
+  = refl (map (f . g) [])   
+                              -- map (f . g) []
+     `by` (map_nil (f . g))
+                              -- == []
+     `by` (map_nil f)
+                              -- == map f []
+     `by` (map_nil g)
+                              -- == map f (map g [])
+     `by` (dot f g)
+                              -- == (map f . map g) []
+```
+
+and
+
+```
+map_dot_cons :: f:_ -> g:_ -> x:_ -> xs:_ ->
+               Eq (map (f . g) (x:xs)) ((map f . map g) (x:xs))
+map_dot_cons f g x xs
+  = refl (map (f . g) (x:xs))
+                                          -- map (f . g) (x : xs)
+      `by` (map_cons (f . g) x xs)
+                                          -- == (f . g) x : map (f . g) xs
+      `by` (map_dot f g xs)
+                                          -- == (f . g) x : (map f . map g) xs
+      `by` (dot (map f) (map g))
+                                          -- == (f . g) x : map f (map g xs)
+      `by` (dot f g)
+                                          -- == f (g x) : map f (map g xs)
+      `by` (map_cons f (g x) (map g xs))
+                                          -- == map f (g x : map g xs)
+      `by` (map_cons g x xs)
+                                          -- == map f (map g (x : xs))
+      `by` (dot (map f) (map g))
+                                          -- ==  (map f . map g) (x : xs)
+```
+
+
+
+GHC 7.10
+--------
+
+- **DONE** singleton type classes represented by newtype
+  - tried to work around by translating
+
+      foo `cast` (co :: a -> b ~ Foo)
+
+    to
+
+      D:Foo foo
+
+    but it still breaks when we don't have an LH class decl
+  - without LH class decl we never see D:Foo, so it doesn't go in CGEnv
+  - SOLUTION: put ALL visible dict constructors in CGEnv
+
+- `cast`s are used more often and we seem to lose information..
+  - seems particularly problematic with ST
+
+- srcloc annotations
+  - -g adds SourceNotes, but the html output is borked
+  - in particular, infix operators aren't annotated correctly (at all?)
+  - are we missing some SrcLocs??
+    - clearly not, if you look at the output of
+
+          ghc -g -ddump-ds -dppr-ticks 
+
+      somewhere along our pipeline the ticks are either being dropped,
+      or the SrcSpans don't quite match the way they used to...
+
+- termination metrics are required in a few places where they were not previously
+  - my guess is that ghc's behaviour for grouping functions in a `Rec` binder have changed
diff --git a/cabal.project b/cabal.project
new file mode 100644
--- /dev/null
+++ b/cabal.project
@@ -0,0 +1,12 @@
+-- For more information see
+--  http://cabal.readthedocs.io/en/latest/nix-local-build-overview.html
+
+packages: .
+          ./liquid-fixpoint
+          ./liquiddesugar
+
+package liquid-fixpoint
+  flags: devel
+
+package liquidhaskell
+  flags: devel
diff --git a/circle.yml b/circle.yml
new file mode 100644
--- /dev/null
+++ b/circle.yml
@@ -0,0 +1,56 @@
+machine:
+  #ghc:
+  #  version: 7.10.2
+  pre:
+    - sudo add-apt-repository -y ppa:hvr/z3
+    # - sudo add-apt-repository -y ppa:hvr/ghc
+    - sudo apt-get -y update
+    - sudo apt-get -y install z3 # ghc-7.10.3
+
+checkout:
+  post:
+    - git submodule sync
+    - sed -i '/fixpoint.git/a fetch = +refs/pull/*/head:refs/remotes/origin/pr/*' .git/modules/liquid-fixpoint/config
+    - git submodule update --init
+    - pwd
+
+dependencies:
+  cache_directories:
+    - "~/.stack"
+    - ".stack-work"
+  pre:
+    # - curl -sSL https://get.haskellstack.org/ | sh
+    - curl -SL https://www.stackage.org/stack/linux-x86_64-static | tar zx -C /tmp
+    # - curl -L https://github.com/commercialhaskell/stack/releases/download/v1.0.4/stack-1.0.4-linux-x86_64.tar.gz | tar zx -C /tmp
+    - sudo mv /tmp/stack-*-linux-x86_64-static/stack /usr/bin
+  override:
+    - stack setup
+    - rm -fr $(stack path --dist-dir) $(stack path --local-install-root)
+    - stack install --fast hlint packdeps cabal-install
+    - stack build liquidhaskell --fast --only-dependencies --test --no-run-tests
+    
+compile:
+  override:
+    # - stack build liquidhaskell --fast --pedantic --flag liquidhaskell:include --flag liquidhaskell:devel
+    - stack build liquidhaskell --fast --flag liquidhaskell:include --flag liquidhaskell:devel
+    - stack build liquidhaskell --fast --flag liquidhaskell:include --flag liquidhaskell:devel --test --no-run-tests
+
+test:
+  override:
+    - mkdir -p $CIRCLE_TEST_REPORTS/junit
+    - stack test liquidhaskell:test --flag liquidhaskell:include --flag liquidhaskell:devel --test-arguments="-j1 --xml=$CIRCLE_TEST_REPORTS/junit/main-test-results.xml --liquid-opts='--cores=1'":
+        timeout: 1800
+    - stack test liquidhaskell:liquidhaskell-parser --test-arguments="-j2 --xml=$CIRCLE_TEST_REPORTS/junit/parser-test-results.xml":
+        timeout: 1800
+    # - git ls-files | grep '\.l\?hs$' | xargs stack exec -- hlint -X QuasiQuotes "$@"
+    # - stack exec -- cabal update
+    # - stack exec --no-ghc-package-path -- cabal install --only-dependencies --dry-run --reorder-goals
+    # - stack exec -- packdeps *.cabal || true
+    # - stack exec -- cabal check
+    - stack sdist
+  post:
+    - stack haddock liquidhaskell --no-haddock-deps --haddock-arguments="--no-print-missing-docs --odir=$CIRCLE_ARTIFACTS"
+    # - cp -r dist/doc $CIRCLE_ARTIFACTS
+    - mkdir -p $CIRCLE_TEST_REPORTS/tasty
+    - cp -r tests/logs/cur $CIRCLE_TEST_REPORTS/tasty/log
+    # - hpc-coveralls --exclude-dir=tests --repo-token=$COVERALLS_REPO_TOKEN
diff --git a/cleanup b/cleanup
new file mode 100644
--- /dev/null
+++ b/cleanup
@@ -0,0 +1,1 @@
+find . | grep -E -e '\.(smt2|bak|json|css|md|hi|out|fqout|fq|o|err|annot|log|html|cgi|liquid)$' | xargs rm -rf
diff --git a/default.nix b/default.nix
new file mode 100644
--- /dev/null
+++ b/default.nix
@@ -0,0 +1,38 @@
+{ fetchgitLocal }:
+{ mkDerivation, aeson, array, base, bifunctors, bytestring, Cabal
+, cereal, cmdargs, containers, cpphs, daemons, data-default
+, deepseq, Diff, directory, filepath, fingertree, ghc, ghc-paths
+, hashable, hpc, hscolour, liquid-fixpoint, located-base, mtl
+, network, optparse-applicative, parsec, pretty, process
+, stdenv, stm, syb, tagged, tasty, tasty-hunit, tasty-rerun
+, template-haskell, text, time, transformers, unix
+, unordered-containers, vector, z3
+, tasty-ant-xml
+}:
+mkDerivation {
+  pname = "liquidhaskell";
+  version = "9.9.9.9";
+  src = fetchgitLocal ./.;
+  isLibrary = true;
+  isExecutable = true;
+  libraryHaskellDepends = [
+    aeson array base bifunctors bytestring Cabal cereal cmdargs
+    containers cpphs data-default deepseq Diff directory filepath
+    fingertree ghc ghc-paths hashable hpc hscolour liquid-fixpoint
+    located-base mtl parsec pretty process syb template-haskell
+    text time unordered-containers vector hscolour
+  ];
+  executableHaskellDepends = [
+    base bytestring cereal cmdargs daemons data-default deepseq
+    directory ghc liquid-fixpoint located-base network pretty process
+    unix unordered-containers
+  ];
+  testHaskellDepends = [
+    base containers directory filepath mtl optparse-applicative process
+    stm tagged tasty tasty-hunit tasty-rerun transformers tasty-ant-xml
+  ];
+  testSystemDepends = [ z3 ];
+  homepage = "http://goto.ucsd.edu/liquidhaskell";
+  description = "Liquid Types for Haskell";
+  license = stdenv.lib.licenses.bsd3;
+}
diff --git a/devel/Paths_liquidhaskell.hs b/devel/Paths_liquidhaskell.hs
new file mode 100644
--- /dev/null
+++ b/devel/Paths_liquidhaskell.hs
@@ -0,0 +1,12 @@
+{-# LANGUAGE TemplateHaskell #-}
+module Paths_liquidhaskell where
+
+import Language.Haskell.TH
+import System.Directory
+import System.FilePath
+
+getDataFileName :: FilePath -> IO FilePath
+getDataFileName f = do
+  let loc = $(do { loc <- location; f <- runIO (canonicalizePath (loc_filename loc)); litE (stringL f); })
+  let root = takeDirectory (takeDirectory loc)
+  return (root  f)
diff --git a/docs/blog/2013-01-01-refinement-types-101.lhs b/docs/blog/2013-01-01-refinement-types-101.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-01-01-refinement-types-101.lhs
@@ -0,0 +1,312 @@
+---
+layout: post
+title: "Refinement Types 101"
+date: 2013-01-01 16:12
+author: Ranjit Jhala
+published: true
+comments: true
+external-url:
+categories: basic
+demo: refinements101.hs
+---
+
+One of the great things about Haskell is its brainy type system that
+allows one to enforce a variety of invariants at compile time, thereby
+nipping a large swathe of run-time errors in the bud. Refinement types
+allow us to use modern logic solvers (*aka* SAT and SMT engines) to
+dramatically extend the scope of invariants that can be statically
+verified.
+
+What is a Refinement Type?
+--------------------------
+
+In a nutshell, 
+
+

+Refinement Types = Types + Logical Predicates
+

+
+That is, refinement types allow us to decorate types with 
+*logical predicates* (think *boolean-valued* Haskell expressions) 
+which constrain the set of values described by the type, and hence 
+allow us to specify sophisticated invariants of the underlying values. 
+
+Say what? 
+
+
+
+(Btw, *click the title* to demo LiquidHaskell on the code in this article)
+
+\begin{code}
+module Intro where
+
+import Language.Haskell.Liquid.Prelude  (liquidAssert)
+\end{code}
+
+Let us jump right in with a simple example, the number `0 :: Int`. 
+As far as Haskell is concerned, the number is simply an `Int` (lets not
+worry about things like `Num` for the moment). So are `2`, `7`, and 
+`904`. With refinements we can dress up these values so that they 
+stand apart. For example, consider the binder
+
+\begin{code}
+zero' :: Int
+zero' = 0
+\end{code}
+
+We can ascribe to the variable `zero'` the refinement type
+
+\begin{code}
+{-@ zero' :: {v: Int | 0 <= v} @-}
+\end{code}
+
+which is simply the basic type `Int` dressed up with a predicate.
+The binder `v` is called the *value variable*, and so the above denotes 
+the set of `Int` values which are greater than `0`. Of course, we can
+attach other predicates to the above value, for example
+
+**Note:** We will use `@`-marked comments to write refinement type 
+annotations the Haskell source file, making these types, quite literally,
+machine-checked comments!
+
+
+\begin{code}
+{-@ zero'' :: {v: Int | (0 <= v && v < 100) } @-}
+zero'' :: Int
+zero'' = 0
+\end{code}
+
+which states that the number is in the range `0` to `100`, or
+
+\begin{code}
+{-@ zero''' :: {v: Int | ((v mod 2) = 0) } @-}
+zero''' :: Int
+zero''' = 0
+\end{code}
+
+where `mod` is the *modulus* operator in the refinement logic. Thus, the type
+above states that zero is an *even* number.
+
+We can also use a singleton type that precisely describes the constant
+
+\begin{code}
+{-@ zero'''' :: {v: Int | v = 0 } @-}
+zero'''' :: Int
+zero'''' = 0
+\end{code}
+
+(Aside: we use a different names `zero'`, `zero''` etc. for a silly technical 
+reason -- LiquidHaskell requires that we ascribe a single refinement type to 
+a top-level name.)
+
+Finally, we could write a single type that captures all the properties above:
+
+\begin{code}
+{-@ zero :: {v: Int | ((0 <= v) && ((v mod 2) = 0) && (v < 100)) } @-}
+zero     :: Int
+zero     =  0
+\end{code}
+
+The key points are:
+
+1. A refinement type is just a type *decorated* with logical predicates.
+2. A value can have *different* refinement types that describe different properties.
+3. If we *erase* the green bits (i.e. the logical predicates) we get back *exactly* 
+   the usual Haskell types that we know and love.
+4. A vanilla Haskell type, say `Int` has the trivial refinement `true` i.e. is 
+   really `{v: Int | true}`.
+
+We have built a refinement type-based verifier called LiquidHaskell. 
+Lets see how we can use refinement types to specify and verify interesting 
+program invariants in LiquidHaskell.
+
+Writing Safety Specifications
+-----------------------------
+
+We can use refinement types to write various kinds of more interesting
+safety specifications.
+
+First, we can write a wrapper around the usual `error` function 
+
+\begin{code}
+{-@ error' :: {v: String | false } -> a  @-}
+error'     :: String -> a
+error'     = error
+\end{code}
+
+The interesting thing about the type signature for `error'` is that the
+input type has the refinement `false`. That is, the function must only be
+called with `String`s that satisfy the predicate `false`. Of course, there
+are *no* such values. Thus, a program containing the above function
+typechecks *exactly* when LiquidHaskell can prove that the function
+`error'` is *never called*.
+
+Next, we can use refinements to encode arbitrary programmer-specified 
+**assertions** by defining a function
+
+\begin{code}
+{-@ lAssert     :: {v:Bool | (Prop v)} -> a -> a  @-}
+lAssert         :: Bool -> a -> a 
+lAssert True  x = x
+lAssert False _ = error' "lAssert failure" 
+\end{code}
+
+In the refinement, `(Prop v)` denotes the Haskell `Bool` value `v` 
+interpreted as a logical predicate. In other words, the input type for 
+this function specifies that the function must *only* be called with
+the value `True`.
+
+
+Refining Function Types : Preconditions
+---------------------------------------
+
+Lets use the above to write a *divide* function that *only accepts* non-zero
+denominators. 
+
+\begin{code}
+divide     :: Int -> Int -> Int
+divide n 0 = error' "divide by zero"
+divide n d = n `div` d
+\end{code}
+
+We can specify that the non-zero denominator *precondition* with a suitable 
+refinement on the *input* component of the function's type 
+
+\begin{code}
+{-@ divide :: Int -> {v: Int | v != 0 } -> Int @-}
+\end{code}
+
+How *does* LiquidHaskell verify the above function? 
+
+The key step is that LiquidHaskell deduces that the expression 
+`"divide by zero"` is not merely of type `String`, but in fact 
+has the the refined type `{v:String | false}` *in the context* 
+in which the call to `error'` occurs.
+
+LiquidHaskell arrives at this conclusion by using the fact that 
+in the first equation for `divide` the *denominator* parameter 
+is in fact `0 :: {v: Int | v = 0}` which *contradicts* the 
+precondition (i.e. input) type.
+
+In other words, LiquidHaskell deduces by contradiction, that 
+the first equation is **dead code** and hence `error'` will 
+not be called at run-time.
+
+If you are paranoid, you can put in an explicit assertion
+
+\begin{code}
+{-@ divide' :: Int  -> {v:Int | v /= 0} -> Int @-}
+divide'     :: Int -> Int -> Int
+divide' n 0 = error' "divide by zero"
+divide' n d = lAssert (d /= 0) $ n `div` d
+\end{code}
+
+and LiquidHaskell will verify the assertion (by verifying the call to
+`lAssert`) for you.
+
+Refining Function Types : Postconditions
+----------------------------------------
+
+Next, lets see how we can use refinements to describe the *outputs* of a
+function. Consider the following simple *absolute value* function
+
+\begin{code}
+abz               :: Int -> Int
+abz n | 0 < n     = n
+      | otherwise = 0 - n
+\end{code}
+
+We can use a refinement on the output type to specify that the function 
+returns non-negative values
+
+\begin{code}
+{-@ abz :: Int -> {v: Int | 0 <= v } @-}
+\end{code}
+
+LiquidHaskell *verifies* that `abz` indeed enjoys the above type by
+deducing that `n` is trivially non-negative when `0 < n` and that in 
+the `otherwise` case, i.e. when `not (0 < n)` the value `0 - n` is
+indeed non-negative (lets not worry about underflows for the moment.)
+LiquidHaskell is able to automatically make these arithmetic deductions
+by using an [SMT solver](http://rise4fun.com/Z3/) which has decision
+built-in procedures for arithmetic, to reason about the logical
+refinements.
+
+
+
+Putting It All Together
+-----------------------
+
+Lets wrap up this introduction with a simple `truncate` function 
+that connects all the dots. 
+
+\begin{code}
+{-@ truncate :: Int -> Int -> Int @-}
+truncate i max  
+  | i' <= max' = i
+  | otherwise  = max' * (i `divide` i')
+    where i'   = abz i
+          max' = abz max 
+\end{code}
+
+`truncate i n` simply returns `i` if its absolute value is less the
+upper bound `max`, and otherwise *truncates* the value at the maximum.
+LiquidHaskell verifies that the use of `divide` is safe by inferring that 
+at the call site
+
+1. `i' > max'` from the branch condition.
+2. `0 <= i'`   from the `abz` postcondition (hover mouse over `i'`).
+3. `0 <= max'` from the `abz` postcondition (hover mouse over `max'`).
+
+From the above, LiquidHaskell infers that `i' != 0`. That is, at the
+call site `i' :: {v: Int | v != 0}`, thereby satisfying the
+precondition for `divide` and verifying that the program has no pesky 
+divide-by-zero errors. Again, if you *really* want to make sure, put 
+in an assertion
+
+\begin{code}
+{-@ truncate' :: Int -> Int -> Int @-}
+truncate' i max  
+  | i' <= max' = i
+  | otherwise  = lAssert (i' /= 0) $ max' * (i `divide` i')
+    where i'   = abz i
+          max' = abz max 
+\end{code}
+
+and *lo!* LiquidHaskell will verify it for you.
+
+Modular Verification
+--------------------
+
+Incidentally, note the `import` statement at the top. Rather than rolling
+our own `lAssert` we can import and use a pre-defined version `liquidAssert` 
+defined in an external [module](https://github.com/ucsd-progsys/liquidhaskell/blob/master/include/Language/Haskell/Liquid/Prelude.hs)
+
+\begin{code}
+{-@ truncate'' :: Int -> Int -> Int @-}
+truncate'' i max  
+  | i' <= max' = i
+  | otherwise  = liquidAssert (i' /= 0) $ max' * (i `divide` i')
+    where i'   = abz i
+          max' = abz max 
+\end{code}
+
+In fact, LiquidHaskell comes equipped with suitable refinements for
+standard functions and it is easy to add refinements as we shall
+demonstrate in subsequent articles.
+
+Conclusion
+----------
+
+This concludes our quick introduction to Refinement Types and
+LiquidHaskell. Hopefully you have some sense of how to 
+
+1. **Specify** fine-grained properties of values by decorating their
+   types with logical predicates.
+2. **Encode** assertions, preconditions, and postconditions with suitable
+   function types.
+3. **Verify** semantic properties of code by using automatic logic engines 
+   (SMT solvers) to track and establish the key relationships between 
+   program values.
+
+
diff --git a/docs/blog/2013-01-27-refinements101-reax.lhs b/docs/blog/2013-01-27-refinements101-reax.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-01-27-refinements101-reax.lhs
@@ -0,0 +1,262 @@
+---
+layout: post
+title: "Refinements 101 (contd.)" 
+date: 2013-01-27 16:12
+author: Ranjit Jhala
+published: true 
+comments: true
+external-url:
+categories: basic
+demo: refinements101reax.hs
+---
+
+Hopefully, the [previous][ref101] article gave you a basic idea about what
+refinement types look like. Several folks had interesting questions, that
+are worth discussing in a separate post, since they throw a lot of light 
+on the strengths (or weaknesses, depending on your point of view!) of
+LiquidHaskell.
+
+
+
+\begin{code}
+module Refinements101Reax where
+\end{code}
+
+How to relate outputs and inputs 
+--------------------------------
+
+Recall the function `divide`
+
+\begin{code}
+{-@ divide :: Int -> {v: Int | v /= 0 } -> Int @-}
+divide     :: Int -> Int -> Int
+divide n 0 = error "divide by zero"
+divide n d = n `div` d
+\end{code}
+
+and `abz` was the absolute value function
+
+\begin{code}
+abz               :: Int -> Int
+abz n | 0 < n     = n
+      | otherwise = 0 - n
+\end{code}
+
+[nanothief](http://www.reddit.com/user/nanothief) [remarked][qreddit101]
+that LiquidHaskell was unable to verify the safety of the following call to
+`divide` (i.e. was unable to show that `x` was non-zero at the callsite).
+
+\begin{code}
+{-@ f :: Int -> Int @-}
+f x | abz x == 0 = 3
+    | otherwise  = 3 `divide` x
+\end{code}
+
+Nanothief correctly argues that the code is clearly safe as *"`abz x == 0` being false implies `x /= 0`"*. 
+Indeed, the code *is safe*, however, the reason that LiquidHaskell
+rejected it has nothing to do with its inability
+to  *"track the constraints of values based on tests using new values derived from that value"* as Nanothief surmised,
+but instead, because LiquidHaskell supports **modular verification** 
+where the *only* thing known about `abz` at a *use site* is 
+whatever is specified in its *type*. 
+
+\begin{code}Concretely speaking, the type 
+abz :: Int -> {v: Int | 0 <= v }
+\end{code}
+
+is too anemic to verify `f` above, as it tells us nothing 
+about the *relationship* between the output and input -- looking at it,
+we have now way of telling that when the *output* (of `abz`) is 
+non-zero, the *input*  must also have been non-zero.
+
+\begin{code}Instead, we can write a *stronger* type which does capture this information, for example
+abz :: x:Int -> {v:Int | v = (if (x > 0) then x else (0 - x))}
+\end{code}
+
+\begin{code} where 
+v = (if p then e1 else e2)
+\end{code}
+
+\begin{code} is an abbreviation for the formula 
+(p => v == e1) && ((not p) => v = e2)
+\end{code}
+
+With this specification for `abz`, LiquidHaskell is able to reason that
+when `abz x` is non-zero, `x` is also non-zero. Of course, `abz` is trivial 
+enough that we can very precisely capture its *exact* semantics in the 
+refinement type, but thats is rarely the case. 
+
+Nevertheless, even here, you could write a somewhat *weaker* specification,
+that still had enough juice to allow the verification of the `divide` call
+in `f`. In particular, we might write
+
+\begin{code}
+{-@ abz :: x:Int -> {v:Int | ((0 <= v) && ((v = 0) <=> (x = 0))) } @-}
+\end{code}
+
+which states the output is `0` *if and only if* the input is `0`.
+LiquidHaskell will happily verify that `abz` implements this specification,
+and will use it to verify the safety of `f` above.
+
+(BTW, follow the link above to *demo this code*  yourself.)
+
+How to tell a Fib
+-----------------
+
+[Chris Done](https://twitter.com/christopherdone) [asked][qblog101]
+why LiquidHaskell refused to verify the following definition of `fib`.
+
+\begin{code}
+{-@ fib :: n:Int -> { b:Int | (n >= 0 && b >= n) } @-}
+fib :: Int -> Int
+fib 0 = 0
+fib 1 = 1
+fib n = fib (n-1) + fib (n-2)
+\end{code}
+
+Indeed, the both the *specification* and the *implementation* look pretty
+legit, so what gives?  It turns out that there are *two* different reasons why. 
+
+**Reason 1: Assumptions vs. Guarantees**
+
+What we really want to say over here is that the *input* `n` 
+is non-negative. However, putting the refinement `n >= 0` in 
+the *output* constraint means that it becomes something that 
+LiquidHaskell checks that the function `fib` **guarantees** 
+(or **ensures**).
+That is, the type states that we can pass `fib` *any* value 
+`n` (including *negative* values) and yet, `fib` must return 
+values `b` such that `b >= n` *and* `n >= 0`. 
+
+The latter requirement is a rather tall order when an arbitrary `n` 
+is passed in as input. `fib` can make no such guarantees since 
+it was *given* the value `n` as a parameter. The only way `n` could 
+be non-negative was that if the caller had sent in a non-negative value. 
+Thus, we want to put the *burden of proof* on the right entity here, 
+namely the caller.
+
+To assign the burden of proof appropriately, we place the
+non-negative refinement on the *input type*
+
+\begin{code}
+{-@ fib' :: n:{v:Int | v >= 0} -> {b:Int | (n >= 0 && b >= n) } @-}
+fib' :: Int -> Int
+fib' 0 = 0
+fib' 1 = 1
+fib' n = fib (n-1) + fib (n-2)
+\end{code}
+
+where now at *calls to* `fib'` LiquidHaskell will check that the argument
+is non-negative, and furthermore, when checking `fib'` LiquidHaskell will 
+**assume** that the parameter `n` is indeed non-negative. So now the
+constraint `n >= 0` on the output is somewhat redundant, and the
+non-negative `n` guarantee holds trivially.
+
+**Reason 2: The Specification is a Fib**
+
+If you run the above in the demo, you will see that LiquidHaskell still
+doth protest loudly, and frankly, one might start getting a little
+frustrated at the stubbornness and petulance of the checker.
+
+\begin{code} However, if you stare at the implementation, you will see that it in fact, *does not* meet the specification, as
+fib' 2  == fib' 1 + fib' 0
+        == 0 + 1
+        == 1
+\end{code}
+
+LiquidHaskell is reluctant to prove things that are false. Rather than 
+anthropomorphize frivolously, lets see why it is unhappy. 
+
+\begin{code}First, recall the somewhat simplified specification 
+fib' :: n:Int -> { b:Int | (b >= n) } 
+\end{code}
+
+As we saw in the discussion about `abz`, at each recursive callsite
+the *only information* LiquidHaskell uses about the returned value, 
+is that described in the *output type* for that function call.
+
+\begin{code}Thus, LiquidHaskell reasons that the expression:
+fib' (n-1) + fib' (n-2)
+\end{code}
+
+\begin{code}has the type
+{b: Int | exists b1, b2. b  == b1 + b2 
+                      && b1 >= n-1 
+                      && b2 >= n-2     }
+\end{code}
+
+where the `b1` and `b2` denote the values returned by the 
+recursive calls --- we get the above by plugging the parameters
+`n-1` and `n-2` in for the parameter `n` in output type for `fib'`.
+
+\begin{code}The SMT solver simplifies the above to
+{b: Int | b >= 2n - 3}
+\end{code}
+
+\begin{code} Finally, to check the output guarantee is met, LiquidHaskell asks the SMT solver to prove that
+(b >= 2n - 2)  =>  (b >= n)
+\end{code}
+
+The SMT solver will refuse, of course, since the above implication is 
+*not valid* (e.g. when `n` is `2`) Thus, via SMT, LiquidHaskell proclaims
+that the function `fib'` does not implement the advertised type and hence
+marks it *unsafe*.
+
+Fixing The Code
+---------------
+
+How then, do we get Chris' specification to work out? It seems like it 
+*should* hold (except for that pesky case where `n=2`. Indeed,
+let's rig the code, so that all the base cases return `1`.
+
+\begin{code}
+{-@ fibOK :: n:Int -> {b:Int | ((b >= n) && (b >= 1))} @-}
+fibOK :: Int -> Int
+fibOK 0 = 1
+fibOK 1 = 1
+fibOK n = fibOK (n-1) + fibOK (n-2)
+\end{code}
+
+Here' we specify that not only is the output greater than the input, it is
+**also** greater than `1`. 
+
+\begin{code} Now in the recursive case, LiquidHaskell reasons that the value being output is
+{b: Int | exists b1, b2. b  == b1 + b2 
+                      && b1 >= n-1 && b1 >= 1 
+                      && b2 >= n-2 && b2 >= 1 }
+\end{code}
+
+\begin{code}which reduces to 
+{b: Int | b = 2n - 3 && n >= 2 }
+\end{code}
+
+\begin{code}which, the SMT solver is happy to verify, is indeed a subtype
+of (i.e. implies the refinement of) the specified output
+{b: Int | b >= n && b >= 1 } 
+\end{code}
+
+Conclusion
+----------
+
+There are several things to take away. 
+
+1. We need to distinguish between *assumptions* and *guarantees* 
+   when writing specifications for functions.
+
+2. For *modularity*, LiquidHaskell, like every type system, uses only
+   the (refinement) *type*  of each function at each use site, and not the 
+   function's *body*.
+
+3. Some seemingly intuitive specifications often aren't; in future work it
+   would be useful to actually [generate][mlton]  [tests][concolic] as 
+   [counterexamples][icse04] that illustrate when a specification
+   [fails][dsd].
+
+[qblog101]: /blog/2013/01/01/refinement-types-101.lhs/#comment-772807850
+[qreddit101]: http://www.reddit.com/r/haskell/comments/16w3hp/liquidhaskell_refinement_types_in_haskell_via_smt/c809160
+[ref101]:  /blog/2013/01/01/refinement-types-101.lhs/ 
+[concolic]: http://en.wikipedia.org/wiki/Concolic_testing
+[icse04]: http://goto.ucsd.edu/~rjhala/papers/generating_tests_from_counterexamples.html
+[dsd]: http://dl.acm.org/citation.cfm?doid=1348250.1348254
+[mlton]: http://www.cs.purdue.edu/homes/zhu103/pubs/vmcai13.pdf
+
diff --git a/docs/blog/2013-01-31-safely-catching-a-list-by-its-tail.lhs b/docs/blog/2013-01-31-safely-catching-a-list-by-its-tail.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-01-31-safely-catching-a-list-by-its-tail.lhs
@@ -0,0 +1,378 @@
+---
+layout: post
+title: "Safely Catching A List By Its Tail"
+date: 2013-01-31 16:12
+author: Ranjit Jhala
+published: true 
+comments: true
+external-url:
+categories: measures 
+demo: lenMapReduce.hs
+---
+
+[Previously][ref101] we [saw][ref102] some examples of how refinements
+could be used to encode invariants about basic `Int` values.  Today, let's
+see how refinements allow us specify and verify *structural invariants*
+about recursive data types like lists. In particular, we will
+learn about at a new mechanism called a `measure`, 
+use measures to describe the **length** of a list, and 
+use the resulting refinement types to obtain compile-time assurances
+that canonical list manipulating operations like `head`, `tail`, `foldl1`
+and (incomplete) pattern matches will not *blow up* at run-time.
+
+
+
+\begin{code}
+module ListLengths where
+
+import Prelude hiding (length, map, filter, head, tail, foldl1)
+import Language.Haskell.Liquid.Prelude (liquidError)
+import qualified Data.HashMap.Strict as M
+import Data.Hashable 
+\end{code}
+
+Measuring the Length of a List
+------------------------------
+
+To begin, we need some instrument by which to measure the length of a list.
+To this end, let's introduce a new mechanism called **measures** which 
+define auxiliary (or so-called **ghost**) properties of data values.
+These properties are useful for specification and verification, but
+**don't actually exist at run-time**.
+That is, measures will appear in specifications but *never* inside code.
+
+
+
+
+\begin{code} Let's reuse this mechanism, this time, providing a [definition](https://github.com/ucsd-progsys/liquidhaskell/blob/master/include/GHC/Base.spec) for the measure
+measure len :: forall a. [a] -> GHC.Types.Int
+len ([])     = 0
+len (y:ys)   = 1 + (len ys) 
+\end{code}
+
+The description of `len` above should be quite easy to follow. Underneath the 
+covers, LiquidHaskell transforms the above description into refined versions 
+of the types for the constructors `(:)` and `[]`,
+\begin{code}Something like 
+data [a] where 
+  []  :: forall a. {v: [a] | (len v) = 0 }
+  (:) :: forall a. y:a -> ys:[a] -> {v: [a] | (len v) = 1 + (len ys) } 
+\end{code}
+
+To appreciate this, note that we can now check that
+
+\begin{code}
+{-@ xs :: {v:[String] | (len v) = 1 } @-}
+xs = "dog" : []
+
+{-@ ys :: {v:[String] | (len v) = 2 } @-}
+ys = ["cat", "dog"]
+
+{-@ zs :: {v:[String] | (len v) = 3 } @-}
+zs = "hippo" : ys
+\end{code}
+
+Dually, when we *de-construct* the lists, LiquidHaskell is able to relate
+the type of the outer list with its constituents. For example,
+
+\begin{code}
+{-@ zs' :: {v:[String] | (len v) = 2 } @-}
+zs' = case zs of 
+        h : t -> t
+\end{code}
+
+Here, from the use of the `:` in the pattern, LiquidHaskell can determine
+that `(len zs) = 1 + (len t)`; by combining this fact with the nugget
+that `(len zs) = 3` LiquidHaskell concludes that `t`, and hence, `zs'`
+contains two elements.
+
+Reasoning about Lengths
+-----------------------
+
+Let's flex our new vocabulary by uttering types that describe the
+behavior of the usual list functions. 
+
+First up: a version of the [standard][ghclist] 
+`length` function, slightly simplified for exposition.
+
+\begin{code}
+{-@ length :: xs:[a] -> {v: Int | v = (len xs)} @-}
+length :: [a] -> Int
+length []     = 0
+length (x:xs) = 1 + length xs
+\end{code}
+
+**Note:** Recall that `measure` values don't actually exist at run-time.
+However, functions like `length` are useful in that they allow us to
+effectively *pull* or *materialize* the ghost values from the refinement
+world into the actual code world (since the value returned by `length` is
+logically equal to the `len` of the input list.)
+
+Similarly, we can speak and have confirmed, the types for the usual
+list-manipulators like
+
+\begin{code}
+{-@ map      :: (a -> b) -> xs:[a] -> {v:[b] | (len v) = (len xs)} @-}
+map _ []     = [] 
+map f (x:xs) = (f x) : (map f xs)
+\end{code}
+
+and
+
+\begin{code}
+{-@ filter :: (a -> Bool) -> xs:[a] -> {v:[a] | (len v) <= (len xs)} @-}
+filter _ []     = []
+filter f (x:xs) 
+  | f x         = x : filter f xs
+  | otherwise   = filter f xs
+\end{code}
+
+and, since doubtless you are wondering,
+
+\begin{code}
+{-@ append :: xs:[a] -> ys:[a] -> {v:[a] | (len v) = (len xs) + (len ys)} @-}
+append [] ys     = ys 
+append (x:xs) ys = x : append xs ys
+\end{code}
+
+We will return to the above at some later date. Right now, let's look at
+some interesting programs that LiquidHaskell can prove safe, by reasoning
+about the size of various lists.
+
+
+
+Example 1: Safely Catching A List by Its Tail (or Head) 
+-------------------------------------------------------
+
+Now, let's see how we can use these new incantations to banish, forever,
+certain irritating kinds of errors. 
+\begin{code}Recall how we always summon functions like `head` and `tail` with a degree of trepidation, unsure whether the arguments are empty, which will awaken certain beasts
+Prelude> head []
+*** Exception: Prelude.head: empty list
+\end{code}
+
+LiquidHaskell allows us to use these functions with 
+confidence and surety! First off, let's define a predicate
+alias that describes non-empty lists:
+
+\begin{code}
+{-@ predicate NonNull X = ((len X) > 0) @-}
+\end{code}
+
+Now, we can type the potentially dangerous `head` as:
+
+\begin{code}
+{-@ head   :: {v:[a] | (NonNull v)} -> a @-}
+head (x:_) = x
+head []    = liquidError "Fear not! 'twill ne'er come to pass"
+\end{code}
+
+As with the case of [divide-by-zero][ref101], LiquidHaskell deduces that
+the second equation is *dead code* since the precondition (input) type
+states that the length of the input is strictly positive, which *precludes*
+the case where the parameter is `[]`.
+
+Similarly, we can write
+
+\begin{code}
+{-@ tail :: {v:[a] | (NonNull v)} -> [a] @-}
+tail (_:xs) = xs
+tail []     = liquidError "Relaxeth! this too shall ne'er be"
+\end{code}
+
+Once again, LiquidHaskell will use the precondition to verify that the 
+`liquidError` is never invoked. 
+
+Let's use the above to write a function that eliminates stuttering, that
+is which converts `"ssstringssss liiiiiike thisss"` to `"strings like this"`.
+
+\begin{code}
+{-@ eliminateStutter :: (Eq a) => [a] -> [a] @-}
+eliminateStutter xs = map head $ groupEq xs 
+\end{code}
+
+The heavy lifting is done by `groupEq`
+
+\begin{code}
+groupEq []     = []
+groupEq (x:xs) = (x:ys) : groupEq zs
+                 where (ys,zs) = span (x ==) xs
+\end{code}
+
+which gathers consecutive equal elements in the list into a single list.
+By using the fact that *each element* in the output returned by 
+`groupEq` is in fact of the form `x:ys`, LiquidHaskell infers that
+`groupEq` returns a *list of non-empty lists*. 
+(Hover over the `groupEq` identifier in the code above to see this.)
+Next, by automatically instantiating the type parameter for the `map` 
+in `eliminateStutter` to `(len v) > 0` LiquidHaskell deduces `head` 
+is only called on non-empty lists, thereby verifying the safety of 
+`eliminateStutter`. (Hover your mouse over `map` above to see the
+instantiated type for it!)
+
+Example 2: Risers 
+-----------------
+
+The above examples of `head` and `tail` are simple, but non-empty lists pop
+up in many places, and it is rather convenient to have the type system
+track non-emptiness without having to make up special types. Let's look at a
+more interesting example, popularized by [Neil Mitchell][risersMitchell]
+which is a key step in an efficient sorting procedure, which we may return
+to in the future when we discuss sorting algorithms.
+
+\begin{code}
+risers           :: (Ord a) => [a] -> [[a]]
+risers []        = []
+risers [x]       = [[x]]
+risers (x:y:etc) = if x <= y then (x:s):ss else [x]:(s:ss)
+    where 
+      (s, ss)    = safeSplit $ risers (y:etc)
+\end{code}
+
+The bit that should cause some worry is `safeSplit` which 
+simply returns the `head` and `tail` of its input, if they
+exist, and otherwise, crashes and burns
+
+\begin{code}
+safeSplit (x:xs)  = (x, xs)
+safeSplit _       = liquidError "don't worry, be happy"
+\end{code}
+
+How can we verify that `safeSplit` *will not crash* ?
+
+The matter is complicated by the fact that since `risers` 
+*does* sometimes return an empty list, we cannot blithely 
+specify that its output type has a `NonNull` refinement.
+
+Once again, logic rides to our rescue!
+
+The crucial property upon which the safety of `risers` rests
+is that when the input list is non-empty, the output list 
+returned by risers is *also* non-empty. It is quite easy to clue 
+LiquidHaskell in on this, namely through a type specification:
+
+\begin{code}
+{-@ risers :: (Ord a) 
+           => zs:[a] 
+           -> {v: [[a]] | ((NonNull zs) => (NonNull v)) } @-} 
+\end{code}
+
+Note how we relate the output's non-emptiness to the input's
+non-emptiness,through the (dependent) refinement type. With this 
+specification in place, LiquidHaskell is pleased to verify `risers` 
+(i.e. the call to `safeSplit`).
+
+Example 3: MapReduce 
+--------------------
+
+Here's a longer example that illustrates this: a toy *map-reduce* implementation.
+
+First, let's write a function `keyMap` that expands a list of inputs into a 
+list of key-value pairs:
+
+\begin{code}
+keyMap :: (a -> [(k, v)]) -> [a] -> [(k, v)]
+keyMap f xs = concatMap f xs
+\end{code}
+
+Next, let's write a function `group` that gathers the key-value pairs into a
+`Map` from *keys* to the lists of values with that same key.
+
+\begin{code}
+group kvs = foldr (\(k, v) m -> inserts k v m) M.empty kvs 
+\end{code}
+
+The function `inserts` simply adds the new value `v` to the list of 
+previously known values `lookupDefault [] k m` for the key `k`.
+
+\begin{code}
+inserts k v m = M.insert k (v : vs) m 
+  where vs    = M.lookupDefault [] k m
+\end{code}
+
+Finally, a function that *reduces* the list of values for a given
+key in the table to a single value:
+
+\begin{code}
+reduce    :: (v -> v -> v) -> M.HashMap k [v] -> M.HashMap k v
+reduce op = M.map (foldl1 op)
+\end{code}
+
+where `foldl1` is a [left-fold over *non-empty* lists][foldl1]
+
+\begin{code}
+{-@ foldl1      :: (a -> a -> a) -> {v:[a] | (NonNull v)} -> a @-}
+foldl1 f (x:xs) =  foldl f x xs
+foldl1 _ []     =  liquidError "will. never. happen."
+\end{code}
+
+We can put the whole thing together to write a (*very*) simple *Map-Reduce* library
+
+\begin{code}
+mapReduce   :: (Eq k, Hashable k) 
+            => (a -> [(k, v)])    -- ^ key-mapper
+            -> (v -> v -> v)      -- ^ reduction operator
+            -> [a]                -- ^ inputs
+            -> [(k, v)]           -- ^ output key-values
+
+mapReduce f op  = M.toList 
+                . reduce op 
+                . group 
+                . keyMap f
+\end{code}
+
+Now, if we want to compute the frequency of `Char` in a given list of words, we can write:
+
+\begin{code}
+{-@ charFrequency :: [String] -> [(Char, Int)] @-}
+charFrequency     :: [String] -> [(Char, Int)]
+charFrequency     = mapReduce wordChars (+)
+  where wordChars = map (\c -> (c, 1)) 
+\end{code}
+
+You can take it out for a spin like so:
+
+\begin{code}
+f0 = charFrequency [ "the", "quick" , "brown"
+                   , "fox", "jumped", "over"
+                   , "the", "lazy"  , "cow"   ]
+\end{code}
+
+**Look Ma! No Types:** LiquidHaskell will gobble the whole thing up, and
+verify that none of the undesirable `liquidError` calls are triggered. By
+the way, notice that we didn't write down any types for `mapReduce` and
+friends.  The main invariant, from which safety follows is that the `Map`
+returned by the `group` function binds each key to a *non-empty* list of
+values.  LiquidHaskell deduces this invariant by inferring suitable types
+for `group`, `inserts`, `foldl1` and `reduce`, thereby relieving us of that
+tedium. In short, by riding on the broad and high shoulders of SMT and
+abstract interpretation, LiquidHaskell makes a little typing go a long way. 
+
+
+Conclusions
+-----------
+
+Well folks, thats all for now. I trust this article gave you a sense of
+
+1. How we can describe certain *structural properties* of data types, 
+   such as the length of a list, 
+
+2. How we might use refinements over these properties to describe key
+   invariants and establish, at compile-time, the safety of operations that
+   might blow up on unexpected values at run-time, and perhaps, most
+   importantly,
+
+3. How we can achieve the above, whilst just working with good old lists, 
+   without having to [make up new types][risersApple] (which have the 
+   unfortunate effect of cluttering programs with their attendant new 
+   functions) in order to enforce special invariants.
+
+
+[vecbounds]:  /blog/2013/01/05/bounding-vectors.lhs/ 
+[ghclist]:    https://github.com/ucsd-progsys/liquidhaskell/blob/master/include/GHC/List.lhs#L125
+[foldl1]:     http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/Data-List.html#foldl1
+[risersMitchell]: http://neilmitchell.blogspot.com/2008/03/sorting-at-speed.html
+[risersApple]: http://blog.jbapple.com/2008/01/extra-type-safety-using-polymorphic.html
+[ref101]:  /blog/2013/01/01/refinement-types-101.lhs/ 
+[ref102]:  /blog/2013/01/27/refinements101-reax.lhs/ 
+
diff --git a/docs/blog/2013-02-16-kmeans-clustering-I.lhs b/docs/blog/2013-02-16-kmeans-clustering-I.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-02-16-kmeans-clustering-I.lhs
@@ -0,0 +1,335 @@
+---
+layout: post
+title: "KMeans Clustering I"
+date: 2013-02-16 16:12
+author: Ranjit Jhala
+published: true
+comments: true
+external-url:
+categories: basic measures
+demo: KMeansHelper.hs
+---
+
+[Last time][safeList] we introduced a new specification mechanism called a
+*measure* and demonstrated how to use it to encode the *length* of a list.
+We saw how measures could be used to verify that functions like `head` and
+`tail` were only called with non-empty lists (whose length was strictly
+positive). As several folks pointed out, once LiquidHaskell can reason about
+lengths, it can do a lot more than just analyze non-emptiness.
+
+Indeed!
+
+Over the next *two* posts, lets see how one might implement a Kmeans
+algorithm that clusters `n`-dimensional points groups, and how LiquidHaskell
+can help us write and enforce various dimensionality invariants along the way.
+
+
+
+
+
+
+\begin{code}
+module KMeansHelper where
+
+import Prelude                          hiding  (zipWith)
+import Data.List                                (span)
+import Language.Haskell.Liquid.Prelude          (liquidError)
+\end{code}
+
+Rather than reinvent the wheel, we will modify an existing implementation
+of K-Means, [available on hackage][URL-kmeans]. This may not be the
+most efficient implementation, but its a nice introduction to the algorithm,
+and the general invariants will hold for more sophisticated implementations.
+
+We have broken this entry into two convenient, bite-sized chunks:
+
++ **Part I**  Introduces the basic types and list operations needed by KMeans,
+
++ **Part II** Describes how the operations are used in the KMeans implementation.
+
+The Game: Clustering Points
+---------------------------
+
+The goal of [K-Means clustering](http://en.wikipedia.org/wiki/K-means_clustering)
+is the following. Given
+
+- **Input** : A set of *points* represented by *n-dimensional points*
+  in *Euclidian* space, return
+
+- **Output** : A partitioning of the points, into K clusters, in a manner that
+  minimizes sum of distances between each point and its cluster center.
+
+
+The Players: Types
+------------------
+
+Lets make matters concrete by creating types for the different elements of the algorithm.
+
+**1. Fixed-Length Lists**  We will represent n-dimensional points using
+good old Haskell lists, refined with a predicate that describes the
+dimensionality (i.e. length.) To simplify matters, lets package this
+into a *type alias* that denotes lists of a given length `N`.
+
+\begin{code}
+{-@ type List a N = {v : [a] | (len v) = N} @-}
+\end{code}
+
+**2. Points** Next, we can represent an `N`-dimensional point as list of `Double` of length `N`,
+
+\begin{code}
+{-@ type Point N = List Double N @-}
+\end{code}
+
+**3. Clusters** A cluster is a **non-empty** list of points,
+
+\begin{code}
+{-@ type NonEmptyList a = {v : [a] | (len v) > 0} @-}
+\end{code}
+
+**4. Clustering** And finally, a clustering is a list of (non-empty) clusters.
+
+\begin{code}
+{-@ type Clustering a  = [(NonEmptyList a)] @-}
+\end{code}
+
+**Notation:** When defining refinement type aliases, we use uppercase variables like `N`
+to distinguish value- parameters from the lowercase type parameters like `a`.
+
+
+**Aside:** By the way, if you are familiar with the *index-style* length
+encoding e.g. as found in [DML][dml] or [Agda][agdavec], then its worth
+noting that despite appearances, our `List` and `Point` definitions are
+*not* indexed. We're just using the indices to define abbreviations for the
+refinement predicates, and we have deliberately chosen the predicates to
+facilitate SMT based checking and inference.
+
+Basic Operations on Points and Clusters
+=======================================
+
+Ok, with the types firmly in hand, let us go forth and develop the KMeans
+clustering implementation. We will use a variety of small helper functions
+(of the kind found in `Data.List`.) Lets get started by looking at them
+through our newly *refined* eyes.
+
+Grouping
+--------
+
+The first such function is [groupBy][URL-groupBy]. We can
+refine its type so that instead of just producing a `[[a]]`
+we know that it produces a `Clustering a` which is a list
+of *non-empty* lists.
+
+\begin{code}
+{-@ groupBy       ::(a -> a -> Bool) -> [a] -> (Clustering a) @-}
+groupBy _  []     = []
+groupBy eq (x:xs) = (x:ys) : groupBy eq zs
+  where (ys,zs)   = span (eq x) xs
+\end{code}
+
+Intuitively, its pretty easy to see how LiquidHaskell verifies the refined
+specification:
+
+- Each element of the output list is of the form `x:ys`
+- For any list `ys` the length is non-negative, i.e. `(len ys) >= 0`
+- The `len` of `x:ys` is `1 + (len ys)`, that is, strictly positive.
+
+Partitioning
+------------
+
+Next, lets look the function
+
+\begin{code}
+{-@ partition :: size:PosInt -> [a] -> (Clustering a) @-}
+{-@ type PosInt = {v: Int | v > 0 } @-}
+\end{code}
+
+which is given a *strictly positive* integer argument,
+a list of `a` values, and returns a `Clustering a`,
+that is, a list of non-empty lists. (Each inner list has a length
+that is less than `size`, but we shall elide this for simplicity.)
+
+The function is implemented in a straightforward manner, using the
+library functions `take` and `drop`
+
+\begin{code}
+partition size []       = []
+partition size ys@(_:_) = zs : partition size zs'
+  where
+    zs                  = take size ys
+    zs'                 = drop size ys
+\end{code}
+
+To verify that a valid `Clustering` is produced, LiquidHaskell needs only
+verify that the list `zs` above is non-empty, by suitably connecting the
+properties of the inputs `size` and `ys` with the output.
+
+\begin{code} We have [verified elsewhere][URL-take] that
+take :: n:{v: Int | v >= 0 }
+     -> xs:[a]
+     -> {v:[a] | (len v) = (if ((len xs) < n) then (len xs) else n) }
+\end{code}
+
+In other words, the output list's length is the *smaller of* the input
+list's length and `n`.  Thus, since both `size` and the `(len ys)` are
+greater than `1`, LiquidHaskell deduces that the list returned by `take
+size ys` has a length greater than `1`, i.e., is non-empty.
+
+Zipping
+-------
+
+To compute the *Euclidean distance* between two points, we will use
+the `zipWith` function. We must make sure that it is invoked on points
+with the same number of dimensions, so we write
+
+\begin{code}
+{-@ zipWith :: (a -> b -> c)
+            -> xs:[a] -> (List b (len xs)) -> (List c (len xs)) @-}
+zipWith f (a:as) (b:bs) = f a b : zipWith f as bs
+zipWith _ [] []         = []
+\end{code}
+
+The type stipulates that the second input list and the output have
+the same length as the first input. Furthermore, it rules out the
+case where one list is empty and the other is not, as in that case
+the former's length is zero while the latter's is not.
+
+Transposing
+-----------
+
+The last basic operation that we will require is a means to
+*transpose* a `Matrix`, which itself is just a list of lists:
+
+\begin{code}
+{-@ type Matrix a Rows Cols = (List (List a Cols) Rows) @-}
+\end{code}
+
+The `transpose` operation flips the rows and columns. I confess that I
+can never really understand matrices without concrete examples,
+and even then, barely.
+
+\begin{code} So, lets say we have a *matrix*
+m1  :: Matrix Int 4 2
+m1  =  [ [1, 2]
+       , [3, 4]
+       , [5, 6]
+       , [7, 8] ]
+\end{code}
+
+\begin{code} then the matrix `m2 = transpose 2 3 m1` should be
+m2 :: Matrix Int 2 4
+m2  =  [ [1, 3, 5, 7]
+       , [2, 4, 6, 8] ]
+\end{code}
+
+We will use a `Matrix a m n` to represent a *single cluster* of `m` points
+each of which has `n` dimensions. We will transpose the matrix to make it
+easy to *sum* and *average* the points along *each* dimension, in order to
+compute the *center* of the cluster.
+
+As you can work out from the above, the code for `transpose` is quite
+straightforward: each *output row* is simply the list of `head`s of
+the *input rows*:
+
+\begin{code}
+transpose       :: Int -> Int -> [[a]] -> [[a]]
+
+transpose 0 _ _ = []
+
+transpose c r ((col00 : col01s) : row1s)
+  = row0' : row1s'
+    where
+      row0'  = col00  : [ col0  | (col0 : _)  <- row1s ]
+      rest   = col01s : [ col1s | (_ : col1s) <- row1s ]
+      row1s' = transpose (c-1) r rest
+\end{code}
+
+LiquidHaskell verifies that
+
+\begin{code}
+{-@ transpose :: c:Int -> r:PosInt -> Matrix a r c -> Matrix a c r @-}
+\end{code}
+
+Try to work it out for yourself on pencil and paper.
+
+If you like you can get a hint by seeing how LiquidHaskell figures it out.
+Lets work *backwards*.
+
+\begin{code} LiquidHaskell verifies the output type by inferring that
+row0'        :: (List a r)
+row1s'       :: List (List a r) (c - 1) -- i.e. Matrix a (c - 1) r
+\end{code}
+
+\begin{code} and so, by simply using the *measure-refined* type for `:`
+(:)          :: x:a -> xs:[a] -> { v : [a] | (len v) = 1 + (len xs) }
+\end{code}
+
+\begin{code} LiquidHaskell deduces that
+row0 : rows' :: List (List a r) c
+\end{code}
+
+\begin{code} That is,
+row0 : rows' :: Matrix a c r
+\end{code}
+
+Excellent! Now, lets work backwards. How does it infer the types of `row0'` and `row1s'`?
+
+The first case is easy: `row0'` is just the list of *heads* of each row, hence a `List a r`.
+
+\begin{code} Now, lets look at `row1s'`. Notice that `row1s` is the matrix of all *except* the first row of the input Matrix, and so
+row1s        :: Matrix a (r-1) c
+\end{code}
+
+\begin{code} and so, as
+col01s       :: List a (c-1)
+col1s        :: List a (c-1)
+\end{code}
+
+\begin{code} LiquidHaskell deduces that since `rest` is the concatenation of `r-1` tails from `row1s`
+rest         = col01s : [ col1s | (_ : col1s) <- row1s ]
+\end{code}
+
+\begin{code} the type of `rest` is
+rest         :: List (List a (c - 1)) r
+\end{code}
+
+\begin{code} which is just
+rest         :: Matrix a r (c-1)
+\end{code}
+
+Now, LiquidHaskell deduces `row1s' :: Matrix a (c-1) r` by inductively
+plugging in the output type of the recursive call, thereby checking the
+function's signature.
+
+
+*Whew!* That was a fair bit of work, wasn't it!
+
+Happily, we didn't have to do *any* of it. Instead, using the SMT solver,
+LiquidHaskell ploughs through calculations like that and guarantees to us
+that `transpose` indeed flips the dimensions of the inner and outer lists.
+
+**Aside: Comprehensions vs. Map** Incidentally, the code above is essentially
+that of `transpose` [from the Prelude][URL-transpose] with some extra
+local variables for exposition. You could instead use a `map head` and `map tail`
+and I encourage you to go ahead and [see for yourself.][demo]
+
+Intermission
+------------
+
+Time for a break -- [go see a cat video!][maru] -- or skip it, stretch your
+legs, and return post-haste for the [next installment][kmeansII], in which
+we will use the types and functions described above, to develop the clustering
+algorithm.
+
+[safeList]:      /blog/2013/01/31/safely-catching-a-list-by-its-tail.lhs/
+[kmeansI]:       /blog/2013/02/16/kmeans-clustering-I.lhs/
+[kmeansII]:      /blog/2013/02/17/kmeans-clustering-II.lhs/
+[URL-take]:      https://github.com/ucsd-progsys/liquidhaskell/blob/master/include/GHC/List.lhs#L334
+[URL-groupBy]:   http://hackage.haskell.org/packages/archive/base/latest/doc/html/Data-List.html#v:groupBy
+[URL-transpose]: http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/Data-List.html#transpose
+[maru]:          http://www.youtube.com/watch?v=8uDuls5TyNE
+[demo]:          http://goto.ucsd.edu/~rjhala/liquid/haskell/demo/#?demo=KMeansHelper.hs
+[URL-kmeans]:    http://hackage.haskell.org/package/kmeans
+[dml]:           http://www.cs.bu.edu/~hwxi/DML/DML.html
+[agdavec]:       http://code.haskell.org/Agda/examples/Vec.agda
+
diff --git a/docs/blog/2013-02-17-kmeans-clustering-II.lhs b/docs/blog/2013-02-17-kmeans-clustering-II.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-02-17-kmeans-clustering-II.lhs
@@ -0,0 +1,436 @@
+---
+layout: post
+title: "KMeans Clustering II"
+date: 2013-02-17 16:12
+author: Ranjit Jhala
+published: true
+comments: true
+external-url:
+categories: basic measures
+demo: KMeans.hs
+---
+
+**The story so far:** [Previously][kmeansI] we saw
+
+- how to encode `n`-dimensional points using plain old Haskell lists,
+- how to encode a matrix with `r` rows and `c` columns as a list of lists,
+- some basic operations on points and matrices via list-manipulating functions
+
+More importantly, we saw how easy it was to encode dimensionality with refinements over
+the `len` measure, thereby allowing LiquidHaskell to precisely track the dimensions across
+the various operations.
+
+Next, lets use the basic types and operations to develop the actual *KMeans clustering*
+algorithm, and, along the way, see how LiquidHaskell lets us write precise module
+contracts which will ward against various unpleasant *lumpenexceptions*.
+
+
+
+\begin{code}
+{-# LANGUAGE ScopedTypeVariables, TypeSynonymInstances, FlexibleInstances #-}
+
+module KMeans (kmeans, kmeansGen) where
+
+import KMeansHelper
+import Prelude              hiding      (zipWith)
+import Data.List                        (sort, span, minimumBy)
+import Data.Function                    (on)
+import Data.Ord                         (comparing)
+import Language.Haskell.Liquid.Prelude  (liquidAssert, liquidError)
+
+instance Eq (WrapType [Double] a) where
+   (==) = (==) `on` getVect
+
+instance Ord (WrapType [Double] a) where
+    compare = comparing getVect
+\end{code}
+
+Recall that we are using a modified version of an [existing KMeans implementation][URL-kmeans].
+While not the swiftest implementation, it serves as a nice introduction to the algorithm,
+and the general invariants carry over to more sophisticated implementations.
+
+A Quick Recap
+-------------
+
+Before embarking on the journey, lets remind ourselves of our destination:
+the goal of [K-Means clustering](http://en.wikipedia.org/wiki/K-means_clustering) is
+
+- **Take as Input** : A set of *points* represented by *n-dimensional points* in *Euclidian* space
+
+- **Return as Ouptut** : A partitioning of the points, into upto K clusters, in a manner that
+  minimizes the sum of distances between each point and its cluster center.
+
+Last time, we introduced a variety of refinement type aliases for Haskell lists
+
+\begin{code} **Fixed Length Lists**
+type List a N = {v : [a] | (len v) = N}
+\end{code}
+
+\begin{code} **Non-empty Lists**
+type NonEmptyList a = {v : [a] | (len v) > 0}
+\end{code}
+
+\begin{code} **N-Dimensional Points**
+type Point N = List Double N
+\end{code}
+
+\begin{code} **Matrices**
+type Matrix a Rows Cols = List (List a Cols) Rows
+\end{code}
+
+\begin{code} We also saw several basic list operations
+groupBy   :: (a -> a -> Bool) -> [a] -> (Clustering a)
+partition :: PosInt -> [a] -> (Clustering a)
+zipWith   :: (a -> b -> c) -> xs:[a] -> (List b (len xs)) -> (List c (len xs))
+transpose :: c:Int -> r:PosInt -> Matrix a r c -> Matrix a c r
+\end{code}
+
+whose types will prove essential in order to verify the invariants of the
+clustering algorithm. You might open the [previous episode][kmeansI] in a
+separate tab to keep those functions handy, but fear not, we will refresh
+our memory about them when we get around to using them below.
+
+Generalized Points
+------------------
+
+To be more flexible, we will support *arbitrary* points as long as they can
+be **projected** to Euclidian space. In addition to supporting, say, an
+image or a [cat video][maru] as a point, this will allow us to *weight*
+different dimensions to different degrees.
+
+We represent generalized points with a record
+
+\begin{code}
+data WrapType b a = WrapType {getVect :: b, getVal :: a}
+\end{code}
+
+and we can define an alias that captures the dimensionality of the point
+
+\begin{code}
+{-@ type GenPoint a N  = WrapType (Point N) a @-}
+\end{code}
+
+That is, `GenPoint a N` denotes a general `a` value that has an
+`N`-dimensional projection into Euclidean space.
+
+Algorithm: Iterative Clustering
+-------------------------------
+
+Terrific, now that all the pieces are in place lets look at the KMeans
+algorithm. We have implemented a function `kmeans'`, which takes as input a
+dimension `n`, the maximum number of clusters `k` (which must be positive),
+a list of *generalized points* of dimension `n`, and returns a `Clustering`
+(i.e. a list of *non-empty lists*) of the generalized points.
+
+So much verbiage -- a type is worth a thousand comments!
+
+\begin{code}
+{-@ kmeans' :: n:Int
+            -> k:PosInt
+            -> points:[(GenPoint a n)]
+            -> (Clustering (GenPoint a n)) @-}
+\end{code}
+
+There! Crisp and to the point. Sorry. Anyhoo, the function implements the
+above type.
+
+\begin{code}
+kmeans' n k points    = fixpoint (refineCluster n) initialClustering
+  where
+    initialClustering = partition clusterSize points
+    clusterSize       = max 1 ((length points + k - 1) `div` k)
+
+    fixpoint          :: (Eq a) => (a -> a) -> a -> a
+    fixpoint f x      = if (f x) == x then x else fixpoint f (f x)
+\end{code}
+
+That is, `kmeans'` creates an `initialClustering` by
+`partition`-ing the `points` into chunks with `clusterSize` elements.
+Then, it invokes `fixpoint` to *iteratively refine* the initial
+clustering  with `refineCluster` until it converges to a stable
+clustering that cannot be improved upon. This stable clustering
+is returned as the output.
+
+LiquidHaskell verifies that `kmeans'` adheres to the given signature in two steps.
+
+**1. Initial Clustering**
+
+\begin{code} First, LiquidHaskell determines from
+max       :: (Ord a) => x:a -> y:a -> {v: a | (v >= x) && ( v >= y) }
+\end{code}
+
+\begin{code} that `clusterSize` is strictly positive, and hence, from
+partition :: size:PosInt -> [a] -> (Clustering a)
+\end{code}
+
+which we saw [last time][kmeansI], that `initialClustering` is indeed
+a valid `Clustering` of `(GenPoint a n)`.
+
+**2. Fixpoint**
+
+Next, LiquidHaskell infers that at the call `fixpoint (refineCluster n)
+...`, that the type parameter `a` of `fixpoint` can be *instantiated* with
+`Clustering (GenPoint a n)`.  This is because `initialClustering` is a
+valid clustering, as we saw above, and because `refineCluster` takes -- and
+returns -- valid `n`-dimensional clusterings, as we shall see below.
+Consequently, the value returned by `kmeans'` is also `Clustering` of
+`GenPoint a n` as required.
+
+Refining A Clustering
+---------------------
+
+Thus, the real work in KMeans happens inside `refineCluster`, which takes a
+clustering and improves it, like so:
+
+\begin{code}
+refineCluster n clusters = clusters'
+  where
+    -- 1. Compute cluster centers
+    centers        = map (clusterCenter n) clusters
+
+    -- 2. Map points to their nearest center
+    points         = concat clusters
+    centeredPoints = sort [(nearestCenter n p centers, p) | p <- points]
+
+    -- 3. Group points by nearest center to get new clusters
+    centeredGroups = groupBy ((==) `on` fst) centeredPoints
+    clusters'      = map (map snd) centeredGroups
+\end{code}
+
+The behavior of `refineCluster` is pithily captured by its type
+
+\begin{code}
+{-@ refineCluster :: n:Int
+                  -> Clustering (GenPoint a n)
+                  -> Clustering (GenPoint a n) @-}
+\end{code}
+
+The refined clustering is computed in three steps.
+
+1. First, we compute the `centers :: [(Point n)]` of the current `clusters`.
+   This is achieved by using `clusterCenter`, which maps a list of generalized
+   `n`-dimensional points to a *single* `n` dimensional point (i.e. `Point n`).
+
+2. Next, we pair each point `p` in the list of all `points` with its `nearestCenter`.
+
+3. Finally, the pairs in the list of `centeredPoints` are grouped by the
+   center, i.e. the first element of the tuple. The resulting groups are
+   projected back to the original generalized points yielding the new
+   clustering.
+
+\begin{code} The type of the output follows directly from
+groupBy :: (a -> a -> Bool) -> [a] -> (Clustering a)
+\end{code}
+
+from [last time][kmeansI]. At the call site above, LiquidHaskell infers that
+`a` can be instantiated with `((Point n), (GenPoint a n))` thereby establishing
+that, after *projecting away* the first element, the output is a list of
+non-empty lists of generalized `n`-dimensional points.
+
+That leaves us with the two crucial bits of the algorithm: `clusterCenter`
+and `nearestCenter`.
+
+Computing the Center of a Cluster
+---------------------------------
+
+The center of an `n`-dimensional cluster is simply an `n`-dimensional point
+whose value in each dimension is equal to the *average* value of that
+dimension across all the points in the cluster.
+
+\begin{code} For example, consider a cluster of 2-dimensional points,
+exampleCluster = [ [0,  0]
+                 , [1, 10]
+                 , [2, 20]
+                 , [4, 40]
+                 , [5, 50] ]
+\end{code}
+
+\begin{code} The center of the cluster is
+exampleCenter = [ (0 + 1  + 2  + 4  + 5 ) / 5
+                , (0 + 10 + 20 + 40 + 50) / 5 ]
+\end{code}
+
+\begin{code} which is just
+exampleCenter = [ 3, 30 ]
+\end{code}
+
+Thus, we can compute a `clusterCenter` via the following procedure
+
+\begin{code}
+clusterCenter n xs = map average xs'
+  where
+    numPoints      = length xs
+    xs'            = transpose n numPoints (map getVect xs)
+
+    average        :: [Double] -> Double
+    average        = (`safeDiv` numPoints) . sum
+\end{code}
+
+First, we `transpose` the matrix of points in the cluster.
+Suppose that `xs` is the `exampleCluster` from above
+(and so `n` is `2` and `numPoints` is `5`.)
+
+\begin{code} In this scenario, `xs'` is
+xs' = [ [0,  1,  2,  4,  5]
+      , [0, 10, 20, 40, 50] ]
+\end{code}
+
+and so `map average xs'` evaluates to `exampleCenter` from above.
+
+We have ensured that the division in the average does not lead to
+any nasty surprises via a *safe division* function whose precondition
+checks that the denominator is non-zero, [as illustrated here][ref101].
+
+\begin{code}
+{- safeDiv   :: (Fractional a) => a -> {v:Int | v != 0} -> a -}
+safeDiv     :: (Fractional a) => a -> Int -> a
+safeDiv n 0 = liquidError "divide by zero"
+safeDiv n d = n / (fromIntegral d)
+\end{code}
+
+LiquidHaskell verifies that the divide-by-zero never occurs, and furthermore,
+that `clusterCenter` indeed computes an `n`-dimensional center by inferring that
+
+\begin{code}
+{-@ clusterCenter :: n:Int -> NonEmptyList (GenPoint a n) -> Point n @-}
+\end{code}
+
+LiquidHaskell deduces that the *input* list of points `xs` is non-empty
+from the fact that `clusterCenter` is only invoked on the elements of a
+`Clustering` which comprise only non-empty lists. Since `xs` is non-empty,
+i.e. `(len xs) > 0`, LiquidHaskell infers that `numPoints` is positive
+(hover over `length` to understand why), and hence, LiquidHaskell is
+satisfied that the call to `safeDiv` will always proceed without any
+incident.
+
+\begin{code} To establish the *output* type `Point n` LiquidHaskell leans on the fact that
+transpose :: n:Int -> m:PosInt -> Matrix a m n -> Matrix a n m
+\end{code}
+
+to deduce that `xs'` is of type `Matrix Double n numPoints`, that is to
+say, a list of length `n` containing lists of length `numPoints`. Since
+`map` preserves the length, the value `map average xs'` is also a list
+of length `n`, i.e. `Point n`.
+
+
+Finding the Nearest Center
+--------------------------
+
+The last piece of the puzzle is `nearestCenter` which maps each
+(generalized) point to the center that it is nearest. The code is
+pretty self-explanatory:
+
+\begin{code}
+nearestCenter     :: Int -> WrapType [Double] a -> [[Double]] -> [Double]
+nearestCenter n x = minKey . map (\c -> (c, distance c (getVect x)))
+\end{code}
+
+We `map` the centers to a tuple of center `c` and the `distance` between
+`x` and `c`, and then we select the tuple with the smallest distance
+
+\begin{code}
+minKey  :: (Ord v) => [(k, v)] -> k
+minKey  = fst . minimumBy (\x y -> compare (snd x) (snd y))
+\end{code}
+
+The interesting bit is that the `distance` function uses `zipWith` to
+ensure that the dimensionality of the center and the point match up.
+
+\begin{code}
+distance     :: [Double] -> [Double] -> Double
+distance a b = sqrt . sum $ zipWith (\v1 v2 -> (v1 - v2) ^ 2) a b
+\end{code}
+
+LiquidHaskell verifies `distance` by inferring that
+
+\begin{code}
+{-@ nearestCenter :: n:Int -> (GenPoint a n) -> [(Point n)] -> (Point n) @-}
+\end{code}
+
+First, LiquidHaskell deduces that each center in `cs` is indeed `n`-dimensional, which
+follows from the output type of `clusterCenter`. Since `x` is a `(GenPoint a n)`
+LiquidHaskell infers that both `c` and `getVect x` are of an equal length `n`.
+
+\begin{code} Consequently, the call to
+zipWith :: (a -> b -> c) -> xs:[a] -> (List b (len xs)) -> (List c (len xs))
+\end{code}
+
+[discussed last time][kmeansI] is determined to be safe.
+
+Finally, the value returned is just one of the input centers and so is a `(Point n)`.
+
+
+Putting It All Together: Top-Level API
+--------------------------------------
+
+We can bundle the algorithm into two top-level API functions.
+
+First, a version that clusters *generalized* points. In this case, we
+require a function that can `project` an `a` value to an `n`-dimensional
+point. This function just wraps each `a`, clusters via `kmeans'` and then
+unwraps the points.
+
+\begin{code}
+{-@ kmeansGen :: n:Int
+              -> (a -> (Point n))
+              -> k:PosInt
+              -> xs:[a]
+              -> (Clustering a)
+  @-}
+
+kmeansGen n project k = map (map getVal)
+                      . kmeans' n k
+                      . map (\x -> WrapType (project x) x)
+\end{code}
+
+Second, a specialized version that operates directly on `n`-dimensional
+points. The specialized version just calls the general version with a
+trivial `id` projection.
+
+\begin{code}
+{-@ kmeans :: n:Int
+           -> k:PosInt
+           -> points:[(Point n)]
+           -> (Clustering (Point n))
+  @-}
+
+kmeans n   = kmeansGen n id
+\end{code}
+
+Conclusions
+-----------
+
+I hope that over the last two posts you have gotten a sense of
+
+1. What KMeans clustering is all about,
+
+2. How measures and refinements can be used to describe the behavior
+   of common list operations like `map`, `transpose`, `groupBy`, `zipWith`, and so on,
+
+3. How LiquidHaskell's automated inference makes it easy to write and
+   verify invariants of non-trivial programs.
+
+The sharp reader will have noticed that the one *major*, non syntactic, change to the
+[original code][URL-kmeans] is the addition of the dimension parameter `n` throughout
+the code. This is critically required so that we can specify the relevant
+invariants (which are in terms of `n`.) The value is actually a ghost, and
+never ever used. Fortunately, Haskell's laziness means that we don't have
+to worry about it (or other ghost variables) imposing any run-time overhead
+at all.
+
+**Exercise:** Incidentally, if you have followed thus far I would
+encourage you to ponder about how you might modify the types (and
+implementation) to verify that KMeans indeed produces at most `k` clusters...
+
+[ref101]:        /blog/2013/01/01/refinement-types-101.lhs/
+[safeList]:      /blog/2013/01/31/safely-catching-a-list-by-its-tail.lhs/
+[kmeansI]:       /blog/2013/02/16/kmeans-clustering-I.lhs/
+[kmeansII]:      /blog/2013/02/17/kmeans-clustering-II.lhs/
+[URL-take]:      https://github.com/ucsd-progsys/liquidhaskell/blob/master/include/GHC/List.lhs#L334
+[URL-groupBy]:   http://hackage.haskell.org/packages/archive/base/latest/doc/html/Data-List.html#v:groupBy
+[URL-transpose]: http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/Data-List.html#transpose
+[maru]:          http://www.youtube.com/watch?v=8uDuls5TyNE
+[demo]:          http://goto.ucsd.edu/~rjhala/liquid/haskell/demo/#?demo=KMeansHelper.hs
+[URL-kmeans]:    http://hackage.haskell.org/package/kmeans
+
+
diff --git a/docs/blog/2013-03-04-bounding-vectors.lhs b/docs/blog/2013-03-04-bounding-vectors.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-03-04-bounding-vectors.lhs
@@ -0,0 +1,428 @@
+---
+layout: post
+title: "Bounding Vectors"
+date: 2013-03-04 16:12
+author: Ranjit Jhala
+published: true 
+comments: true
+external-url:
+categories: basic
+demo: vectorbounds.hs
+---
+
+Today, lets look at a classic use-case for refinement types, namely, 
+the static verification of **vector access bounds**. Along the way, 
+we'll see some examples that illustrate how LiquidHaskell reasons 
+about *recursion*, *higher-order functions*, *data types*, and 
+*polymorphism*.
+
+
+
+\begin{code}
+module VectorBounds (
+    safeLookup 
+  , unsafeLookup, unsafeLookup'
+  , absoluteSum, absoluteSum'
+  , dotProduct
+  , sparseProduct, sparseProduct'
+  ) where
+
+import Prelude      hiding (length)
+import Data.List    (foldl')
+import Data.Vector  hiding (foldl') 
+\end{code}
+
+Specifying Bounds for Vectors
+-----------------------------
+
+One [classical][dmlarray] use-case for refinement types is to verify
+the safety of accesses of arrays and vectors and such, by proving that
+the indices used in such accesses are *within* the vector bounds. 
+Lets see how to do this with LiquidHaskell by writing a few short
+functions that manipulate vectors, in particular, those from the 
+popular [vector][vec] library. 
+
+First things first. Lets **specify** bounds safety by *refining* 
+the types for the [key functions][vecspec] exported by the module 
+`Data.Vector`. 
+
+\begin{code}Specifications for `Data.Vector`
+module spec Data.Vector where
+
+import GHC.Base
+
+measure vlen  ::   (Vector a) -> Int 
+assume length :: x:(Vector a) -> {v:Int | v = (vlen x)}
+assume !      :: x:(Vector a) -> {v:Int | 0 <= v && v < (vlen x)} -> a 
+\end{code}
+
+In particular, we 
+
+- **define** a *property* called `vlen` which denotes the size of the vector,
+- **assume** that the `length` function *returns* an integer equal to the vector's size, and
+- **assume** that the lookup function `!` *requires* an index between `0` and the vector's size.
+
+There are several things worth paying close attention to in the above snippet.
+
+**Measures**
+
+[Recall][listtail] that measures define auxiliary (or so-called **ghost**)
+properties of data values that are useful for specification and verification, 
+but which *don't actually exist at run-time*. Thus, they will 
+*only appear in specifications*, i.e. inside type refinements, but *never* 
+inside code. Often we will use helper functions like `length` in this case, 
+which *pull* or *materialize* the ghost values from the refinement world 
+into the actual code world.
+
+**Assumes**
+
+We write `assume` because in this scenario we are not *verifying* the
+implementation of `Data.Vector`, we are simply *using* the properties of
+the library to verify client code.  If we wanted to verify the library
+itself, we would ascribe the above types to the relevant functions in the
+Haskell source for `Data.Vector`. 
+
+**Dependent Refinements**
+
+Notice that in the function type (e.g. for `length`) we have *named* the *input*
+parameter `x` so that we can refer to it in the *output* refinement. 
+
+\begin{code} In this case, the type 
+assume length   :: x:(Vector a) -> {v : Int | v = (vlen x)}
+\end{code}
+
+states that the `Int` output is exactly equal to the size of the input `Vector` named `x`.
+
+In other words, the output refinement **depends on** the input value, which
+crucially allows us to write properties that *relate* different program values.
+
+**Verifying a Simple Wrapper**
+
+Lets try write some simple functions to sanity check the above specifications. 
+First, consider an *unsafe* vector lookup function:
+
+\begin{code}
+unsafeLookup vec index = vec ! index
+\end{code}
+
+If we run this through LiquidHaskell, it will spit back a type error for
+the expression `x ! i` because (happily!) it cannot prove that `index` is
+between `0` and the `vlen vec`. Of course, we can specify the bounds 
+requirement in the input type
+
+\begin{code}
+{-@ unsafeLookup :: vec:Vector a 
+                 -> {v: Int | (0 <= v && v < (vlen vec))} 
+                 -> a 
+  @-}
+\end{code}
+
+then LiquidHaskell is happy to verify the lookup. Of course, now the burden
+of ensuring the index is valid is pushed to clients of `unsafeLookup`.
+
+Instead, we might write a *safe* lookup function that performs the *bounds check*
+before looking up the vector:
+
+\begin{code}
+{-@ safeLookup :: Vector a -> Int -> Maybe a @-}
+safeLookup x i 
+  | 0 <= i && i < length x = Just (x ! i)
+  | otherwise              = Nothing 
+\end{code}
+
+**Predicate Aliases**
+
+The type for `unsafeLookup` above is rather verbose as we have to spell out
+the upper and lower bounds and conjoin them. Just as we enjoy abstractions
+when programming, we will find it handy to have abstractions in the
+specification mechanism. To this end, LiquidHaskell supports 
+*predicate aliases*, which are best illustrated by example
+
+\begin{code}
+{-@ predicate Btwn Lo I Hi = (Lo <= I && I < Hi) @-}
+{-@ predicate InBounds I A = (Btwn 0 I (vlen A)) @-}
+\end{code}
+
+Now, we can simplify the type for the unsafe lookup function to
+
+\begin{code}
+{-@ unsafeLookup' :: x:Vector a -> {v:Int | (InBounds v x)} -> a @-}
+unsafeLookup' :: Vector a -> Int -> a
+unsafeLookup' x i = x ! i
+\end{code}
+
+
+Our First Recursive Function
+----------------------------
+
+OK, with the tedious preliminaries out of the way, lets write some code!
+
+To start: a vanilla recursive function that adds up the absolute values of
+the elements of an integer vector.
+
+\begin{code}
+absoluteSum       :: Vector Int -> Int 
+absoluteSum vec   = if 0 < n then go 0 0 else 0
+  where
+    go acc i 
+      | i /= n    = go (acc + abz (vec ! i)) (i + 1)
+      | otherwise = acc 
+    n             = length vec
+\end{code}
+
+where the function `abz` is the absolute value function from [before][ref101].
+
+\begin{code}
+abz n = if 0 <= n then n else (0 - n) 
+\end{code}
+
+Digression: Introducing Errors  
+------------------------------
+
+If you are following along in the demo page -- I heartily 
+recommend that you try the following modifications, 
+one at a time, and see what happens.
+
+**What happens if:** 
+
+1. You *remove* the check `0 < n` (see `absoluteSumNT` in the demo code)
+
+2. You *replace* the guard with `i <= n`
+
+In the *former* case, LiquidHaskell will *verify* safety, but
+in the *latter* case, it will grumble that your program is *unsafe*. 
+
+Do you understand why? 
+(Thanks to [smog_alado][smog_alado] for pointing this out :))
+
+
+Refinement Type Inference
+-------------------------
+
+LiquidHaskell happily verifies `absoluteSum` -- or, to be precise, 
+the safety of the vector accesses `vec ! i`. The verification works 
+out because LiquidHaskell is able to automatically infer a suitable 
+type for `go`. Shuffle your mouse over the identifier above to see 
+the inferred type. Observe that the type states that the first 
+parameter `acc` (and the output) is `0 <= V`. That is, the returned
+value is non-negative.
+
+More importantly, the type states that the second parameter `i` is 
+`0 <= V` and `V <= n` and `V <= (vlen vec)`. That is, the parameter `i` 
+is between `0` and the vector length (inclusive). LiquidHaskell uses these 
+and the test that `i /= n` to establish that `i` is in fact between `0` 
+and `(vlen vec)` thereby verifing safety. 
+
+In fact, if we want to use the function externally (i.e. in another module) 
+we can go ahead and strengthen its type to specify that the output is 
+non-negative.
+
+\begin{code}
+{-@ absoluteSum :: Vector Int -> {v: Int | 0 <= v}  @-} 
+\end{code}
+
+**What happens if:** You *replace* the output type for `absoluteSum` with `{v: Int | 0 < v }` ?
+
+Bottling Recursion With a Higher-Order `loop`
+---------------------------------------------
+
+Next, lets refactor the above low-level recursive function 
+into a generic higher-order `loop`.
+
+\begin{code}
+loop :: Int -> Int -> a -> (Int -> a -> a) -> a 
+loop lo hi base f = go base lo
+  where
+    go acc i     
+      | i /= hi   = go (f i acc) (i + 1)
+      | otherwise = acc
+\end{code}
+
+**Using `loop` to compute `absoluteSum`**
+
+We can now use `loop` to implement `absoluteSum` like so:
+
+\begin{code}
+absoluteSum' vec = if 0 < n then loop 0 n 0 body else 0
+  where body     = \i acc -> acc + (vec ! i)
+        n        = length vec
+\end{code}
+
+LiquidHaskell verifies `absoluteSum'` without any trouble.
+
+It is very instructive to see the type that LiquidHaskell *infers* 
+for `loop` -- it looks something like
+
+\begin{code}
+{-@ loop :: lo: {v: Int | (0 <= v) }  
+         -> hi: {v: Int | (lo <= v) } 
+         -> a 
+         -> (i: {v: Int | (Btwn lo v hi)} -> a -> a)
+         -> a 
+  @-}
+\end{code}
+
+In english, the above type states that 
+
+- `lo` the loop *lower* bound is a non-negative integer
+- `hi` the loop *upper* bound is a greater than `lo`,
+- `f`  the loop *body* is only called with integers between `lo` and `hi`.
+
+Inference is a rather convenient option -- it can be tedious to have to keep 
+typing things like the above! Of course, if we wanted to make `loop` a
+public or exported function, we could use the inferred type to generate 
+an explicit signature too.
+
+\begin{code}At the call 
+loop 0 n 0 body 
+\end{code}
+
+the parameters `lo` and `hi` are instantiated with `0` and `n` respectively
+(which, by the way is where the inference engine deduces non-negativity
+from) and thus LiquidHaskell concludes that `body` is only called with
+values of `i` that are *between* `0` and `(vlen vec)`, which shows the 
+safety of the call `vec ! i`.
+
+**Using `loop` to compute `dotProduct`**
+
+Here's another use of `loop` -- this time to compute the `dotProduct` 
+of two vectors. 
+
+\begin{code}
+dotProduct     :: Vector Int -> Vector Int -> Int
+dotProduct x y = loop 0 (length x) 0 (\i -> (+ (x ! i) * (y ! i))) 
+\end{code}
+
+The gimlet-eyed reader will realize that the above is quite unsafe -- what
+if `x` is a 10-dimensional vector while `y` has only 3-dimensions? 
+
+\begin{code}A nasty
+*** Exception: ./Data/Vector/Generic.hs:244 ((!)): index out of bounds ...
+\end{code}
+
+*Yech*. 
+
+This is precisely the sort of unwelcome surprise we want to do away with at 
+compile-time. Refinements to the rescue! We can specify that the vectors 
+have the same dimensions quite easily
+
+\begin{code}
+{-@ dotProduct :: x:(Vector Int) 
+               -> y:{v: (Vector Int) | (vlen v) = (vlen x)} 
+               -> Int 
+  @-}
+\end{code}
+
+after which LiquidHaskell will gladly verify that the implementation of
+`dotProduct` is indeed safe!
+
+Refining Data Types
+-------------------
+
+Next, suppose we want to write a *sparse dot product*, that is, 
+the dot product of a vector and a **sparse vector** represented
+by a list of index-value tuples.
+
+**Representing Sparse Vectors**
+
+We can represent the sparse vector with a **refinement type alias** 
+
+\begin{code}
+{-@ type SparseVector a N = [({v: Int | (Btwn 0 v N)}, a)] @-}
+\end{code}
+
+As with usual types, the alias `SparseVector` on the left is just a 
+shorthand for the (longer) type on the right, it does not actually 
+define a new type. Thus, the above alias is simply a refinement of
+Haskell's `[(Int, a)]` type, with a size parameter `N` that facilitates 
+easy specification reuse. In this way, refinements let us express 
+invariants of containers like lists in a straightforward manner. 
+
+**Aside:** If you are familiar with the *index-style* length 
+encoding e.g. as found in [DML][dml] or [Agda][agdavec], then note
+that despite appearances, our `SparseVector` definition is *not* 
+indexed. Instead, we deliberately choose to encode properties 
+with logical refinement predicates, to facilitate SMT based 
+checking and inference.
+
+**Verifying Uses of Sparse Vectors**
+
+Next, we can write a recursive procedure that computes the sparse product
+
+\begin{code}
+{-@ sparseProduct :: (Num a) => x:(Vector a) 
+                             -> SparseVector a (vlen x) 
+                             -> a 
+  @-}
+sparseProduct x y  = go 0 y
+  where 
+    go sum ((i, v) : y') = go (sum + (x ! i) * v) y' 
+    go sum []            = sum
+\end{code}
+
+LiquidHaskell verifies the above by using the specification for `y` to
+conclude that for each tuple `(i, v)` in the list, the value of `i` is 
+within the bounds of the vector `x`, thereby proving the safety of the 
+access `x ! i`.
+
+Refinements and Polymorphism
+----------------------------
+
+The sharp reader will have undoubtedly noticed that the sparse product 
+can be more cleanly expressed as a [fold][foldl]. 
+
+\begin{code} Indeed! Let us recall the type of the `foldl` operation
+foldl' :: (a -> b -> a) -> a -> [b] -> a
+\end{code}
+
+Thus, we can simply fold over the sparse vector, accumulating the `sum`
+as we go along
+
+\begin{code}
+{-@ sparseProduct' :: (Num a) => x:(Vector a) 
+                             -> SparseVector a (vlen x) 
+                             -> a 
+  @-}
+sparseProduct' x y  = foldl' body 0 y   
+  where 
+    body sum (i, v) = sum + (x ! i) * v
+\end{code}
+
+LiquidHaskell digests this too, without much difficulty. 
+
+The main trick is in how the polymorphism of `foldl'` is instantiated. 
+
+1. The GHC type inference engine deduces that at this site, the type variable
+   `b` from the signature of `foldl'` is instantiated to the Haskell type `(Int, a)`. 
+
+2. Correspondingly, LiquidHaskell infers that in fact `b` can be instantiated
+   to the *refined* type `({v: Int | (Btwn 0 v (vlen x))}, a)`. 
+   
+Walk the mouse over to `i` to see this inferred type. (You can also hover over
+`foldl'`above to see the rather more verbose fully instantiated type.)
+
+Thus, the inference mechanism saves us a fair bit of typing and allows us to
+reuse existing polymorphic functions over containers and such without ceremony.
+
+Conclusion
+----------
+
+That's all for now folks! Hopefully the above gives you a reasonable idea of
+how one can use refinements to verify size related properties, and more
+generally, to specify and verify properties of recursive, and polymorphic
+functions operating over datatypes. Next time, we'll look at how we can
+teach LiquidHaskell to think about properties of recursive structures
+like lists and trees.
+
+[smog_alado]: http://www.reddit.com/user/smog_alado
+
+[vecspec]:  https://github.com/ucsd-progsys/liquidhaskell/blob/master/include/Data/Vector.spec
+[vec]:      http://hackage.haskell.org/package/vector
+[dml]:      http://www.cs.bu.edu/~hwxi/DML/DML.html
+[agdavec]:  http://code.haskell.org/Agda/examples/Vec.agda
+[ref101]:   /blog/2013/01/01/refinement-types-101.lhs/ 
+[ref102]:   /blog/2013/01/27/refinements-101-reax.lhs/ 
+[foldl]:    http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/Data-List.html
+[listtail]: /blog/2013/01/31/safely-catching-a-list-by-its-tail.lhs/
+[dmlarray]: http://www.cs.bu.edu/~hwxi/academic/papers/pldi98.pdf
+
diff --git a/docs/blog/2013-03-26-talking-about-sets.lhs b/docs/blog/2013-03-26-talking-about-sets.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-03-26-talking-about-sets.lhs
@@ -0,0 +1,383 @@
+---
+layout: post
+title: "Talking About Sets"
+date: 2013-03-26 16:12
+comments: true
+external-url:
+categories: basic measures sets
+author: Ranjit Jhala
+published: true 
+demo: TalkingAboutSets.hs
+---
+
+In the posts so far, we've seen how LiquidHaskell allows you to use SMT 
+solvers to specify and verify *numeric* invariants -- denominators 
+that are non-zero, integer indices that are within the range of an 
+array, vectors that have the right number of dimensions and so on.
+
+However, SMT solvers are not limited to numbers, and in fact, support
+rather expressive logics. In the next couple of posts, let's see how
+LiquidHaskell uses SMT to talk about **sets of values**, for example, 
+the contents of a list, and to specify and verify properties about 
+those sets.
+
+
+
+\begin{code}
+module TalkingAboutSets where
+
+import Data.Set hiding (filter, split)
+import Prelude  hiding (reverse, filter)
+
+\end{code}
+
+Talking about Sets (In Logic)
+=============================
+
+First, we need a way to talk about sets in the refinement logic. We could
+roll our own special Haskell type, but why not just use the `Set a` type
+from `Data.Set`.
+
+The `import Data.Set` , also instructs LiquidHaskell to import in the various 
+specifications defined for the `Data.Set` module that we have *predefined* 
+in [Data/Set.spec][setspec] 
+
+\begin{code} Let's look at the specifications.
+module spec Data.Set where
+
+embed Set as Set_Set
+\end{code}
+
+The `embed` directive tells LiquidHaskell to model the **Haskell** 
+type constructor `Set` with the **SMT** type constructor `Set_Set`.
+
+\begin{code} First, we define the logical operators (i.e. `measure`s) 
+measure Set_sng  :: a -> (Set a)                    -- ^ singleton
+measure Set_cup  :: (Set a) -> (Set a) -> (Set a)   -- ^ union
+measure Set_cap  :: (Set a) -> (Set a) -> (Set a)   -- ^ intersection
+measure Set_dif  :: (Set a) -> (Set a) -> (Set a)   -- ^ difference 
+\end{code}
+
+\begin{code} Next, we define predicates on `Set`s 
+measure Set_emp  :: (Set a) -> Prop                 -- ^ emptiness
+measure Set_mem  :: a -> (Set a) -> Prop            -- ^ membership
+measure Set_sub  :: (Set a) -> (Set a) -> Prop      -- ^ inclusion 
+\end{code}
+
+
+Interpreted Operations
+----------------------
+
+The above operators are *interpreted* by the SMT solver. 
+
+\begin{code} That is, just like the SMT solver "knows that"
+2 + 2 == 4
+\end{code}
+
+\begin{code} the SMT solver also "knows that"
+(Set_sng 1) == (Set_cap (Set_sng 1) (Set_cup (Set_sng 2) (Set_sng 1)))
+\end{code}
+
+This is because, the above formulas belong to a decidable Theory of Sets
+which can be reduced to McCarthy's more general [Theory of Arrays][mccarthy]. 
+See [this recent paper][z3cal] if you want to learn more about how modern SMT 
+solvers "know" the above equality holds...
+
+Talking about Sets (In Code)
+============================
+
+Of course, the above operators exist purely in the realm of the 
+refinement logic, beyond the grasp of the programmer.
+
+To bring them down (or up, or left or right) within reach of Haskell code, 
+we can simply *assume* that the various public functions in `Data.Set` do 
+the *Right Thing* i.e. produce values that reflect the logical set operations:
+
+\begin{code} First, the functions that create `Set` values
+empty     :: {v:(Set a) | (Set_emp v)}
+singleton :: x:a -> {v:(Set a) | v = (Set_sng x)}
+\end{code}
+
+\begin{code} Next, the functions that operate on elements and `Set` values
+insert :: Ord a => x:a 
+                -> xs:(Set a) 
+                -> {v:(Set a) | v = (Set_cup xs (Set_sng x))}
+
+delete :: Ord a => x:a 
+                -> xs:(Set a) 
+                -> {v:(Set a) | v = (Set_dif xs (Set_sng x))}
+\end{code}
+
+\begin{code} Then, the binary `Set` operators
+union        :: Ord a => xs:(Set a) 
+                      -> ys:(Set a) 
+                      -> {v:(Set a) | v = (Set_cup xs ys)}
+
+intersection :: Ord a => xs:(Set a) 
+                      -> ys:(Set a) 
+                      -> {v:(Set a) | v = (Set_cap xs ys)}
+
+difference   :: Ord a => xs:(Set a) 
+                      -> ys:(Set a) 
+                      -> {v:(Set a) | v = (Set_dif xs ys)}
+\end{code}
+
+\begin{code} And finally, the predicates on `Set` values:
+isSubsetOf :: Ord a => xs:(Set a) 
+                    -> ys:(Set a) 
+                    -> {v:Bool | (Prop v) <=> (Set_sub xs ys)}
+
+member     :: Ord a => x:a 
+                    -> xs:(Set a) 
+                    -> {v:Bool | (Prop v) <=> (Set_mem x xs)}
+\end{code}
+
+**Note:** Of course we shouldn't and needn't really *assume*, but should and
+will *guarantee* that the functions from `Data.Set` implement the above types. 
+But thats a story for another day...
+
+Proving Theorems With LiquidHaskell
+===================================
+
+OK, let's take our refined operators from `Data.Set` out for a spin!
+One pleasant consequence of being able to precisely type the operators 
+from `Data.Set` is that we have a pleasant interface for using the SMT
+solver to *prove theorems* about sets, while remaining firmly rooted in
+Haskell. 
+
+First, let's write a simple function that asserts that its input is `True`
+
+\begin{code}
+{-@ boolAssert :: {v: Bool | (Prop v)} -> {v:Bool | (Prop v)} @-}
+boolAssert True   = True
+boolAssert False  = error "boolAssert: False? Never!"
+\end{code}
+
+Now, we can use `boolAssert` to write some simple properties. (Yes, these do
+indeed look like QuickCheck properties -- but here, instead of generating
+tests and executing the code, the type system is proving to us that the
+properties will *always* evaluate to `True`) 
+
+Let's check that `intersection` is commutative ...
+
+\begin{code}
+prop_cap_comm x y 
+  = boolAssert 
+  $ (x `intersection` y) == (y `intersection` x)
+\end{code}
+
+that `union` is associative ...
+
+\begin{code}
+prop_cup_assoc x y z 
+  = boolAssert 
+  $ (x `union` (y `union` z)) == (x `union` y) `union` z
+\end{code}
+
+and that `union` distributes over `intersection`.
+
+\begin{code}
+prop_cap_dist x y z 
+  = boolAssert 
+  $  (x `intersection` (y `union` z)) 
+  == (x `intersection` y) `union` (x `intersection` z) 
+\end{code}
+  
+Of course, while we're at it, let's make sure LiquidHaskell
+doesn't prove anything that *isn't* true ...
+
+\begin{code}
+prop_cup_dif_bad x y
+   = boolAssert 
+   $ x == (x `union` y) `difference` y
+\end{code}
+
+Hmm. You do know why the above doesn't hold, right? It would be nice to
+get a *counterexample* wouldn't it? Well, for the moment, there is
+QuickCheck!
+
+Thus, the refined types offer a nice interface for interacting with the SMT
+solver in order to prove theorems in LiquidHaskell. (BTW, The [SBV project][sbv]
+describes another approach for using SMT solvers from Haskell, without the 
+indirection of refinement types.)
+
+While the above is a nice warm up exercise to understanding how
+LiquidHaskell reasons about sets, our overall goal is not to prove 
+theorems about set operators, but instead to specify and verify 
+properties of programs. 
+
+
+
+The Set of Values in a List
+===========================
+
+Let's see how we might reason about sets of values in regular Haskell programs.
+
+We'll begin with Lists, the jack-of-all-data-types. Now, instead of just
+talking about the **number of** elements in a list, we can write a measure
+that describes the **set of** elements in a list:
+
+\begin{code} A measure for the elements of a list, from [Data/Set.spec][setspec]
+
+measure listElts :: [a] -> (Set a) 
+listElts ([])    = {v | (? Set_emp(v))}
+listElts (x:xs)  = {v | v = (Set_cup (Set_sng x) (listElts xs)) }
+\end{code}
+
+That is, `(listElts xs)` describes the set of elements contained in a list `xs`.
+
+Next, to make the specifications concise, let's define a few predicate aliases:
+
+\begin{code}
+{-@ predicate EqElts  X Y = 
+      ((listElts X) = (listElts Y))                        @-}
+
+{-@ predicate SubElts   X Y = 
+      (Set_sub (listElts X) (listElts Y))                  @-}
+
+{-@ predicate UnionElts X Y Z = 
+      ((listElts X) = (Set_cup (listElts Y) (listElts Z))) @-}
+\end{code}
+
+A Trivial Identity
+------------------
+
+OK, now let's write some code to check that the `listElts` measure is sensible!
+
+\begin{code}
+{-@ listId    :: xs:[a] -> {v:[a] | (EqElts v xs)} @-}
+listId []     = []
+listId (x:xs) = x : listId xs
+\end{code}
+
+That is, LiquidHaskell checks that the set of elements of the output list
+is the same as those in the input.
+
+A Less Trivial Identity
+-----------------------
+
+Next, let's write a function to `reverse` a list. Of course, we'd like to
+verify that `reverse` doesn't leave any elements behind; that is that the 
+output has the same set of values as the input list. This is somewhat more 
+interesting because of the *tail recursive* helper `go`. Do you understand 
+the type that is inferred for it? (Put your mouse over `go` to see the 
+inferred type.)
+
+\begin{code}
+{-@ reverse       :: xs:[a] -> {v:[a] | (EqElts v xs)} @-}
+reverse           = go [] 
+  where 
+    go acc []     = acc
+    go acc (y:ys) = go (y:acc) ys
+\end{code}
+
+Appending Lists
+---------------
+
+Next, here's good old `append`, but now with a specification that states
+that the output indeed includes the elements from both the input lists.
+
+\begin{code}
+{-@ append       :: xs:[a] -> ys:[a] -> {v:[a]| (UnionElts v xs ys)} @-}
+append []     ys = ys
+append (x:xs) ys = x : append xs ys
+\end{code}
+
+Filtering Lists
+---------------
+
+Let's round off the list trilogy, with `filter`. Here, we can verify
+that it returns a **subset of** the values of the input list.
+
+\begin{code}
+{-@ filter      :: (a -> Bool) -> xs:[a] -> {v:[a]| (SubElts v xs)} @-}
+
+filter f []     = []
+filter f (x:xs) 
+  | f x         = x : filter f xs 
+  | otherwise   = filter f xs
+\end{code}
+
+Merge Sort
+==========
+
+Let's conclude this entry with one larger example: `mergeSort`.
+We'd like to verify that, well, the list that is returned 
+contains the same set of elements as the input list. 
+
+And so we will!
+
+But first, let's remind ourselves of how `mergeSort` works:
+
+1. `split` the input list into two halves, 
+2. `sort`  each half, recursively, 
+3. `merge` the sorted halves to obtain the sorted list.
+
+
+Split
+-----
+
+We can `split` a list into two, roughly equal parts like so:
+
+\begin{code}
+split []     = ([], [])
+split (x:xs) = (x:zs, ys)
+  where 
+    (ys, zs) = split xs
+\end{code}
+
+LiquidHaskell verifies that the relevant property of split is
+
+\begin{code} 
+{-@ split :: xs:[a] -> ([a], [a])<{\ys zs -> (UnionElts xs ys zs)}> @-}
+\end{code}
+
+The funny syntax with angle brackets simply says that the output of `split` 
+is a *pair* `(ys, zs)` whose union is the list of elements of the input `xs`.
+(Yes, this is indeed a dependent pair; we will revisit these later to
+understand whats going on with the odd syntax.)
+
+Merge
+-----
+
+Next, we can `merge` two (sorted) lists like so:
+
+\begin{code}
+merge xs []         = xs
+merge [] ys         = ys
+merge (x:xs) (y:ys) 
+  | x <= y          = x : merge xs (y : ys)
+  | otherwise       = y : merge (x : xs) ys
+\end{code}
+
+As you might expect, the elements of the returned list are the union of the
+elements of the input, or as LiquidHaskell might say,
+
+\begin{code}
+{-@ merge :: (Ord a) => x:[a] -> y:[a] -> {v:[a]| (UnionElts v x y)} @-}
+\end{code}
+
+Sort
+----
+
+Finally, we put all the pieces together by
+
+\begin{code}
+{-@ mergeSort :: (Ord a) => xs:[a] -> {v:[a] | (EqElts v xs)} @-}
+mergeSort []  = []
+mergeSort [x] = [x]
+mergeSort xs  = merge (mergeSort ys) (mergeSort zs) 
+  where 
+    (ys, zs)  = split xs
+\end{code}
+
+The type given to `mergeSort`guarantees that the set of elements in the 
+output list is indeed the same as in the input list. Of course, it says 
+nothing about whether the list is *actually sorted*. 
+
+Well, Rome wasn't built in a day...
+
+[sbv]:      https://github.com/LeventErkok/sbv
+[setspec]:  https://github.com/ucsd-progsys/liquidhaskell/blob/master/include/Data/Set.spec
+[mccarthy]: http://www-formal.stanford.edu/jmc/towards.ps
+[z3cal]:    http://research.microsoft.com/en-us/um/people/leonardo/fmcad09.pdf
diff --git a/docs/blog/2013-05-16-unique-zippers.lhs b/docs/blog/2013-05-16-unique-zippers.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-05-16-unique-zippers.lhs
@@ -0,0 +1,313 @@
+---
+layout: post
+title: "Unique Zippers"
+date: 2013-05-10 16:12
+comments: true
+external-url:
+categories: basic measures sets zipper uniqueness
+author: Niki Vazou
+published: false 
+demo: TalkingAboutUniqueSets.hs
+---
+
+**The story so far:** [Previously][talking-about-sets] we saw
+how we can use LiquidHaskell to talk about set of values and specifically
+the set of values in a list.
+
+In this post, we will extend this vocabulary to talk about the 
+set of duplicate values in a list. 
+If we constrain this set to be empty, 
+we encode a list without duplicates, or an **unique list**. 
+Once we express uniqueness on lists, it is straightforward to 
+describe uniqueness on other data structures that contain lists.
+As an example, we will illustrate the properties of a **unique zipper**.
+
+\begin{code}
+module UniqueZipper where
+
+import Prelude  hiding (reverse, (++), filter)
+import Data.Set hiding (filter)
+\end{code}
+
+
+A Quick Recap
+=============
+
+\begin{code} In the previous post we used a measure for the elements of a list, from [Data/Set.spec][setspec]
+measure listElts :: [a] -> (Set a)
+listElts ([])    = {v | (? Set_emp(v))}
+listElts (x:xs)  = {v | v = (Set_cup (Set_sng x) (listElts xs)) }
+\end{code}
+
+With this measure we defined predicate aliases 
+that describe relations between lists:
+
+\begin{code}
+{-@ predicate EqElts  X Y      = ((listElts X) = (listElts Y))                        @-}
+
+{-@ predicate DisjointElts X Y = (Set_emp (Set_cap (listElts X) (listElts Y)))        @-}
+
+{-@ predicate SubElts X Y      = (Set_sub (listElts X) (listElts Y))                  @-}
+
+{-@ predicate UnionElts X Y Z  = ((listElts X) = (Set_cup (listElts Y) (listElts Z))) @-}
+
+{-@ predicate ListElt N X      = (Set_mem N (listElts X))                             @-}
+\end{code}
+
+
+These predicates were our vocabulary on specifying properties of list functions.
+Remember, that `reverse` returns an output list that has the same elements, i.e., `EqElts`, with the input list.
+We can extend these predicates and express list uniqueness.
+So reversing a unique list should again return an output list that has the same
+elements as the input list, and also it is unique.
+
+Describing Unique Lists
+======================
+
+To describe unique lists, we follow two steps:
+first, we describe the set of duplicate values of
+a list;
+then, we demand this set to be empty.
+
+Towards the first step, we define a measure `listDup`
+that returns the duplicate values of its input list.
+This measure is recursively defined:
+The duplicates of an empty list is the empty set.
+We compute the duplicates of a non-empty list, 
+namely `x:xs`, as follows:
+
+- If `x` is member of the list values of `xs`, then `x` is a duplicate
+so `listDup` returns a set that contains `x` and the 
+list duplicates of `xs`, as computed recursively.
+
+- Otherwise, we can ignore `x` and recursively compute the duplicates of `xs`.
+
+\begin{code}
+{-@
+  measure listDup :: [a] -> (Set a)
+  listDup([])   = {v | (? (Set_emp v))}
+  listDup(x:xs) = {v | v = ((Set_mem x (listElts xs))?(Set_cup (Set_sng x) (listDup xs)):(listDup xs)) }
+  @-}
+\end{code}
+
+With `listDup` at hand, it is direct to describe unique lists.
+A list is unique, if the set of duplicates, 
+as computed by `listDup`
+is the empty set.
+We create a type alias for unique lists and name it `UList`.
+
+\begin{code}
+{-@ predicate ListUnique X = (Set_emp (listDup X)) @-}
+
+{-@ type UList a = {v:[a] | (ListUnique v)}        @-}
+\end{code}
+
+
+Functions on Unique Lists
+==========================
+
+In the previous post, we proved interesting properties about 
+the list trilogy, i.e., `append`, `reverse`, and `filter`.
+Now, we will prove that apart from these properties,
+all these function preserve list uniqueness.
+
+To begin with, 
+we proved that the output of append
+indeed includes the elements from both the input lists.
+Now, we can also prove that if both input lists are unique and 
+their values form disjoint sets, then the output list is also unique.
+
+\begin{code}
+infixr 5 ++
+{-@ UniqueZipper.++ :: xs:(UList a)
+                    -> ys:{v: UList a | (DisjointElts v xs)}
+                    -> {v: UList a | (UnionElts v xs ys)}
+  @-}
+(++)         :: [a] -> [a] -> [a]
+[] ++ ys     = ys
+(x:xs) ++ ys = x: (xs ++ ys)
+\end{code}
+
+Next, we can prove that if a unique list is reversed, 
+the output list has the same elements as the input,
+and also it is unique.
+\begin{code}
+{-@ reverse :: xs:(UList a)
+            -> {v: UList a | (EqElts v xs)} 
+  @-}
+reverse :: [a] -> [a]
+reverse = go []
+  where
+    go a []     = a
+    go a (x:xs) = go (x:a) xs 
+\end{code}
+
+Finally, filtering a unique list returns a list
+with a subset of values of the input list, that once again is unique! 
+
+\begin{code}
+{-@ filter :: (a -> Bool) -> xs:(UList a) -> {v:UList a | (SubElts v xs)} @-}
+filter      :: (a -> Bool) -> [a] -> [a]
+filter p [] = []
+filter p (x:xs) 
+  | p x       = x : filter p xs
+  | otherwise = filter p xs
+\end{code}
+
+Unique Zipper
+=============
+
+A [zipper][http://en.wikipedia.org/wiki/Zipper_(data_structure)] is an aggregate data stucture 
+that is used to arbitrary traverse the structure and update its contents.
+We define a zipper as a data type that contains 
+an element (called `focus`) that we are currently using,
+a list of elements (called `up`) before the current one,
+and a list of elements (called `down`) after the current one.
+
+\begin{code}
+data Zipper a = Zipper { focus :: a       -- focused element in this set
+                       , up    :: [a]     -- elements to the left
+                       , down  :: [a] }   -- elements to the right
+\end{code}
+
+
+We would like to state that all the values in the zipper 
+are unique.
+To start with, we would like to refine the `Zipper` data declaration
+to express that both the lists in the structure
+are unique **and** do not include `focus` in their values.
+
+LiquidHaskell allow us to refine data type declarations, 
+using the liquid comments.
+So, apart from above definition definition for the `Zipper`, 
+we add a refined one, stating that the data structure always enjoys 
+the desired properties.
+
+\begin{code}
+{-@ 
+data Zipper a = Zipper { focus :: a
+                       , up    :: UListDif a focus
+                       , down  :: UListDif a focus}
+  @-}
+
+{-@ type UListDif a N = {v:(UList a) | (not (ListElt N v))} @-}
+\end{code}
+
+With this annotation any time we use a `Zipper` in the code
+LiquidHaskell knows that 
+the `up` and `down` components are unique lists that do not include `focus`.
+Moreover, when a new `Zipper` is constructed we should prove that
+this property holds,
+otherwise a liquid error will occur.
+
+You may notice values inside the `Zipper` are not unique, as
+a value can appear in both the `up` and the `down` components.
+So, we have to specify that 
+these two elements form disjoint lists.
+To this end, we define two measures `getUp` and `getDown`
+that return the relevant parts of the `Zipper`
+
+\begin{code}
+{-@ measure getUp :: forall a. (Zipper a) -> [a] 
+    getUp (Zipper focus up down) = up
+  @-}
+
+{-@ measure getDown :: forall a. (Zipper a) -> [a] 
+    getDown (Zipper focus up down) = down
+  @-}
+\end{code}
+
+With these definitions, we create a type alias `UZipper` that states that 
+the two list components are disjoint.
+
+\begin{code}
+{-@ type UZipper a = {v:Zipper a | (DisjointElts (getUp v) (getDown v))} @-}
+\end{code}
+
+Functions on Unique Zipper
+===========================
+
+Since we defined a unique zipper, it is straightforward for
+LiquidHaskell to prove that
+operations on zippers preserve uniqueness.
+
+We can prove that a zipper that contains elements 
+from a unique list is indeed unique.
+
+\begin{code}
+{-@ differentiate :: UList a -> Maybe (UZipper a) @-}
+differentiate :: [a] -> Maybe (Zipper a)
+differentiate []     = Nothing
+differentiate (x:xs) = Just $ Zipper x [] xs
+\end{code}
+
+And vice versa, all elements of a unique zipper 
+can construct a unique list.
+
+\begin{code}
+{-@ integrate :: UZipper a -> UList a @-}
+integrate :: Zipper a -> [a]
+integrate (Zipper x l r) = reverse l ++ x : r
+\end{code}
+
+By the definition of `UZipper` we know that `l` is a unique list
+and that `x` is not an element of `l`.
+Thus, if `l` is reversed using the descriptive type of `reverse` 
+that we provided before, it preserves both these properties.
+The append operator also uses the 
+type that we show before. So LiquidHaskell, can prove that `x : r`
+is indeed a unique list with elements disjoint from `reverse l` and so we can append it to `reverse l` 
+and get a unique list.
+
+
+With the exact same reasoning, 
+we use the above list operations to create more zipper operations.
+
+So we can reverse a unique zipper
+\begin{code}
+{-@ reverseZipper :: UZipper a -> UZipper a @-}
+reverseZipper :: Zipper a -> Zipper a
+reverseZipper (Zipper t ls rs) = Zipper t rs ls
+\end{code}
+
+
+More the focus up or down
+\begin{code}
+{-@ focusUp, focusDown :: UZipper a -> UZipper a @-}
+focusUp, focusDown :: Zipper a -> Zipper a
+focusUp (Zipper t [] rs)     = Zipper x xs [] where (x:xs) = reverse (t:rs)
+focusUp (Zipper t (l:ls) rs) = Zipper l ls (t:rs)
+
+focusDown = reverseZipper . focusUp . reverseZipper
+
+{-@ q :: x:a ->  {v:[a] |(not (Set_mem x (listElts v)))} @-}
+q :: a -> [a]
+q _ = []
+\end{code}
+
+Finally, using the filter operation on lists
+allows LiquidHaskell to prove that filtering a zipper 
+also preserves uniqueness.
+\begin{code}
+{-@ filterZipper :: (a -> Bool) -> UZipper a -> Maybe (UZipper a) @-}
+filterZipper :: (a -> Bool) -> Zipper a -> Maybe (Zipper a)
+filterZipper p (Zipper f ls rs) = case filter p (f:rs) of
+    f':rs' -> Just $ Zipper f' (filter p ls) rs'    -- maybe move focus down
+    []     -> case filter p ls of                  -- filter back up
+                    f':ls' -> Just $ Zipper f' ls' [] -- else up
+                    []     -> Nothing
+\end{code}
+
+Conclusion
+==========
+
+That's all for now!
+This post illustrated
+
+- How we can use set theory to express properties the values of the list,
+such as list uniqueness.
+- How we can use LuquidHaskell to prove that these properties are preserved through list operations.
+- How we can embed this properties in complicated data structures that use lists, such as a zipper.
+
+
+
diff --git a/docs/blog/2013-05-24-unique-zipper.lhs b/docs/blog/2013-05-24-unique-zipper.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-05-24-unique-zipper.lhs
@@ -0,0 +1,396 @@
+---
+layout: post
+title: "Unique Zippers"
+date: 2013-05-10 16:12
+comments: true
+external-url:
+categories: basic measures sets zipper uniqueness
+author: Niki Vazou
+published: true
+demo: UniqueZipper.hs
+---
+
+**The story so far:** [Previously][about-sets] we saw
+how we can use LiquidHaskell to talk about set of values
+and specifically the *set of values* in a list.
+
+Often, we want to enforce the invariant that a particular data structure
+contains *no duplicates*. For example, we may have a structure that holds
+a collection of file handles, or other resources, where the presence of
+duplicates could lead to unpleasant leaks.
+
+In this post, we will see how to use LiquidHaskell to talk
+about the set of duplicate values in data structures, and 
+hence, let us specify and verify uniqueness, that is, the
+absence of duplicates.
+
+
+
+To begin, lets extend our vocabulary to talk about the *set of duplicate
+values* in lists.  By constraining this set to be empty, we can specify a
+list without duplicates, or an **unique list**.  Once we express uniqueness
+on lists, it is straightforward to describe uniqueness on other data
+structures that contain lists.  As an example, we will illustrate the
+properties of a **unique zipper**.
+
+\begin{code}
+module UniqueZipper where
+
+import Prelude  hiding (reverse, (++), filter)
+import Data.Set hiding (filter)
+\end{code}
+
+
+A Quick Recap
+=============
+
+\begin{code} In the previous post we used a measure for the elements of a list, from [Data/Set.spec][setspec]
+measure listElts :: [a] -> (Set a)
+listElts ([])    = {v | (? (Set_emp v))}
+listElts (x:xs)  = {v | v = (Set_cup (Set_sng x) (listElts xs)) }
+\end{code}
+
+With this measure we defined predicate aliases 
+that describe relations between lists:
+
+\begin{code}
+{-@ predicate EqElts  X Y      = 
+      ((listElts X) = (listElts Y))                        @-}
+
+{-@ predicate DisjointElts X Y = 
+      (Set_emp (Set_cap (listElts X) (listElts Y)))        @-}
+
+{-@ predicate SubElts X Y      = 
+      (Set_sub (listElts X) (listElts Y))                  @-}
+
+{-@ predicate UnionElts X Y Z  = 
+      ((listElts X) = (Set_cup (listElts Y) (listElts Z))) @-}
+
+{-@ predicate ListElt N X      = 
+      (Set_mem N (listElts X))                             @-}
+\end{code}
+
+
+These predicates were our vocabulary on specifying properties of list functions.
+Remember, that `reverse` returns an output list that has the same elements, i.e., `EqElts`, with the input list.
+We can extend these predicates and express list uniqueness.
+So reversing a unique list should again return an output list that has the same
+elements as the input list, and also it is unique.
+
+Describing Unique Lists
+======================
+
+To describe unique lists, we follow two steps:
+
+1. we describe the set of duplicate values of a list; and 
+2. we demand this set to be empty.
+
+Towards the first step, we define a measure `dups`
+that returns the duplicate values of its input list.
+This measure is recursively defined:
+The duplicates of an empty list is the empty set.
+We compute the duplicates of a non-empty list, 
+namely `x:xs`, as follows:
+
+- If `x` is an element of `xs`, then `x` is a duplicate.
+  Hence, `dups` is `x` plus the (recursively computed) 
+  duplicates in `xs`.
+
+- Otherwise, we can ignore `x` and recursively compute 
+  the duplicates of `xs`.
+
+The above intuition can be formalized as a measure:
+
+\begin{code}
+{-@
+  measure dups :: [a] -> (Set a)
+  dups([])   = {v | (? (Set_emp v))}
+  dups(x:xs) = {v | v = (if (Set_mem x (listElts xs))
+                         then (Set_cup (Set_sng x) (dups xs))
+                         else (dups xs)) }
+  @-}
+\end{code}
+
+With `dups` in hand, it is direct to describe unique lists:
+
+A list is unique, if the set of duplicates, as computed by `dups` is empty.
+
+We create a type alias for unique lists and name it `UList`.
+
+\begin{code}
+{-@ predicate ListUnique X = (Set_emp (dups X)) @-}
+
+{-@ type UList a = {v:[a] | (ListUnique v)}     @-}
+\end{code}
+
+
+Functions on Unique Lists
+==========================
+
+In the previous post, we proved interesting properties about 
+the list trilogy, i.e., `append`, `reverse`, and `filter`.
+Now, we will prove that apart from these properties,
+all these functions preserve list uniqueness.
+
+Append
+------
+
+To begin with, we proved that the output of append
+indeed includes the elements from both the input lists.
+Now, we can also prove that if both input lists are 
+unique *and their elements are disjoint*, then the 
+output list is also unique.
+
+\begin{code}
+infixr 5 ++
+{-@ UniqueZipper.++ :: xs:(UList a)
+                    -> ys:{v: UList a | (DisjointElts v xs)}
+                    -> {v: UList a | (UnionElts v xs ys)}
+  @-}
+(++)         :: [a] -> [a] -> [a]
+[] ++ ys     = ys
+(x:xs) ++ ys = x:(xs ++ ys)
+\end{code}
+
+Reverse
+-------
+
+Next, we can prove that if a unique list is reversed, 
+the output list has the same elements as the input,
+and also it is unique.
+
+\begin{code}
+{-@ reverse :: xs:(UList a) -> {v: UList a | (EqElts v xs)} @-}
+reverse :: [a] -> [a]
+reverse = go []
+  where
+    go a []     = a
+    go a (x:xs) = go (x:a) xs 
+\end{code}
+
+Filter
+------
+
+Finally, filtering a unique list returns a list with a subset of
+values of the input list, that once again is unique! 
+
+\begin{code}
+{-@ filter :: (a -> Bool) 
+           -> xs:(UList a) 
+           -> {v:UList a | (SubElts v xs)} 
+  @-}
+filter p [] = []
+filter p (x:xs) 
+  | p x       = x : filter p xs
+  | otherwise = filter p xs
+\end{code}
+
+
+Unique Zipper
+=============
+
+That was easy enough! Now, lets look at a slightly more interesting
+structure fashioned from lists.  A [zipper][wiki-zipper] is an aggregate
+data stucture that is used to arbitrary traverse the structure and update
+its contents.
+
+We define a zipper as a data type that contains an element (called `focus`)
+that we are currently using, a list of elements (called `up`) before
+the current one, and a list of elements (called `down`) after the current one.
+
+\begin{code}
+data Zipper a = Zipper { focus :: a       -- focused element in this set
+                       , up    :: [a]     -- elements to the left
+                       , down  :: [a] }   -- elements to the right
+\end{code}
+
+
+One well-known application of zippers is in the
+[XMonad](http://xmonad.org/) tiling window manager. 
+The set of windows being managed is stored in a zipper 
+similar to the above. The `focus` happily coincides with 
+the window currently in focus, and the `up` and `down` 
+to the list of windows that come before and after it.
+
+One crucial invariant maintained by XMonad is that the zipper structure is
+unique -- i.e. each window appears at most once inside the zipper.
+
+Lets see how we can state and check that all the values in a zipper are unique.
+
+To start with, we would like to refine the `Zipper` data declaration
+to express that both the lists in the structure are unique **and** 
+do not include `focus` in their values.
+
+LiquidHaskell allow us to refine data type declarations, using the liquid comments.
+So, apart from above definition definition for the `Zipper`, we add a refined one,
+stating that the data structure always enjoys the desired properties.
+
+\begin{code}
+{-@ data Zipper a = Zipper { focus :: a
+                           , up    :: UListDif a focus
+                           , down  :: UListDif a focus}
+  @-}
+
+{-@ type UListDif a N = {v:(UList a) | (not (ListElt N v))} @-}
+\end{code}
+
+It is worth noting that the above is kind of *dependent* record in that
+the types of the `up` and `down` fields depend on the value of the `focus`
+field.
+
+With this annotation any time we use a `Zipper` in the code LiquidHaskell
+knows that the `up` and `down` components are unique lists
+that do not include `focus`. Moreover, when a new `Zipper` is constructed
+LiquidHaskell proves that this property holds, otherwise a liquid type 
+error is reported.
+
+
+Hold on a minute!
+
+The awake reader will have noticed that values inside the `Zipper` as 
+specified so far, are *not unique*, as nothing prevents a value from 
+appearing in both the `up` and the `down` components.
+
+So, we have to specify that the contents of those two fields are *disjoint*.
+
+One way to achieve this is by defining two measures `getUp` and `getDown`
+that return the relevant parts of the `Zipper`
+
+\begin{code}
+{-@ measure getUp :: forall a. (Zipper a) -> [a] 
+    getUp (Zipper focus up down) = up
+  @-}
+
+{-@ measure getDown :: forall a. (Zipper a) -> [a] 
+    getDown (Zipper focus up down) = down
+  @-}
+\end{code}
+
+With these definitions, we create a type alias `UZipper`
+that states that the two list components are disjoint, and hence,
+that we have a *unique zipper* with no duplicates.
+
+\begin{code}
+{-@ 
+  type UZipper a = {v:Zipper a | (DisjointElts (getUp v) (getDown v))} 
+  @-}
+\end{code}
+
+
+Functions on Unique Zippers
+===========================
+
+Now that we have defined a unique zipper, it is straightforward for
+LiquidHaskell to prove that operations on zippers preserve uniqueness.
+
+Differentiation
+---------------
+
+We can prove that a zipper that built from elements from a unique list is
+indeed unique.
+
+\begin{code}
+{-@ differentiate :: UList a -> Maybe (UZipper a) @-}
+differentiate []     = Nothing
+differentiate (x:xs) = Just $ Zipper x [] xs
+\end{code}
+
+Integration
+-----------
+
+And vice versa, all elements of a unique zipper yield a unique list.
+
+\begin{code}
+{-@ integrate :: UZipper a -> UList a @-}
+integrate (Zipper x l r) = reverse l ++ x : r
+\end{code}
+
+Recall the types for `++` and `reverse` that we proved earlier -- hover
+your mouse over the identifiers to refresh your memory. Those types are
+essential for establishing the type of `integrate`. 
+
+- By the definition of `UZipper` we know that `l` is a unique list
+  and that `x` is not an element of `l`.
+
+- Thus via the type of `reverse` we know that  `reverse l` is also
+  unique and disjoint from `x` and `r`.
+
+- Finally, using the previously established type for `++` 
+  LiquidHaskell can prove that since `x : r` is a unique 
+  list with elements disjoint from `reverse l` the concatenation
+  of the two lists is also a unique list.
+
+
+With the exact same reasoning, we use the above list operations to create more zipper operations.
+
+Reverse
+-------
+
+We can reverse a unique zipper
+
+\begin{code}
+{-@ reverseZipper :: UZipper a -> UZipper a @-}
+reverseZipper :: Zipper a -> Zipper a
+reverseZipper (Zipper t ls rs) = Zipper t rs ls
+\end{code}
+
+Shifting Focus
+--------------
+
+More the focus up or down
+
+\begin{code}
+{-@ focusUp   :: UZipper a -> UZipper a @-}
+focusUp (Zipper t [] rs)     = Zipper x xs [] 
+  where 
+    (x:xs)                   = reverse (t:rs)
+
+focusUp (Zipper t (l:ls) rs) = Zipper l ls (t:rs)
+
+{-@ focusDown :: UZipper a -> UZipper a @-}
+focusDown = reverseZipper . focusUp . reverseZipper
+\end{code}
+
+Filter
+------
+
+Finally, using the filter operation on lists allows LiquidHaskell to prove
+that filtering a zipper also preserves uniqueness.
+
+\begin{code}
+{-@ filterZipper :: (a -> Bool) -> UZipper a -> Maybe (UZipper a) @-}
+filterZipper p (Zipper f ls rs) 
+  = case filter p (f:rs) of
+      f':rs' -> Just $ Zipper f' (filter p ls) rs'
+      []     -> case filter p ls of                  
+                  f':ls' -> Just $ Zipper f' ls' []
+                  []     -> Nothing
+\end{code}
+
+Conclusion
+==========
+
+That's all for now! This post illustrated
+
+1. How we can use set theory to express properties the values of the list,
+   such as list uniqueness.
+
+2. How we can use LuquidHaskell to prove that these properties are
+   preserved through list operations.
+
+3. How we can embed this properties in complicated data structures that use
+   lists, such as a zipper.
+
+
+[wiki-zipper]: http://en.wikipedia.org/wiki/Zipper_(data_structure)
+[about-sets]:  blog/2013/03/26/talking-about-sets.lhs/
+[setspec]:     https://github.com/ucsd-progsys/liquidhaskell/blob/master/include/Data/Set.spec
+
+\begin{code}
+-- TODO: Dummy function to provide qualifier hint.
+{-@ q :: x:a ->  {v:[a] |(not (Set_mem x (listElts v)))} @-}
+q :: a -> [a]
+q _ = []
+\end{code}
+
+
diff --git a/docs/blog/2013-06-03-abstracting-over-refinements.lhs b/docs/blog/2013-06-03-abstracting-over-refinements.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-06-03-abstracting-over-refinements.lhs
@@ -0,0 +1,315 @@
+---
+layout: post
+title: "Abstracting Over Refinements"
+date: 2013-06-03 16:12
+comments: true
+external-url:
+author: Ranjit Jhala and Niki Vazou 
+published: true 
+categories: abstract-refinements
+demo: absref101.hs
+---
+
+We've seen all sorts of interesting invariants that can be expressed with
+refinement predicates. For example, whether a divisor is [non-zero][blog-dbz], 
+the [dimension][blog-len] of lists, ensuring the safety of 
+[vector indices][blog-vec] and reasoning about the [set][blog-set] of values
+in containers and verifying their [uniqueness][blog-zip].
+In each of these cases, we were working with *specific* refinement predicates
+that described whatever property was of interest.
+
+Today, (drumroll please), I want to unveil a brand new feature of
+LiquidHaskell, which allows us to *abstract* over specific properties or
+invariants, which significantly increases the expressiveness of the 
+system, whilst still allowing our friend the SMT solver to carry 
+out verification and inference automatically.
+
+
+
+\begin{code}
+
+module MickeyMouse where
+
+import Language.Haskell.Liquid.Prelude (isEven)
+\end{code}
+
+Pin The Specification On the Function 
+-------------------------------------
+
+Lets look at some tiny *mickey-mouse* examples to see why we may want
+to abstract over refinements in the first place.
+
+Consider the following monomorphic `max` function on `Int` values:
+
+\begin{code}
+maxInt     :: Int -> Int -> Int 
+maxInt x y = if x <= y then y else x 
+\end{code}
+
+\begin{code} We could give `maxInt` many, quite different and incomparable refinement types like
+maxInt :: {v:Int | v >= 0} -> {v:Int | v >= 0} -> {v:Int | v >= 0}
+\end{code}
+
+\begin{code}or
+maxInt :: {v:Int | v < 10} -> {v:Int | v < 10} -> {v:Int | v < 10}
+\end{code}
+
+\begin{code}or even 
+maxInt :: {v:Int | (Even v)} -> {v:Int | (Even v)} -> {v:Int | (Even v)}
+\end{code}
+
+All of the above are valid. 
+
+But which one is the *right* type? 
+
+At this point, you might be exasperated for one of two reasons.
+
+First, the type enthusiasts among you may cry out -- "What? Does this funny
+refinement type system not have **principal types**?"
+
+No. Or, to be precise, of course not!
+
+Principal typing is a lovely feature that is one of the many 
+reasons why Hindley-Milner is such a delightful sweet spot. 
+Unfortunately, the moment one wants fancier specifications 
+one must tearfully kiss principal typing good bye.
+
+Oh well.
+
+Second, you may very well say, "Yes yes, does it even matter? Just pick
+one and get on with it already!"
+
+Unfortunately, it matters quite a bit.
+
+Suppose we had a refined type describing valid RGB values:
+
+\begin{code}
+{-@ type RGB = {v: Int | ((0 <= v) && (v < 256)) } @-}
+\end{code}
+
+Now, if I wrote a function that selected the larger, that is to say, the
+more intense, of two RGB values, I would certainly like to check that it 
+produced an RGB value!
+
+\begin{code}
+{-@ intenser   :: RGB -> RGB -> RGB @-}
+intenser c1 c2 = maxInt c1 c2
+\end{code}
+
+Well, guess what. The first type (with `v >= 0`) one would tell us that 
+the output was non-negative, losing the upper bound. The second type (with
+`v < 10`) would cause LiquidHaskell to bellyache about `maxInt` being 
+called with improper arguments -- muttering darkly that an RGB value 
+is not necesarily less than `10`. As for the third type ... well, you get the idea.
+
+So alas, the choice of type *does* matter. 
+
+\begin{code} If we were clairvoyant, we would give `maxInt` a type like
+maxInt :: RGB -> RGB -> RGB 
+\end{code}
+
+but of course, that has its own issues. ("What? I have to write a
+*separate* function for picking the larger of two *4* digit numbers?!")
+
+Defining Parametric Invariants 
+------------------------------
+
+Lets take a step back from the types, and turn to a spot of handwaving.
+
+What's *really* going on with `maxInt`?
+
+Well, the function returns *one of* its two arguments `x` and `y`. 
+
+This means that if *both* arguments satisfy some property then the output
+*must* satisfy that property, *regardless of what that property was!*
+
+To teach LiquidHaskell to understand this notion of "regardless of
+property" we introduce the idea of **abstracting over refinements**
+or, if you prefer, parameterizing a type over its refinements.
+
+In particular, we type `maxInt` as
+
+\begin{code}
+{-@ maxInt :: forall 
 Prop>. Int
 -> Int
 -> Int
@-}
+\end{code}
+
+Here, the definition says explicitly: *for any property* `p` that is a
+property of `Int`, the function takes two inputs each of which satisfy `p`
+and returns an output that satisfies `p`. That is to say, `Int
` is 
+just an abbreviation for `{v:Int | (p v)}`
+
+**Digression: Whither Decidability?** 
+At first glance, it may appear that these abstract `p` have taken us into
+the realm of higher-order logics, where we must leave decidable checking
+and our faithful SMT companion at that door, and instead roll up our 
+sleeves for interactive proofs (not that there's anything wrong with that!) 
+Fortunately, that's not the case. We simply encode abstract refinements `p` 
+as *uninterpreted function symbols* in the refinement logic. 
+
+\begin{code} Uninterpreted functions are special symbols `p` which satisfy only the *congruence axiom*.
+forall X, Y. if (X = Y) then  p(X) = p(Y)
+\end{code}
+
+Happily, reasoning with such uninterpreted functions is quite decidable
+(thanks to Ackermann, yes, *that* Ackermann) and actually rather efficient.
+Thus, via SMT, LiquidHaskell happily verifies that `maxInt` indeed behaves
+as advertised: the input types ensure that both `(p x)` and `(p y)` hold 
+and hence that the returned value in either branch of `maxInt` satisfies 
+the refinement  `{v:Int | p(v)}`, thereby ensuring the output type. 
+
+By the same reasoning, we can define the `maximumInt` operator on lists:
+
+\begin{code}
+{-@ maximumInt :: forall 
 Prop>. x:[Int 
] -> Int 
@-}
+maximumInt (x:xs) = foldr maxInt x xs
+\end{code}
+
+Using Parametric Invariants
+---------------------------
+
+Its only useful to parametrize over invariants if there is some easy way 
+to *instantiate* the parameters. 
+
+Concretely, consider the function:
+
+\begin{code}
+{-@ maxEvens1 :: xs:[Int] -> {v:Int | (Even v)} @-}
+maxEvens1 xs = maximumInt xs''
+  where 
+    xs'      = [ x | x <- xs, isEven x]
+    xs''     = 0 : xs'
+\end{code}
+
+\begin{code} where the function `isEven` is from the Language.Haskell.Liquid.Prelude library:
+{- isEven :: x:Int -> {v:Bool | (Prop(v) <=> (Even x))} -}
+isEven   :: Int -> Bool
+isEven x = x `mod` 2 == 0
+\end{code}
+
+where the predicate `Even` is defined as
+
+\begin{code}
+{-@ predicate Even X = ((X mod 2) = 0) @-}
+\end{code}
+
+To verify that `maxEvens1` returns an even number, LiquidHaskell 
+
+1. infers that the list `(0:xs')` has type `[{v:Int | (Even v)}]`, 
+   that is, is a list of even numbers.
+
+2. automatically instantiates the *refinement* parameter of 
+   `maximumInt` with the concrete refinement `{\v -> (Even v)}` and so
+
+3. concludes that the value returned by `maxEvens1` is indeed `Even`.
+
+Parametric Invariants and Type Classes
+--------------------------------------
+
+Ok, lets be honest, the above is clearly quite contrived. After all,
+wouldn't you write a *polymorphic* `max` function? And having done so,
+we'd just get all the above goodness from old fashioned parametricity.
+
+\begin{code} That is to say, if we just wrote:
+max     :: forall a. a -> a -> a 
+max x y = if x > y then x else y
+
+maximum :: forall a. [a] -> a
+maximum (x:xs) = foldr max x xs
+\end{code}
+
+then we could happily *instantiate* the `a` with `{v:Int | v > 0}` or
+`{v:Int | (Even v)}` or whatever was needed at the call-site of `max`.
+Sigh. Perhaps we are still pining for Hindley-Milner.
+
+\begin{code} Well, if this was an ML perhaps we could but in Haskell, the types would be 
+(>)     :: (Ord a) => a -> a -> Bool
+max     :: (Ord a) => a -> a -> a
+maximum :: (Ord a) => [a] -> a
+\end{code}
+
+Our first temptation may be to furtively look over our shoulders, and
+convinced no one was watching, just pretend that funny `(Ord a)` business
+was not there, and quietly just treat `maximum` as `[a] -> a` and summon
+parametricity.
+
+That would be most unwise. We may get away with it with the harmless `Ord` but what of, say, `Num`. 
+
+\begin{code} Clearly a function 
+numCrunch :: (Num a) => [a] -> a
+\end{code}
+
+is not going to necessarily return one of its inputs as an output. 
+Thus, it is laughable to believe that `numCrunch` would, if given 
+a list of  of even (or positive, negative, prime, RGB, ...) integers, 
+return a even (or positive, negative, prime, RGB, ...) integer, since 
+the function might add or subtract or multiply or do other unspeakable
+things to the numbers in order to produce the output value.
+
+And yet, typeclasses are everywhere. 
+
+How could we possibly verify that
+
+\begin{code}
+{-@ maxEvens2 :: xs:[Int] -> {v:Int | (Even v) } @-}
+maxEvens2 xs = maximumPoly xs''
+  where 
+     xs'     = [ x | x <- xs, isEven x]
+     xs''    = 0 : xs'
+\end{code}
+
+where the helpers were in the usual `Ord` style?
+
+\begin{code}
+maximumPoly :: (Ord a) => [a] -> a
+maximumPoly (x:xs) = foldr maxPoly x xs
+
+maxPoly     :: (Ord a) => a -> a -> a 
+maxPoly x y = if x <= y then y else x
+\end{code}
+
+The answer: abstract refinements.
+
+First, via the same analysis as the monomorphic `Int` case, LiquidHaskell
+establishes that
+
+\begin{code}
+{-@ maxPoly :: forall 
 Prop>. 
+                 (Ord a) => x:a
 -> y:a
 -> a
 @-}
+\end{code}
+
+and hence, that
+
+\begin{code}
+{-@ maximumPoly :: forall 
 Prop>. 
+                     (Ord a) => x:[a
] -> a
     @-}
+\end{code}
+
+Second, at the call-site for `maximumPoly` in `maxEvens2` LiquidHaskell 
+instantiates the type variable `a` with `Int`, and the abstract refinement
+parameter `p` with `{\v -> (Even v)}` after which, the verification proceeds 
+as described earlier (for the `Int` case).
+
+And So
+------
+
+If you've courageously slogged through to this point then you've learnt
+that 
+
+1. Sometimes, choosing the right type can be quite difficult! 
+
+2. But fortunately, with *abstract refinements* we needn't choose, but 
+   can write types that are parameterized over the actual concrete 
+   invariants or refinements, which
+
+3. Can be instantiated at the call-sites i.e. users of the functions.
+
+We started with some really frivolous examples, but buckle your seatbelt 
+and hold on tight, because we're going to see some rather nifty things that
+this new technique makes possible, including induction, reasoning about
+memoizing functions, and *ordering* and *sorting* data. Stay tuned.
+
+[blog-dbz]:     /blog/2013/01/01/refinement-types-101.lhs/ 
+[blog-len]:     /blog/2013/01/31/safely-catching-a-list-by-its-tail.lhs/ 
+[blog-vec]:     /blog/2013/03/04/bounding-vectors.lhs/
+[blog-set]:     /blog/2013/03/26/talking/about/sets.lhs/
+[blog-zip]:     /blog/2013/05/16/unique-zipper.lhs/
diff --git a/docs/blog/2013-07-29-putting-things-in-order.lhs b/docs/blog/2013-07-29-putting-things-in-order.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-07-29-putting-things-in-order.lhs
@@ -0,0 +1,608 @@
+---
+layout: post
+title: "Putting Things In Order"
+date: 2013-07-29 16:12
+comments: true
+external-url:
+categories: abstract-refinements
+author: Niki Vazou and Ranjit Jhala
+published: true 
+demo: Order.hs
+---
+
+Hello again! Since we last met, much has happened that
+we're rather excited about, and which we promise to get
+to in the fullness of time.
+
+Today, however, lets continue with our exploration of
+abstract refinements. We'll see that this rather innocent 
+looking mechanism packs quite a punch, by showing how 
+it can encode various **ordering** properties of 
+recursive data structures.
+
+
+
+\begin{code}
+module PuttingThingsInOrder where
+
+import Prelude hiding (break)
+
+-- Haskell Type Definitions
+plusOnes                         :: [(Int, Int)]
+insertSort, mergeSort, quickSort :: (Ord a) => [a] -> [a]
+\end{code}
+
+Abstract Refinements
+--------------------
+
+\begin{code} Recall that *abstract refinements* are a mechanism that let us write and check types of the form
+maxInt :: forall 
 Prop>. Int
 -> Int
 -> Int

+\end{code}
+
+which states that the output of `maxInt` preserves 
+*whatever* invariants held for its two inputs as 
+long as both those inputs *also* satisfied those 
+invariants. 
+
+First, lets see how we can (and why we may want to) 
+abstractly refine data types. 
+
+Polymorphic Association Lists
+-----------------------------
+
+Suppose, we require a type for association lists. 
+Lets define one that is polymorphic over keys `k` 
+and values `v` 
+
+\begin{code}
+data AssocP k v = KVP [(k, v)]
+\end{code}
+
+Now, in a program, you might have multiple association
+lists, whose keys satisfy different properties. 
+For example, we might have a table for mapping digits 
+to the corresponding English string
+
+\begin{code}
+digitsP :: AssocP Int String
+digitsP = KVP [ (1, "one")
+              , (2, "two")
+              , (3, "three") ]
+\end{code}
+
+We could have a separate table for *sparsely* storing 
+the contents of an array of size `1000`.
+
+\begin{code}
+sparseVecP :: AssocP Int Double
+sparseVecP = KVP [ (12 ,  34.1 )
+                 , (92 , 902.83)
+                 , (451,   2.95)
+                 , (877,   3.1 )]
+\end{code}
+
+The **keys** used in the two tables have rather 
+different properties, which we may want to track 
+at compile time.
+
+- In `digitsP` the keys are between `0` and `9` 
+- In `sparseVecP` the keys are between `0` and `999`. 
+
+Well, since we had the foresight to parameterize 
+the key type in `AssocP`, we can express the above 
+properties by appropriately **instantiating** the type
+of `k` with refined versions
+
+\begin{code}
+{-@ digitsP :: AssocP {v:Int | (Btwn 0 v 9)} String @-}
+\end{code}
+
+and 
+
+\begin{code}
+{-@ sparseVecP :: AssocP {v:Int | (Btwn 0 v 1000)} Double @-}
+\end{code}
+
+where `Btwn` is just an alias 
+
+\begin{code}
+{-@ predicate Btwn Lo V Hi = (Lo <= V && V <= Hi) @-}
+\end{code}
+
+Monomorphic Association Lists
+-----------------------------
+
+Now, suppose that for one reason or another, we want to 
+specialize our association list so that the keys are of 
+type `Int`. 
+
+\begin{code}
+data Assoc v = KV [(Int, v)]
+\end{code}
+
+(We'd probably also want to exploit the `Int`-ness 
+in the implementation but thats a tale for another day.)
+
+Now, we have our two tables
+
+\begin{code}
+digits    :: Assoc String
+digits    = KV [ (1, "one")
+               , (2, "two")
+               , (3, "three") ]
+
+sparseVec :: Assoc Double
+sparseVec = KV [ (12 ,  34.1 )
+               , (92 , 902.83)
+               , (451,   2.95)
+               , (877,   3.1 )]
+\end{code}
+
+but since we didn't make the key type generic, it seems 
+we have no way to distinguish between the invariants of 
+the two sets of keys. Bummer!
+
+Abstractly Refined Data
+-----------------------
+
+We *could* define *two separate* types of association 
+lists that capture different invariants, but frankly, 
+thats rather unfortunate, as we'd then have to 
+duplicate the code the manipulates the structures. 
+Of course, we'd like to have (type) systems help 
+keep an eye on different invariants, but we'd 
+*really* rather not have to duplicate code to 
+achieve that end. Thats the sort of thing that
+drives a person to JavaScript ;-).
+
+Fortunately, all is not lost. 
+
+If you were paying attention [last time][blog-absref] 
+then you'd realize that this is the perfect job for 
+an abstract refinement, this time applied to a `data` 
+definition:
+
+\begin{code}
+{-@ data Assoc v 
 Prop> 
+      = KV (z :: [(Int
, v)]) @-} 
+\end{code}
+
+The definition refines the type for `Assoc` to introduce
+an abstract refinement `p` which is, informally speaking,
+a property of `Int`. The definition states that each `Int`
+in the association list in fact satisfies `p` as, `Int
`
+is an abbreviation for `{v:Int| (p v)}`.
+
+Now, we can *have* our `Int` keys and *refine* them too!
+For example, we can write:
+
+\begin{code}
+{-@ digits :: Assoc (String) <{\v -> (Btwn 0 v 9)}> @-}
+\end{code}
+
+to track the invariant for the `digits` map, and write
+
+\begin{code}
+{-@ sparseVec :: Assoc Double <{\v -> (Btwn 0 v 1000)}> @-}
+\end{code}
+
+Thus, we can recover (some of) the benefits of abstracting 
+over the type of the key by instead parameterizing the type
+directly over the possible invariants. We will have much 
+[more to say][blog-absref-vec] on association lists 
+(or more generally, finite maps) and abstract refinements, 
+but lets move on for the moment.
+
+Dependent Tuples
+----------------
+
+It is no accident that we have reused Haskell's function 
+type syntax to define abstract refinements (`p :: Int -> Prop`);
+interesting things start to happen if we use multiple parameters.
+
+Consider the function `break` from the Prelude. 
+
+\begin{code}
+break                   :: (a -> Bool) -> [a] -> ([a], [a])
+break _ xs@[]           =  (xs, xs)
+break p xs@(x:xs')
+           | p x        =  ([], xs)
+           | otherwise  =  let (ys, zs) = break p xs' 
+                           in (x:ys,zs)
+\end{code}
+
+From the comments in [Data.List][data-list], `break p xs`: 
+"returns a tuple where the first element is longest prefix (possibly empty)
+`xs` of elements that do not satisfy `p` and second element is the 
+remainder of the list."
+
+We could formalize the notion of the *second-element-being-the-remainder* 
+using sizes. That is, we'd like to specify that the length of the second 
+element equals the length of `xs` minus the length of the first element.  
+That is, we need a way to allow the refinement of the second element to 
+*depend on* the value in the first refinement.
+Again, we could define a special kind of tuple-of-lists-type that 
+has the above property *baked in*, but thats just not how we roll.
+
+\begin{code} Instead, lets use abstract refinements to give us **dependent tuples**
+data (a,b)
 b -> Prop> = (x:a, b
) 
+\end{code}
+
+Here, the abstract refinement takes two parameters, 
+an `a` and a `b`. In the body of the tuple, the 
+first element is named `x` and we specify that 
+the second element satisfies the refinement `p x`, 
+i.e. a partial application of `p` with the first element. 
+In other words, the second element is a value of type
+`{v:b | (p x v)}`.
+
+As before, we can instantiate the `p` in *different* ways. 
+For example the whimsical
+
+\begin{code}
+{-@ plusOnes :: [(Int, Int)<{\x1 x2 -> x2 = x1 + 1}>] @-}
+plusOnes = [(0,1), (5,6), (999,1000)]
+\end{code}
+
+and returning to the *remainder* property for  `break` 
+
+\begin{code}
+{-@ break :: (a -> Bool) -> x:[a] 
+          -> ([a], [a])<{\y z -> (Break x y z)}> @-}
+\end{code}
+
+using the predicate alias
+
+\begin{code}
+{-@ predicate Break X Y Z   = (len X) = (len Y) + (len Z) @-}
+\end{code}
+
+
+Abstractly Refined Lists
+------------------------
+
+Right, we've been going on for a bit. Time to put things *in order*.
+
+To recap: we've already seen one way to abstractly refine lists: 
+to recover a *generic* means of refining a *monomorphic* list 
+(e.g. the list of `Int` keys.) However, in that case we were 
+talking about *individual* keys.
+Next, we build upon the dependent-tuples technique we just 
+saw to use abstract refinements to relate *different* 
+elements inside containers.
+
+In particular, we can use them to specify that *every pair* 
+of elements inside the list is related according to some 
+abstract relation `p`. By *instantiating* `p` appropriately,
+we will be able to recover various forms of (dis) order. 
+
+\begin{code} Consider the refined definition of good old Haskell lists:
+data [a] 
 a -> Prop> where
+  | []  :: [a] 

+  | (:) :: h:a -> [a
]
 -> [a]

+\end{code}
+
+Whoa! Thats a bit of a mouthful. Lets break it down.
+
+* The type is parameterized with a refinement `p :: a -> a -> Prop` 
+  Think of `p` as a *binary relation* over the `a` values comprising
+  the list.
+
+* The empty list `[]` is a `[]
`. Clearly, the empty list has no
+  elements whatsoever and so every pair is trivially, or rather, 
+  vacuously related by `p`.
+
+* The cons constructor `(:)` takes a head `h` of type `a` and a tail
+  of `a
` values, each of which is *related to* `h` **and** which 
+  (recursively) are pairwise related `[...]
` and returns a list where 
+  *all* elements are pairwise related `[a]
`.
+
+Pairwise Related
+----------------
+
+Note that we're being a bit sloppy when we say *pairwise* related.
+
+\begin{code} What we really mean is that if a list
+[x1,...,xn] :: [a]

+\end{code}
+
+then for each `1 <= i < j <= n` we have `(p xi xj)`.
+
+\begin{code} To see why, consider the list
+[x1, x2, x3, ...] :: [a]

+\end{code}
+
+\begin{code} This list unfolds into a head and tail 
+x1                :: a
+[x2, x3,...]      :: [a
]

+\end{code}
+
+\begin{code} The above tail unfolds into
+x2                :: a

+[x3, ...]         :: [a
]

+\end{code}
+
+\begin{code} And finally into 
+x3                :: a

+[...]             :: [a
]

+\end{code}
+
+That is, each element `xj` satisfies the refinement 
+`(p xi xj)` for each `i < j`.
+
+Using Abstractly Refined Lists
+------------------------------
+
+Urgh. *Math is hard!*  
+
+Lets see how we can *program* with these funnily refined lists.
+
+For starters, we can define a few helpful type aliases.
+
+\begin{code}
+{-@ type IncrList a = [a]<{\xi xj -> xi <= xj}> @-}      
+{-@ type DecrList a = [a]<{\xi xj -> xi >= xj}> @-}
+{-@ type UniqList a = [a]<{\xi xj -> xi /= xj}> @-}
+\end{code}
+
+As you might expect, an `IncrList` is a list of values in *increasing* order:
+
+\begin{code}
+{-@ whatGosUp :: IncrList Integer @-}
+whatGosUp = [1,2,3]
+\end{code}
+
+Similarly, a `DecrList` contains its values in *decreasing* order:
+
+\begin{code}
+{-@ mustGoDown :: DecrList Integer @-}
+mustGoDown = [3,2,1]
+\end{code}
+
+My personal favorite though, is a `UniqList` which has *no duplicates*:
+
+\begin{code}
+{-@ noDuplicates :: UniqList Integer @-}
+noDuplicates = [1,3,2]
+\end{code}
+
+Sorting Lists
+-------------
+
+Its all very well to *specify* lists with various kinds of invariants. 
+The question is, how easy is it to *establish* these invariants?
+
+Lets find out, by turning inevitably to that staple of all forms of
+formal verification: your usual textbook sorting procedures.
+
+**Insertion Sort**
+
+First up: insertion sort. Well, no surprises here:
+
+\begin{code}
+{-@ insertSort    :: (Ord a) => xs:[a] -> (IncrList a) @-}
+insertSort []     = []
+insertSort (x:xs) = insert x (insertSort xs) 
+\end{code}
+
+The hard work is done by `insert` which places an 
+element into the correct position of a sorted list
+
+\begin{code}
+insert y []     = [y]
+insert y (x:xs) 
+  | y <= x      = y : x : xs 
+  | otherwise   = x : insert y xs
+\end{code}
+
+LiquidHaskell infers that if you give `insert` an element 
+and a sorted list, it returns a sorted list.
+
+\begin{code}
+{-@ insert :: (Ord a) => a -> IncrList a -> IncrList a @-}
+\end{code}
+
+If you prefer the more Haskelly way of writing insertion sort, 
+i.e. with a `foldr`, that works too. Can you figure out why?
+
+\begin{code}
+{-@ insertSort' :: (Ord a) => [a] -> IncrList a @-}
+insertSort' xs  = foldr insert [] xs
+\end{code}
+
+**Merge Sort**
+
+Well, you know the song goes. First, we write a function 
+that **splits** the input into two parts:
+
+\begin{code}
+split          :: [a] -> ([a], [a])
+split (x:y:zs) = (x:xs, y:ys) 
+  where 
+    (xs, ys)   = split zs
+split xs       = (xs, [])
+\end{code}
+
+Then we need a function that **merges** two (sorted) lists
+
+\begin{code}
+merge xs []         = xs
+merge [] ys         = ys
+merge (x:xs) (y:ys) 
+  | x <= y          = x : merge xs (y:ys)
+  | otherwise       = y : merge (x:xs) ys
+\end{code}
+
+LiquidHaskell deduces that if both inputs are 
+ordered, then so is the output.
+
+\begin{code}
+{-@ merge :: (Ord a) => IncrList a 
+                     -> IncrList a 
+                     -> IncrList a 
+  @-}
+\end{code}
+
+Finally, using the above functions we write `mergeSort`:
+
+\begin{code}
+{-@ mergeSort :: (Ord a) => [a] -> IncrList a @-}
+mergeSort []  = []
+mergeSort [x] = [x]
+mergeSort xs  = merge (mergeSort ys) (mergeSort zs) 
+  where 
+    (ys, zs)  = split xs
+\end{code}
+
+Lets see how LiquidHaskell proves the output type. 
+
++ The first two cases are trivial: for an empty 
+  or singleton list, we can vacuously instantiate 
+  the abstract refinement with *any* concrete 
+  refinement.
+
++ For the last case, we can inductively assume 
+ `mergeSort ys` and `mergeSort zs` are sorted 
+  lists, after which the type inferred for 
+  `merge` kicks in, allowing LiquidHaskell to conclude
+  that the output is also sorted.
+
+**Quick Sort**
+
+The previous two were remarkable because they were, well, quite *unremarkable*. 
+Pretty much the standard textbook implementations work *as is*. 
+Unlike the [classical][omega-sort] [developments][hasochism] 
+using indexed types we don't have to define any auxiliary 
+types for increasing lists, or lists whose value is in a 
+particular range, or any specialized `cons` operators and 
+so on.
+
+With *quick sort* we need to do a tiny bit of work.
+
+
+\begin{code} We would like to define `quickSort` as
+{-@ quickSort'    :: (Ord a) => [a] -> IncrList a @-}
+quickSort' []     = []
+quickSort' (x:xs) = lts ++ (x : gts) 
+  where 
+    lts           = quickSort' [y | y <- xs, y < x]
+    gts           = quickSort' [z | z <- xs, z >= x]
+\end{code}
+
+But, if you try it out, you'll see that LiquidHaskell 
+*does not approve*. What could possibly be the trouble?
+
+The problem lies with *append*. What type do we give `++`? 
+
+\begin{code} We might try something like
+(++) :: IncrList a -> IncrList a -> IncrList a
+\end{code}
+
+\begin{code} but of course, this is bogus, as 
+[1,2,4] ++ [3,5,6]
+\end{code}
+
+is decidedly not an `IncrList`!
+
+Instead, at this particular use of `++`, there is
+an extra nugget of information: there is a *pivot*
+element `x` such that every element in the first 
+argument is less than `x` and every element in 
+the second argument is greater than `x`. 
+
+There is no way we can give the usual append `++` 
+a type that reflects the above as there is no pivot 
+`x` to refer to. Thus, with a heavy heart, we must
+write a specialized pivot-append that uses this fact:
+
+\begin{code}
+pivApp piv []     ys  = piv : ys
+pivApp piv (x:xs) ys  = x   : pivApp piv xs ys
+\end{code}
+
+Now, LiquidHaskell infers that 
+
+\begin{code}
+{-@ pivApp :: piv:a 
+           -> IncrList {v:a | v <  piv} 
+           -> IncrList {v:a | v >= piv} 
+           -> IncrList a 
+  @-}
+\end{code}
+
+And we can use `pivApp` to define `quickSort' simply as:
+
+\begin{code}
+{-@ quickSort    :: (Ord a) => [a] -> IncrList a @-}
+quickSort []     = []
+quickSort (x:xs) = pivApp x lts gts 
+  where 
+    lts          = quickSort [y | y <- xs, y < x ]
+    gts          = quickSort [z | z <- xs, z >= x]
+\end{code}
+
+Really Sorting Lists
+--------------------
+
+The convenient thing about our encoding is that the 
+underlying datatype is plain Haskell lists. 
+This yields two very concrete benefits. 
+First, as mentioned before, we can manipulate 
+sorted lists with the same functions we'd use 
+for regular lists.
+Second, by decoupling (or rather, parameterizing)
+the relation or property or invariant from the actual 
+data structure we can plug in different invariants, 
+sometimes in the *same* program.
+
+To see why this is useful, lets look at a *real-world* 
+sorting algorithm: the one used inside GHC's 
+`Data.List` [module][data-list].
+
+\begin{code}
+sort :: (Ord a) => [a] -> [a]
+sort = mergeAll . sequences
+  where
+    sequences (a:b:xs)
+      | a `compare` b == GT = descending b [a]  xs
+      | otherwise           = ascending  b (a:) xs
+    sequences [x] = [[x]]
+    sequences []  = [[]]
+
+    descending a as (b:bs)
+      | a `compare` b == GT = descending b (a:as) bs
+    descending a as bs      = (a:as): sequences bs
+
+    ascending a as (b:bs)
+      | a `compare` b /= GT = ascending b (\ys -> as (a:ys)) bs
+    ascending a as bs       = as [a]: sequences bs
+
+    mergeAll [x] = x
+    mergeAll xs  = mergeAll (mergePairs xs)
+
+    mergePairs (a:b:xs) = merge a b: mergePairs xs
+    mergePairs [x]      = [x]
+    mergePairs []       = []
+\end{code}
+
+The interesting thing about the procedure is that it 
+generates some intermediate lists that are increasing 
+*and* others that are decreasing, and then somehow
+miraculously whips this whirlygig into a single 
+increasing list.
+
+Yet, to check this rather tricky algorithm with 
+LiquidHaskell we need merely write:
+
+\begin{code}
+{-@ sort :: (Ord a) => [a] -> IncrList a  @-}
+\end{code}
+
+
+
+[blog-absref]:     /blog/2013/06/3/abstracting-over-refinements.lhs/
+[blog-absref-vec]: http://goto.ucsd.edu/~rjhala/liquid/abstract_refinement_types.pdf
+[data-list]:        http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Data-List.html#sort
+[omega-sort]:      http://web.cecs.pdx.edu/~sheard/Code/InsertMergeSort.html
+[hasochism]:       https://personal.cis.strath.ac.uk/conor.mcbride/pub/hasochism.pdf
+
diff --git a/docs/blog/2013-11-23-telling_lies.lhs b/docs/blog/2013-11-23-telling_lies.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-11-23-telling_lies.lhs
@@ -0,0 +1,128 @@
+---
+layout: post
+title: "LiquidHaskell Caught Telling Lies!"
+date: 2013-11-23 16:12
+comments: true
+external-url:
+categories: termination
+author: Ranjit Jhala, Niki Vazou 
+published: true
+demo: TellingLies.hs
+---
+
+One crucial goal of a type system is to provide the guarantee, 
+memorably phrased by Milner as *well-typed programs don't go wrong*. 
+The whole point of LiquidHaskell (and related systems) is to provide
+the above guarantee for expanded notions of "going wrong". 
+All this time, we've claimed (and believed) that LiquidHaskell 
+provided such a guarantee.
+
+We were wrong. 
+
+LiquidHaskell tells lies.
+
+
+
+\begin{code}
+{-@ LIQUID "--no-termination" @-}
+
+module TellingLies where
+
+import Language.Haskell.Liquid.Prelude (liquidError)
+
+divide  :: Int -> Int -> Int
+foo     :: Int -> Int
+explode :: Int
+\end{code}
+
+To catch LiquidHaskell red-handed, we require
+
+1. a notion of **going wrong**,
+2. a **program** that clearly goes wrong, and the smoking gun,
+3. a **lie** from LiquidHaskell that the program is safe.
+
+The Going Wrong
+---------------
+
+Lets keep things simple with an old fashioned `div`-ision operator.
+A division by zero would be, clearly *going wrong*.
+
+To alert LiquidHaskell to this possibility, we encode "not going wrong"
+with the precondition that the denominator be  non-zero.
+
+\begin{code}
+{-@ divide :: n:Int -> d:{v:Int | v /= 0} -> Int @-}
+divide n 0 = liquidError "no you didn't!"
+divide n d = n `div` d
+\end{code}
+
+The Program 
+-----------
+
+Now, consider the function `foo`.
+
+\begin{code}
+{-@ foo :: n:Int -> {v:Nat | v < n} @-}
+foo n | n > 0     = n - 1
+      | otherwise = foo n
+\end{code}
+
+Now, `foo` should only be called with strictly positive values. 
+In which case, the function returns a `Nat` that is strictly 
+smaller than the input. 
+The function diverges when called with `0` or negative inputs. 
+
+Note that the signature of `foo` is slightly different, but 
+nevertheless, legitimate, as *when* the function returns an 
+output, the output is indeed a `Nat` that is *strictly less than* 
+the input parameter `n`. Hence, LiquidHaskell happily checks 
+that `foo` does indeed satisfy its given type.
+
+So far, nothing has gone wrong either in the program, or 
+with LiquidHaskell, but consider this innocent little 
+function:
+
+\begin{code}
+explode = let z = 0
+          in  (\x -> (2013 `divide` z)) (foo z)
+\end{code}
+
+Thanks to *lazy evaluation*, the call to `foo` is ignored,
+and hence evaluating `explode` leads to a crash! Ugh!
+
+The Lie
+-------
+
+However, LiquidHaskell produces a polyannish prognosis and 
+cheerfully declares the program *safe*. 
+
+Huh?
+
+Well, LiquidHaskell deduces that
+
+a. `z == 0`  from the binding,
+b. `x : Nat` from the output type for `foo`
+c. `x <  z`  from the output type for `foo`
+
+\begin{code} Of course, no such `x` exists! Or, rather, the SMT solver reasons
+    z == 0 && x >= 0 && x < z  => z /= 0
+\end{code}
+
+as the hypotheses are inconsistent. In other words, LiquidHaskell 
+deduces that the call to `divide` happens in an *impossible* environment,
+i.e. is dead code, and hence, the program is safe.
+
+In our defence, the above, sunny prognosis is not *totally misguided*. 
+Indeed, if Haskell was like ML and had *strict evaluation* then 
+indeed the program would be safe in that we would *not* go wrong 
+i.e. would not crash with a divide-by-zero.  
+
+But of course, thats a pretty lame excuse, since Haskell doesn't have 
+strict semantics. So looks like LiquidHaskell (and hence, we) 
+have been caught red-handed.
+
+Well then, is there a way to prevent LiquidHaskell from telling lies?
+That is, can we get Milner's *well-typed programs don't go wrong* 
+guarantee under lazy evaluation? 
+
+Thankfully, there is.
diff --git a/docs/blog/2013-12-01-getting-to-the-bottom.lhs b/docs/blog/2013-12-01-getting-to-the-bottom.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-12-01-getting-to-the-bottom.lhs
@@ -0,0 +1,103 @@
+---
+layout: post
+title: "Getting To the Bottom of The Lies"
+date: 2013-12-01 16:12
+comments: true
+external-url:
+categories: termination
+author: Ranjit Jhala, Niki Vazou
+published: true
+demo: BasicTermination.hs
+---
+
+[Previously][ref-lies], we caught LiquidHaskell telling a lie. Today, lets try to
+get to the bottom of this mendacity, in order to understand how we can ensure
+that it always tells the truth.
+
+
+
+\begin{code}
+module GettingToTheBottom where
+\end{code}
+The Truth Lies At the Bottom
+----------------------------
+
+To figure out how we might prevent such mendacity, lets try to understand 
+whats really going on. We need to go back to the beginning.
+
+\begin{code} Recall that the refinement type:
+{v:Int | 0 <= v}
+\end{code}
+
+is supposed to denote the set of `Int` values that are greater than `0`.
+
+\begin{code} Consider a function:
+fib :: {n:Int | 0 <= n} -> {v:Int | 0 <= v}
+fib n = e
+\end{code}
+
+Intuitively, the type signature states that when checking the body `e` 
+we can **assume** that `0 <= n`. 
+
+This is indeed the case with **strict** evaluation, as we are guaranteed 
+that `n` will be evaluated before `e`. Thus, either:
+
+1. `n` diverges and so we don't care about `e` as we won't evaluate it, or,
+2. `n` is a non-negative value.
+
+Thus, either way, `e` is only evaluated in a context where `0 <= n`.
+
+But of course, this is not the case with **lazy** evaluation, as we may 
+well start evaluating `e` without evaluating `n`. Indeed, we may *finish*
+evaluating `e` without evaluating `n`. 
+
+Now of course, we know that *if* `n` is evaluated, it will yield a 
+non-negative value, but if it is not (or does not) evaluate to a
+value, we **cannot assume** that the rest of the computation is dead 
+(as with eager evaluation). 
+
+\begin{code} Thus, really with lazy evaluation, the refinement type `{n:Int | 0 <= n}` *actually* means:
+(n = _|_) || (0 <= n)
+\end{code}
+
+Keeping LiquidHaskell Honest
+----------------------------
+
+One approach to forcing LiquidHaskell to telling the truth is to force 
+it to *always* split cases and reason about `_|_`.
+
+\begin{code} Lets revisit `explode`
+explode = let z = 0
+          in  (\x -> 2013 `divide` z) (foo z)
+\end{code}
+
+\begin{code}This prevents the cheerful but bogus prognosis that `explode` above was safe, because the SMT solver cannot prove that at the call to `divide` 
+    z == 0 && (x = _|_ || (x >= 0 && x < z))  => z /= 0
+\end{code}
+
+PIC: PESSIMISTIC-ALWAYS-NO
+
+But alas, this cure is worse than the disease. Effectively it would end up
+lobotomizing LiquidHaskell making it unable to prove even trivial things like:
+
+\begin{code}_
+{-@ trivial    :: x:Int -> y:Int -> {pf: () | x < y} -> Int @-}
+trivial x y pf = liquidAssert (x < y) 10
+\end{code}
+
+\begin{code}as the corresponding SMT query
+    (pf = _|_ || x < y) => (x < y)
+\end{code}
+
+is, thanks to the pesky `_|_`, not valid. 
+
+Terminating The Bottom
+----------------------
+
+Thus, to make LiquidHaskell tell the truth while also not just pessimistically 
+rejecting perfectly good programs, we need a way to get rid of the `_|_`. That 
+is, we require a means of teaching LiquidHaskell to determine when a value
+is *definitely* not bottom. 
+
+In other words, we need to teach LiquidHaskell how to prove that a computation 
+definitely terminates.
diff --git a/docs/blog/2013-12-02-getting-to-the-bottom.lhs b/docs/blog/2013-12-02-getting-to-the-bottom.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-12-02-getting-to-the-bottom.lhs
@@ -0,0 +1,103 @@
+---
+layout: post
+title: "Getting To the Bottom"
+date: 2013-12-02 16:12
+comments: true
+external-url:
+categories: termination
+author: Ranjit Jhala, Niki Vazou
+published: true 
+demo: TellingLies.hs
+---
+
+[Previously][ref-lies], we caught LiquidHaskell telling a lie. Today, lets try to
+get to the bottom of this mendacity, in order to understand how we can ensure
+that it always tells the truth.
+
+
+
+\begin{code}
+module GettingToTheBottom where
+\end{code}
+
+The Truth Lies At the Bottom
+----------------------------
+
+To figure out how we might prevent falsehoods, lets try to understand 
+whats really going on. We need to go back to the beginning.
+
+\begin{code} Recall that the refinement type:
+{v:Int | 0 <= v}
+\end{code}
+
+is supposed to denote the set of `Int` values that are greater than `0`.
+
+\begin{code} Consider a function:
+fib :: {n:Int | 0 <= n} -> {v:Int | 0 <= v}
+fib n = e
+\end{code}
+
+Intuitively, the type signature states that when checking the body `e` 
+we can **assume** that `0 <= n`. 
+
+This is indeed the case with **strict** evaluation, as we are guaranteed 
+that `n` will be evaluated before `e`. Thus, either:
+
+1. `n` diverges and so we don't care about `e` as we won't evaluate it, or,
+2. `n` is a non-negative value.
+
+Thus, either way, `e` is only evaluated in a context where `0 <= n`.
+
+But this is *not* the case with **lazy** evaluation, as we may 
+well start evaluating `e` without evaluating `n`. Indeed, we may
+*finish* evaluating `e` without evaluating `n`. 
+
+Of course, *if* `n` is evaluated, it will yield a non-negative value, 
+but if it is not (or does not) evaluate to a value, we **cannot assume** 
+that the rest of the computation is dead (as with eager evaluation). 
+
+\begin{code} That is, with lazy evaluation, the refinement type `{n:Int | 0 <= n}` *actually* means:
+(n = _|_) || (0 <= n)
+\end{code}
+
+Keeping LiquidHaskell Honest
+----------------------------
+
+One approach to forcing LiquidHaskell to telling the truth is to force 
+it to *always* split cases and reason about `_|_`.
+
+\begin{code} Lets revisit `explode`
+explode = let z = 0
+          in  (\x -> 2013 `divide` z) (foo z)
+\end{code}
+
+\begin{code}The case splitting prevents the cheerful but bogus prognosis that `explode` above was safe, because the SMT solver cannot prove that at the call to `divide` 
+    z == 0 && (x = _|_ || (x >= 0 && x < z))  => z /= 0
+\end{code}
+
+But alas, this cure is worse than the disease. 
+It would end up lobotomizing LiquidHaskell making it unable to prove even trivial things like:
+
+\begin{code}_
+{-@ trivial    :: x:Int -> y:Int -> {pf: () | x < y} -> Int @-}
+trivial x y pf = liquidAssert (x < y) 10
+\end{code}
+
+\begin{code}as the corresponding SMT query
+    (pf = _|_ || x < y) => (x < y)
+\end{code}
+
+is, thanks to the pesky `_|_`, not valid. 
+
+Terminating The Bottom
+----------------------
+
+Thus, to make LiquidHaskell tell the truth while also not just pessimistically 
+rejecting perfectly good programs, we need a way to get rid of the `_|_`. That 
+is, we require a means of teaching LiquidHaskell to determine when a value
+is *definitely* not bottom. 
+
+In other words, we need to teach LiquidHaskell how to prove that a computation 
+definitely terminates.
+
+[ref-lies]:  /blog/2013/11/23/telling_lies.lhs/ 
diff --git a/docs/blog/2013-12-09-checking-termination.lhs b/docs/blog/2013-12-09-checking-termination.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-12-09-checking-termination.lhs
@@ -0,0 +1,173 @@
+---
+layout: post
+title: "Checking Termination"
+date: 2013-12-09 16:12
+comments: true
+external-url:
+categories: termination
+author: Niki Vazou
+published: true 
+demo: Termination.hs
+---
+
+As explained in the [last][ref-lies] [two][ref-bottom] posts, we need a termination
+checker to ensure that LiquidHaskell is not tricked by divergent, lazy
+computations into telling lies. Happily, it turns out that with very 
+little retrofitting, and a bit of jiu jitsu, we can use refinements 
+themselves to prove termination!
+
+
+
+

+   

+       Falling Down
+       

+       

+       

+       How do you prove this fellow will stop falling?
+       

+       

+       

+   

+

+
+
+
+\begin{code}
+module Termination where
+
+import Prelude     hiding (sum)
+import Data.Vector hiding (sum)
+\end{code}
+
+Lets first see how LiquidHaskell proves termination on simple 
+recursive functions, and then later, we'll see how to look at 
+fancier cases.
+
+Looping Over Vectors
+--------------------
+
+Lets write a bunch of little functions that operate on 1-dimensional vectors
+
+\begin{code}
+type Val = Int
+type Vec = Vector Val
+\end{code}
+
+Next, lets write a simple recursive function that loops over to add up
+the first `n` elements of a vector:
+
+\begin{code}
+sum     :: Vec -> Int -> Val
+sum a 0 = 0
+sum a n = (a ! (n-1)) + sum a (n-1)
+\end{code}
+
+Proving Termination By Hand(waving) 
+-----------------------------------
+
+Does `sum` terminate? 
+
+First off, it is apparent that if we call `sum` with a
+negative `n` then it **will not** terminate. 
+Thus, we should only call `sum` with non-negative integers.
+
+Fine, lets assume `n` is non-negative. Why then does it terminate?
+
+Intuitively,
+
+1. If `n` is `0` then it trivially returns with the value `0`.
+
+2. If `n` is non-zero, then we recurse *but* with a strictly smaller `n` ...
+
+3. ... but ultimately hit `0` at which point it terminates.
+
+Thus we can, somewhat more formally, prove termination by induction on `n`. 
+
+**Base Case** `n == 0` The function clearly terminates for the base case input of `0`.
+
+**Inductive Hypothesis** Lets assume that `sum` terminates on all `0 <= k < n`.
+
+**Inductive Step** Prove that `sum n` only recursively invokes `sum` with values that
+satisfy the inductive hypothesis and hence, which terminate.
+
+This reasoning suffices to convince ourselves that `sum i` terminates for 
+every natural number `i`. That is, we have shown that `sum` terminates 
+because a *well-founded metric* (i.e., the natural number `i`) is decreasing 
+at each recursive call.
+
+Proving Termination By Types
+----------------------------
+
+We can teach LiquidHaskell to prove termination by applying the same reasoning 
+as above, by rephrasing it in terms of refinement types.
+
+First, we specify that the input is restricted to the set of `Nat`ural numbers
+
+\begin{code}
+{-@ sum :: a:Vec -> {v:Nat | v < (vlen a)} -> Val @-}
+\end{code}
+
+where recall that `Nat` is just the refinement type `{v:Int | v >= 0}`.
+
+Second, we typecheck the *body* of `sum` under an environment that
+restricts `sum` to only be called on inputs less than `n`, i.e. using
+an environment:
+
+-  `a   :: Vec`
+-  `n   :: Nat`
+-  `sum :: Vec -> n':{v:Nat | v < n} -> Val`
+
+This ensures that any (recursive) call in the body only calls `sum` 
+with inputs smaller than the current parameter `n`. Since its body 
+typechecks in this environment, i.e. `sum` is called with `n-1` which 
+is smaller than `n` and, in this case, a `Nat`, LiquidHaskell proves 
+that sum terminates for all `n`.
+
+For those keeping track at home, this is the technique of 
+[sized types](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.124.5589), 
+, expressed using refinements. Sized types themselves are an instance of 
+the classical method of proving termination via well founded metrics that 
+goes back, at least, to [Turing](http://www.turingarchive.org/viewer/?id=462&title=01b).
+
+Choosing the Correct Argument
+-----------------------------
+
+The example above is quite straightforward, and you might well wonder if this
+method works well for ``real-world" programs. With a few generalizations
+and extensions, and by judiciously using the wealth of information captured in
+refinement types, the answer is an emphatic, yes!
+
+Lets see one extension today.
+
+We saw that liquidHaskell can happily check that some Natural number is decreasing
+at each iteration, but it uses a naïve heuristic to choose which one -- for
+now, assume that it always chooses *the first* `Int` parameter.
+
+As you might imagine, this is quite simpleminded. 
+
+Consider, a tail-recursive implementation of `sum`:
+
+\begin{code}
+{-@ sum' :: a:Vec -> Val -> {v:Nat| v < (vlen a)} -> Val @-}
+sum' :: Vec -> Val -> Int -> Val
+sum' a acc 0 = acc + a!0 
+sum' a acc n = sum' a (acc + a!n) (n-1)
+\end{code}
+
+Clearly, the proof fails as liquidHaskell wants to prove that the `acc`umulator 
+is a `Nat`ural number that decreases at each iteration, neither of which may be
+true.
+
+\begin{code}The remedy is easy. We can point liquidHaskell to the correct argument `n` using a `Decrease` annotation: 
+{-@ Decrease sum' 3 @-}
+\end{code}
+which directs liquidHaskell to verify that the *third* argument (i.e., `n`) is decreasing. 
+With this hint, liquidHaskell will happily verify that `sum'` is indeed a terminating function.
+
+Thats all for now, next time we'll see how the basic technique can be extended
+to a variety of real-world settings.
+
+[ref-lies]:  /blog/2013/11/23/telling-lies.lhs/ 
+[ref-bottom]: /blog/2013/12/01/getting-to-the-bottom.lhs/
diff --git a/docs/blog/2013-12-14-gcd.lhs b/docs/blog/2013-12-14-gcd.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-12-14-gcd.lhs
@@ -0,0 +1,110 @@
+---
+layout: post
+title: "Termination Requires Refinements"
+date: 2013-12-14 16:12
+comments: true
+external-url:
+categories: termination 
+author: Niki Vazou
+published: true 
+demo: GCD.hs
+---
+
+We've seen how, in the presence of [lazy evaluation][ref-lies], refinements
+[require termination][ref-bottom]. [Next][ref-termination], we saw how 
+LiquidHaskell can be used to prove termination. 
+
+Today, lets see how **termination requires refinements**. 
+
+That is, a crucial feature of LiquidHaskell's termination prover is that it is 
+not syntactically driven, i.e. is not limited to say, structural recursion. 
+Instead, it uses the wealth of information captured by refinements that are
+at our disposal, in order to prove termination. 
+
+This turns out to be crucial in practice.
+As a quick toy example -- motivated by a question by [Elias][comment-elias] -- 
+lets see how, unlike purely syntax-directed (structural) approaches, 
+LiquidHaskell proves that recursive functions, such as Euclid's GCD 
+algorithm, terminates.
+
+
+
+

+

+

+
+

+  

+  Euclid
+       

+       

+       

+       With LiquidHaskell, Euclid wouldn't have had to wave his hands.
+       

+       

+       

+  

+

+
+\begin{code}
+module GCD where
+
+import Prelude hiding (gcd, mod)
+
+mod :: Int -> Int -> Int
+gcd :: Int -> Int -> Int
+\end{code}
+
+The [Euclidean algorithm][ref-euclidean] is one of the oldest numerical algorithms 
+still in common use and calculates the the greatest common divisor (GCD) of two 
+natural numbers `a` and `b`.
+
+Assume that `a > b` and consider the following implementation of `gcd`
+
+\begin{code}
+{-@ gcd :: a:Nat -> b:{v:Nat | v < a} -> Int @-}
+gcd a 0 = a
+gcd a b = gcd b (a `mod` b)
+\end{code}
+
+From our previous post, to prove that `gcd` is terminating, it suffices to prove
+that the first argument decreases as each recursive call.
+
+By `gcd`'s type signature, `a < b` holds at each iteration, thus liquidHaskell 
+will happily discharge the terminating condition.
+
+The only condition left to prove is that `gcd`'s second argument, ie., `a `mod`
+b` is less that `b`. 
+
+This property follows from the behavior of the `mod` operator.
+
+So, to prove `gcd` terminating, liquidHaskell needs a refined signature for 
+`mod` that captures this behavior, i.e., that for any `a` and `b` the value 
+`mod a b` is less than `b`. Fortunately, we can stipulate this via a refined
+type:
+
+\begin{code}
+{-@ mod :: a:Nat -> b:{v:Nat| 0 < v} -> {v:Nat | v < b} @-}
+mod a b
+  | a < b = a
+  | otherwise = mod (a - b) b
+\end{code}
+
+\begin{code}Euclid's original version of `gcd` is different
+gcd' :: Int -> Int -> Int
+gcd' a b | a == b = a
+         | a >  b = gcd' (a - b) b 
+         | a <  b = gcd' a (b - a) 
+\end{code}
+
+Though this version is simpler, turns out that LiquidHaskell needs 
+a more sophisticated mechanism, called **lexicographic ordering**, to 
+prove it terminates. Stay tuned!
+
+
+[ref-euclidean]:    http://en.wikipedia.org/wiki/Euclidean_algorithm
+[ref-termination]:  /blog/2013/12/09/checking-termination.lhs/ 
+[ref-lies]:  /blog/2013/11/23/telling-lies.lhs/ 
+[ref-bottom]: /blog/2013/12/01/getting-to-the-bottom.lhs/
+[comment-elias]: http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/blog/2013/12/09/checking-termination.lhs/#comment-1159606500
diff --git a/docs/blog/2013-12-22-measuring-the-size-of-structures.lhs b/docs/blog/2013-12-22-measuring-the-size-of-structures.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-12-22-measuring-the-size-of-structures.lhs
@@ -0,0 +1,184 @@
+---
+layout: post
+title: "Measuring the size of Structures"
+date: 2013-12-22 16:12
+comments: false
+external-url:
+categories: termination, measures
+author: Niki Vazou
+published: false
+demo: TheSizeOfStructures.hs
+---
+
+In the [previous][ref-termination] [two][ref-lexicographic] posts we saw how refinements can be used to prove
+termination. 
+In both posts functions recurse on integers.
+In Haskell the most common type of recursion is over recursive data structures.
+
+Today lets see how to prove termination on functions defined over
+recursive data structures.
+
+
+
+\begin{code}
+module TheSizeOfStructures where
+
+import Prelude hiding (map)
+\end{code}
+
+Does list map Terminate?
+------------------------
+
+Lets define a `List` structure
+
+\begin{code}
+infixr `C`
+data List a = N | C a (List a)
+\end{code}
+
+and a map function `lmap` on it
+
+\begin{code}
+lmap              :: (a -> b) -> (List a) -> (List b)
+lmap _ N          = N
+lmap f (x `C` xs) = f x `C` lmap f xs
+\end{code}
+
+Does `lmap` terminate?
+
+At each iteration `lmap` is called with the tail of the input list.
+So, the *length* of the list is decreasing at each iteration
+and 
+if the input list is finite, its length will reach `0` and `lmap` will terminate.
+
+Since the length of the list is a natural number, it is
+a *well-founded metric*.
+
+From the [previous][ref-lexicographic] [two][ref-termination] posts a
+well-founded metric that decreases at each iteration is all
+liquidHaskell needs to prove termination on a recursive function.
+
+Two things are left to do: teach liquidHaskell to
+
+1. compute the length of a List
+
+2. use this length as the decreasing metric that decreases in `lmap`.
+
+
+Express Termination Metric
+--------------------------
+
+First things first,
+we need to teach liquidHaskell to compute the length of the list.
+
+Remember *measures*?
+They were introduced in a [previous][ref-measure] post and in short measures
+provide a mechanism to define auxiliary properties on data
+values.
+
+Now we can define a measure `llen` than maps a list to its length:
+\begin{code}
+{-@ measure llen  :: (List a) -> Int
+    llen (N)      = 0
+    llen (C x xs) = 1 + (llen xs)
+  @-}
+\end{code}
+
+
+and then, inform liquidHaskell that this measure is *well-formed*, ie., cannot
+be negative:
+
+\begin{code}
+{-@ invariant {v:(List a) | (llen v) >= 0}@-}
+\end{code}
+
+
+Relate List with its length
+---------------------------
+
+The final step towards verification of `lmap`'s termination is to relate the List
+structure with its length `llen`.
+We can do this with the usual `data` annotation
+
+\begin{code}
+{-@ data List [llen] @-}
+\end{code}
+
+that informs the tool that `llen` measures the size of a list. 
+So each time the termination checker checks if a list is decreasing, it
+checks if its *default* size `llen` decreases. 
+
+
+Choosing the correct argument
+-----------------------------
+
+To prove termination liquidHaskell chooses one argument and tries to prove that
+is decreasing.
+But which argument? 
+It chooses the first one for which decreasing information exists.
+We have that for an integer to decrease its value should decrease 
+and we specified that a list decreases if its length `llen` decreases.
+
+In `lmap` there is no decreasing information for the function `f`, 
+so liquidHaskell will correclty guess that the list argument (ie., the second
+argument) should be
+decreasing.
+
+In a function that many arguments with decreasing information exist,
+liquidHaskell will naïvely choose the first one.
+
+As an example, the following `posSum` function could not be proven to terminate
+without our `Decrease` hint.
+
+\begin{code}
+{-@ Decrease posSum 2 @-}
+posSum                            :: Int -> (List Int) -> Int
+posSum acc N                      = acc
+posSum acc (x `C` xs) | x > 0     = posSum (acc + x) xs
+                      | otherwise = posSum (acc)     xs
+\end{code}
+
+Standard lists
+--------------
+You may think that all this is much work to prove that a function on a recursive
+structure is terminating.
+You have to both define the size of the structure and relate it with the
+structure.
+The good news is that this work is just performed once!
+
+Even better, for structures like standard lists liquidHaskell has done all this
+work for you!
+
+
+\begin{code} The standard list `[a]` comes with the build in measure 'len', defined as
+ measure len :: [a] -> Int
+ len ([])   = 1
+ len (x:xs) = 1 + (len xs)
+\end{code}
+
+Thus liquidHaskell will just prove that functions recursive on standard lists
+shall terminate:
+
+\begin{code}
+map          :: (a -> b) -> [a] -> [b]
+map _ []     = []
+map f (x:xs) = f x : map f xs
+\end{code}
+
+Today we shaw how to prove termination on functions recursive over a data
+structure.
+You need to 
+
+1. define the size of the structure
+
+2. associate this size with the structure.
+
+In the next post, 
+we shall see our final mechanism to prove termination: *decreasing expressions*
+Stay tuned!
+
+[ref-measure]:       /blog/2013/01/31/sately-catching-a-list-by-its-tails.lhs/
+[ref-lies]:          /blog/2013/11/23/telling-lies.lhs/ 
+[ref-bottom]:        /blog/2013/12/01/getting-to-the-bottom.lhs/
+[ref-termination]:   /blog/2013/12/08/termination-checking.lhs/
+[ref-lexicographic]: /blog/2013/12/15/lexicographic-termination.lhs/
diff --git a/docs/blog/2013-12-24-lexicographic-termination.lhs b/docs/blog/2013-12-24-lexicographic-termination.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-12-24-lexicographic-termination.lhs
@@ -0,0 +1,125 @@
+---
+layout: post
+title: "Lexicographic Termination"
+date: 2013-12-15 16:12
+comments: true
+external-url:
+categories: termination, lexicographic ordering
+author: Niki Vazou
+published: true 
+demo: LexicographicTermination.hs
+---
+
+[Previously][ref-termination] we saw how refinements can be used to prove termination
+and we promised to extend our termination checker to handle "real-word" programs.
+
+Keeping our promise, today we shall see a trick that allows liquidHaskell to prove termination on
+more recursive functions, namely *lexicographic termination*.
+
+
+
+
+
+Does Ackermann Function Terminate?
+----------------------------------
+
+Consider the famous [Ackermann
+function](http://en.wikipedia.org/wiki/Ackermann_function)
+
+\begin{code}
+{-@ ack :: m:Nat -> n:Nat -> Nat @-}
+ack :: Int -> Int -> Int
+ack m n
+    | m == 0          = n + 1
+    | m > 0 && n == 0 = ack (m-1) 1
+    | m > 0 && n >  0 = ack (m-1) (ack m (n-1))
+    | otherwise       = liquidError "Bad arguments!!!"
+\end{code}
+
+Does `ack` terminate?
+
+At each iteration
+
+1. Either `m` decreases, 
+
+2. or `m` remains the same and `n` decreases.
+
+Each time that `n` reaches `0`, `m` decreases, so `m` will
+eventaully reach `0` and `ack` will terminate.
+
+Expressed more technically the pair `(m, n)`
+decreases in the [lexicographic order](htpp://en.wikipedia/wiki/Lexicographic_order)
+on pairs, which is a well-ordering, ie.,
+we cannot go down infinitely many times.
+
+Express Termination Metric
+--------------------------
+
+Great! The pair `(m, n)` is a *well-founded metric* on the Ackermann function that decreases.
+From the [previous post][ref-termination] a well-founded metric is all
+liquidHaskell needs to prove termination.
+So, we should feed the tool with this information.
+
+Remember the `Decrease` token?
+We used it [previously][ref-termination]
+to specify which is the decreasing argument.
+Now, we will use it with more arguments to specify 
+our decreasing pair. So,
+
+\begin{code}
+{-@ Decrease ack 1 2 @-}
+\end{code}
+
+says that the decreasing metric is the pair of the first
+and the second arguments, 
+ie., the pair `(m, n)`.
+
+Finally, we will see how liquidHaskell uses this annotation to prove
+termination.
+
+Proving Termination By Types
+----------------------------
+
+Following once more our [previous post][ref-termination],
+liquidHaskell typechecks the *body* of `ack` under an environment that
+restricts `ack` to only be called on inputs *less than* `(m,n)`.
+This time "less than" referes not to ordering on natural numbers, but to lexicographic
+ordering
+, i.e., using
+an environment:
+
+-  `m   :: Nat`
+-  `n   :: Nat`
+-  `ack :: m':Nat -> n':{v:Nat | m' < m || (m' = m && v < n)} -> Nat`
+
+This ensures that any (recursive) call in the body only calls `ack` 
+with inputs smaller than the current parameter `(m, n)`. Since its body 
+typechecks in this environment, i.e. `ack` is called with smaller parameters, LiquidHaskell proves 
+that `ack` terminates.
+
+
+Someone may find the `Decrease` token annoying:
+if we insert another argument we should also update the decrease information.
+LiquidHaskell supports an alternative notation, 
+which lets you annotate the type signature 
+with a list of *decreasing expressions*.
+
+\begin{code} So, `ack` will also typecheck against the signature:
+{-@ ack :: m:Nat -> n:Nat -> Nat / [m, n] @-}
+\end{code}
+
+But what is the syntax of the decreasing expressions?
+Are they restricted to function parameters?
+No, but that is the subject of a next post!
+
+[ref-lies]:        /blog/2013/11/23/telling-lies.lhs/ 
+[ref-bottom]:      /blog/2013/12/01/getting-to-the-bottom.lhs/
+[ref-termination]: /blog/2013/12/08/termination-checking.lhs/
diff --git a/docs/blog/2013-12-29-decreasing-expressions.lhs b/docs/blog/2013-12-29-decreasing-expressions.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2013-12-29-decreasing-expressions.lhs
@@ -0,0 +1,153 @@
+---
+layout: post
+title: "Decreasing Expressions"
+date: 2013-12-29 16:12
+comments: true
+external-url:
+categories: termination, measures
+author: Niki Vazou
+published: false
+demo: DecreasingExpressions.hs
+---
+
+So far we proved that many recursive functions terminate.
+All the functions we used share a characteristic.
+They had (a list of) arguments that were (lexicographically) decreasing.
+
+What if no argument decreases?
+Consider an argument `i` that increases up to a higher value `hi`.
+As `i` increases the difference `hi - i` decreases and will eventually reach
+`0`.
+This difference "witnesses" termination.
+
+Today we will describe 
+the last mechanism liquidHaskell uses to prove termination:
+*decreasing expressions*
+that allow us to annotate functions with termination withnesses.
+
+
+
+\begin{code}
+module DecreasingExpressions where
+
+range ::          Int -> Int -> [Int]
+merge :: Ord a => [a] -> [a] -> [a]
+\end{code}
+
+Termination on Increasing Arguments
+-----------------------------------
+
+Consider a `range` function that takes two integers 
+a `lo`wer and a `hi`gher and returns the list `[lo, lo+1, ..., hi-1]`
+
+\begin{code}
+range lo hi | lo < hi   = lo : range (lo + 1) hi
+            | otherwise = []
+\end{code}
+
+Clearly the difference `hi - lo` is decreasing at each iteration and will
+eventually reach `0`.
+That is, `hi - lo` is a *well-founded metric* that decreases.
+[Previously][ref-termination] we discussed that this is exactly what 
+liquidHaksell needs to prove termination.
+
+Sadly, liquidHaskell cannot synthesize this metric.
+But provides a mechanism for the user to specify it.
+With *decreasing expressions*, 
+we can annotate the type of a recursive function
+with the termination witness. Thus
+
+\begin{code}
+{-@ range :: lo:Int -> hi:Int -> [Int] / [(hi - lo)] @-}
+\end{code}
+
+makes liquidHaskell 
+prove that `hi - lo` is a non-negative quantily that decreases at
+each iteration, 
+
+Termination on a Function of the Arguments
+------------------------------------------
+
+Lets illustrate the power of decreasing expressions with a more involved
+example.
+
+Consider the standard `merge` from the homonymous sorting function 
+
+\begin{code}
+merge (x:xs) (y:ys) 
+  | x < y     = x : merge xs     (y:ys)
+  | otherwise = y : merge (x:xs) ys
+\end{code}
+
+Does `merge` terminate?
+Well it does because at each iteration the sum of the lengths of the two
+arguments decreases. 
+Using liquidHaskell's build in [measure][ref-measure] `len`
+to get the length of a list, we can specify 
+`(len xs) + (len ys)`
+as the decreasing expression for `merge`
+
+\begin{code}_
+{-@ merge :: Ord a => xs:[a] -> ys:[a] -> [a] / [(len xs) + (len ys)] @-}
+\end{code}
+
+
+By the way, the power of liquidHaskell does not stop at proving `merge`
+terminating. 
+It extends to proving that given two sorted lists, `merge` will actually return
+a sorted list!
+
+[Some time ago][ref-slist], we represented Sorted Lists as
+\begin{code}
+{-@ type SL a = [a]<{\x v -> x <= v}> @-}
+\end{code}
+
+With this, all we need to prove that sortedness is preserved is to type `merge`
+as
+\begin{code}
+{-@ merge :: Ord a => xs:(SL a) -> ys:(SL a) -> (SL a) 
+           / [(len xs) + (len ys)]                                    @-}
+\end{code}
+
+
+Wrapping Up Termination Checking
+--------------------------------
+
+In the last couple of posts, we presented the mechanisms liquidHaskell uses to
+prove termination
+
+- We [started][ref-termination] with functions recursive on some natural namber
+  `i` that served as a decreasing metric to prove termination.
+
+- [Then][ref-lex], we used lexicographic ordering to prove termination on functions where
+  the decreasing metric constists of a list of arguments.
+
+- [After][ref-structures], we saw how to handle recursion on data structures: by proving the size of
+  this structure is decreasing, and
+
+- Today, we saw how to express more complicated decreasing metrics.
+
+Obviously liquidHaskell does not solve the halting problem: there do exist
+terminating functions that cannot be proven terminating.
+Worse, there do exist some cases of non-terminating functions tha fool
+liquidHaskell: 
+for instance, you can trick the tool 
+if you encode termination via [recursive types][ref-rec] or
+[references][ref-ref].
+We aim to soon address such corner cases.
+
+We claim that the above mechanisms suffice to prove 
+termination on numerous functions.
+Even *mutually recursive* ones, as we shall soon see.
+
+
+
+[ref-ref]:          https://github.com/ucsd-progsys/liquidhaskell/blob/master/tests/todo/Recursion1.hs
+[ref-rec]:          http://en.wikipedia.org/wiki/Fixed-point_combinator#Example_of_encoding_via_recursive_types 
+[ref-lies]:        /blog/2013/11/23/telling-lies.lhs/ 
+[ref-bottom]:      /blog/2013/12/01/getting-to-the-bottom.lhs/
+[ref-termination]: /blog/2013/12/08/termination-checking.lhs/
+[ref-lex]:         /blog/2013/12/15/lexicographic-termination.lhs/
+[ref-structures]:  /blog/2013/12/22/measuring-the-size-of-structures.lhs/
+[ref-measure]:     /blog/2013/01/31/safely-catching-a-list-by-its-tail.lhs/
+[ref-slist]:       /blog/2013/07/29/putting-things-in-order.lhs/
diff --git a/docs/blog/2014-02-11-the-advantage-of-measures.lhs b/docs/blog/2014-02-11-the-advantage-of-measures.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2014-02-11-the-advantage-of-measures.lhs
@@ -0,0 +1,375 @@
+---
+layout: post
+title: "The Advantage of Measures"
+date: 2014-02-11
+author: Eric Seidel
+published: true
+comments: true
+external-url:
+categories: basic measures
+---
+
+Yesterday someone asked on [Reddit][] how one might define GHC's [OrdList][] 
+in a way that statically enforces its three key invariants. The accepted
+solution required rewriting `OrdList` as a `GADT` indexed by a proof of
+*emptiness* (which is essentially created by a run-time check), and used
+the new Closed Type Families extension in GHC 7.8 to define a type-level 
+join of the Emptiness index.
+
+Today, let's see a somewhat more direct way of tackling this problem in 
+LiquidHaskell, in which we need not change a single line of code 
+(well.. maybe one), and need not perform any dynamic checks. 
+
+
+
+
+
+The OrdList Type
+----------------
+
+The `OrdList` type is defined as follows:
+
+\begin{code}
+data OrdList a
+  = None
+  | One a
+  | Many [a]        -- Invariant: non-empty
+  | Cons a (OrdList a)
+  | Snoc (OrdList a) a
+  | Two (OrdList a) -- Invariant: non-empty
+        (OrdList a) -- Invariant: non-empty
+\end{code}
+
+As indicated by the comments the key invariants are that:
+
+* `Many` should take a *non-empty* list,
+* `Two` takes two non-empty `OrdList`s. 
+
+What is a Non-Empty OrdList?
+----------------------------
+
+To proceed, we must tell LiquidHaskell what non-empty means. We do this
+with a [measure][] that describes the *number of elements* in a structure.
+When this number is strictly positive, the structure is non-empty.
+
+\begin{code} We've previously seen how to measure the size of a list.
+measure len :: [a] -> Int
+len ([])   = 0
+len (x:xs) = 1 + (len xs)
+\end{code}
+
+We can use the same technique to measure the size of an `OrdList`.
+
+\begin{code}
+{-@ measure olen :: OrdList a -> Int
+    olen (None)      = 0
+    olen (One x)     = 1
+    olen (Many xs)   = (len xs)
+    olen (Cons x xs) = 1 + (olen xs)
+    olen (Snoc xs x) = 1 + (olen xs)
+    olen (Two x y)   = (olen x) + (olen y)
+  @-}
+
+{-@ invariant {v:OrdList a | (olen v) >= 0} @-}
+\end{code}
+
+Now, we can use the measures to define aliases for **non-empty** lists and `OrdList`s.
+
+\begin{code}
+{-@ type ListNE    a = {v:[a]       | (len v)  > 0} @-}
+{-@ type OrdListNE a = {v:OrdList a | (olen v) > 0} @-}
+\end{code}
+
+Capturing the Invariants In a Refined Type
+------------------------------------------
+
+Let's return to the original type, and refine it with the above non-empty
+variants to specify the invariants as
+\begin{code} part of the data declaration
+{-@ data OrdList [olen] a
+      = None
+      | One  (x  :: a)
+      | Many (xs :: ListNE a)
+      | Cons (x  :: a)           (xs :: OrdList a)
+      | Snoc (xs :: OrdList a)   (x  :: a)
+      | Two  (x  :: OrdListNE a) (y  :: OrdListNE a)
+  @-}
+\end{code}
+
+Notice immediately that LiquidHaskell can use the refined definition to warn us 
+about malformed `OrdList` values.
+
+\begin{code}
+ok     = Many [1,2,3]
+bad    = Many []
+badder = Two None ok
+\end{code}
+
+All of the above are accepted by GHC, but only the first one is actually a valid
+`OrdList`. Happily, LiquidHaskell will reject the latter two, as they violate
+the invariants.
+
+
+Basic Functions
+---------------
+
+Now let's look at some of the functions!
+
+First, we'll define a handy alias for `OrdList`s of a given size:
+
+\begin{code}
+{-@ type OrdListN a N = {v:OrdList a | (olen v) = N} @-}
+\end{code}
+
+Now, the `nilOL` constructor returns an empty `OrdList`:
+
+\begin{code}
+{-@ nilOL :: OrdListN a {0} @-}
+nilOL = None
+\end{code}
+
+the `unitOL` constructor returns an `OrdList` with one element:
+
+\begin{code}
+{-@ unitOL :: a -> OrdListN a {1} @-}
+unitOL as = One as
+\end{code}
+
+and `snocOL` and `consOL` return outputs with precisely one more element:
+
+\begin{code}
+{-@ snocOL :: xs:OrdList a -> a -> OrdListN a {1 + (olen xs)} @-}
+snocOL as b = Snoc as b
+
+{-@ consOL :: a -> xs:OrdList a -> OrdListN a {1 + (olen xs)} @-}
+consOL a bs = Cons a bs
+\end{code}
+
+**Note:** The `OrdListN a {e}` syntax just lets us use LiquidHaskell 
+expressions `e` as a parameter to the type alias `OrdListN`.
+
+
+
+
+Appending `OrdList`s
+--------------------
+
+The above functions really aren't terribly interesting, however, since their 
+types fall right out of the definition of `olen`. 
+
+So how about something that takes a little thinking?
+
+\begin{code}
+{-@ appOL :: xs:OrdList a -> ys:OrdList a
+          -> OrdListN a {(olen xs) + (olen ys)}
+  @-}
+None  `appOL` b     = b
+a     `appOL` None  = a
+One a `appOL` b     = Cons a b
+a     `appOL` One b = Snoc a b
+a     `appOL` b     = Two a b
+\end{code}
+
+`appOL` takes two `OrdList`s and returns a list whose length is the **sum of** 
+the two input lists. The most important thing to notice here is that we haven't 
+had to insert any extra checks in `appOL`, unlike the [GADT][] solution. 
+
+LiquidHaskell uses the definition of `olen` to infer that in the last case of 
+`appOL`, `a` and `b` *must be non-empty*, so they are valid arguments to `Two`.
+
+We can prove other things about `OrdList`s as well, like the fact
+that converting an `OrdList` to a Haskell list preserves length
+
+\begin{code}
+{-@ toOL :: xs:[a] -> OrdListN a {(len xs)} @-}
+toOL [] = None
+toOL xs = Many xs
+\end{code}
+
+as does mapping over an `OrdList`
+
+\begin{code}
+{-@ mapOL :: (a -> b) -> xs:OrdList a -> OrdListN b {(olen xs)} @-}
+mapOL _ None        = None
+mapOL f (One x)     = One (f x)
+mapOL f (Cons x xs) = Cons (f x) (mapOL f xs)
+mapOL f (Snoc xs x) = Snoc (mapOL f xs) (f x)
+mapOL f (Two x y)   = Two (mapOL f x) (mapOL f y)
+mapOL f (Many xs)   = Many (map f xs)
+\end{code}
+
+as does converting a Haskell list to an `OrdList`.
+
+\begin{code}
+{-@ type ListN a N = {v:[a] | (len v) = N} @-}
+
+{-@ fromOL :: xs:OrdList a -> ListN a {(olen xs)} @-}
+fromOL a = go a []
+  where
+    {-@ go :: xs:_ -> ys:_
+           -> {v:_ | (len v) = (olen xs) + (len ys)}
+      @-}
+    go None       acc = acc
+    go (One a)    acc = a : acc
+    go (Cons a b) acc = a : go b acc
+    go (Snoc a b) acc = go a (b:acc)
+    go (Two a b)  acc = go a (go b acc)
+    go (Many xs)  acc = xs ++ acc
+\end{code}
+
+
+
+There's nothing super interesting to say about the `foldOL`s but I'll
+include them here for completeness' sake.
+
+\begin{code}
+foldrOL :: (a->b->b) -> b -> OrdList a -> b
+foldrOL _ z None        = z
+foldrOL k z (One x)     = k x z
+foldrOL k z (Cons x xs) = k x (foldrOL k z xs)
+foldrOL k z (Snoc xs x) = foldrOL k (k x z) xs
+foldrOL k z (Two b1 b2) = foldrOL k (foldrOL k z b2) b1
+foldrOL k z (Many xs)   = foldr k z xs
+
+foldlOL :: (b->a->b) -> b -> OrdList a -> b
+foldlOL _ z None        = z
+foldlOL k z (One x)     = k z x
+foldlOL k z (Cons x xs) = foldlOL k (k z x) xs
+foldlOL k z (Snoc xs x) = k (foldlOL k z xs) x
+foldlOL k z (Two b1 b2) = foldlOL k (foldlOL k z b1) b2
+foldlOL k z (Many xs)   = foldl k z xs
+\end{code}
+
+
+Concatenatation: Nested Measures
+--------------------------------
+
+Now, the astute readers will have probably noticed that I'm missing 
+one function, `concatOL`, which glues a list of `OrdList`s into a 
+single long `OrdList`.
+
+With LiquidHaskell we can give `concatOL` a super precise type, which 
+states that the size of the output list equals the *sum-of-the-sizes* 
+of the input `OrdLists`.
+
+\begin{code}
+{-@ concatOL :: xs:[OrdList a] -> OrdListN a {(olens xs)} @-}
+concatOL []       = None
+concatOL (ol:ols) = ol `appOL` concatOL ols
+\end{code}
+
+The notion of *sum-of-the-sizes* of the input lists is specifed by the measure
+
+\begin{code}
+{-@ measure olens :: [OrdList a] -> Int
+    olens ([])     = 0
+    olens (ol:ols) = (olen ol) + (olens ols)
+  @-}
+
+{-@ invariant {v:[OrdList a] | (olens v) >= 0} @-}
+\end{code}
+
+LiquidHaskell is happy to verify the above signature, again without 
+requiring any explict proofs. 
+
+Conclusion
+----------
+
+The above illustrates the flexibility provided by LiquidHaskell *measures*.
+
+Instead of having to bake particular invariants into a datatype using indices
+or phantom types (as in the [GADT][] approach), we are able to split our 
+properties out into independent *views* of the datatype, yielding an approach
+that is more modular as 
+
+* we didn't have to go back and change the definition of `[]` to talk about `OrdList`s,
+* we didn't have to provide explict non-emptiness witnesses,
+* we obtained extra information about the behavior of API functions like `concatOL`.
+
+
+
+
+[GADT]: http://www.reddit.com/r/haskell/comments/1xiurm/how_to_define_append_for_ordlist_defined_as_gadt/cfbrinr
+[Reddit]: http://www.reddit.com/r/haskell/comments/1xiurm/how_to_define_append_for_ordlist_defined_as_gadt/
+[OrdList]: http://www.haskell.org/platform/doc/2013.2.0.0/ghc-api/OrdList.html
+[measure]: http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/blog/2013/01/31/safely-catching-a-list-by-its-tail.lhs/
diff --git a/docs/blog/2014-02-16-text-read.lhs b/docs/blog/2014-02-16-text-read.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2014-02-16-text-read.lhs
@@ -0,0 +1,345 @@
+---
+layout: post
+title: "Text Read"
+date: 2014-02-16
+comments: true
+external-url:
+author: Eric Seidel
+published: false
+categories: benchmarks, text
+demo: TextRead.hs
+---
+
+Welcome back! Last time we left off on a bit of a cliffhanger with the
+`unstream` example. Remember, the issue we found was that some `Char`s
+can't fit into a single `Word16`, so the safety of a write depends not
+only on the *index*, but also on the *value* being written! Before we
+can resolve this issue with `unstream` we'll have to learn about
+UTF-16, so let's take a short detour and look at how one *consumes* a
+`Text`.
+
+
+
+
+
+Let's begin with a simple example, `unsafeHead`.
+
+\begin{code}
+{-@ type TextNE = {v:Text | (tlen v) > 0} @-}
+
+{-@ unsafeHead :: TextNE -> Char @-}
+unsafeHead :: Text -> Char
+unsafeHead (Text arr off _len)
+    | m < 0xD800 || m > 0xDBFF = unsafeChr m
+    | otherwise                = chr2 m n
+    where m = unsafeIndex arr off
+          n = unsafeIndex arr (off+1)
+\end{code}
+
+LiquidHaskell can prove the first `unsafeIndex` is safe because the
+precondition states that the `Text` must not be empty, i.e. `_len > 0`
+must hold. Combine this with the core `Text` invariant that
+`off + _len <= alen arr` and we get that `off < alen arr`, which satisfies
+the precondition for `unsafeIndex`.
+
+However, the same calculation *fails* for the second index because we
+can't prove that `off + 1 < alen arr`. The solution is going to
+require some understanding of UTF-16, so let's take a brief detour.
+
+The UTF-16 standard represents all code points below `U+10000` with a
+single 16-bit word; all others are split into two 16-bit words, known
+as a *surrogate pair*. The first word, or *lead*, is guaranteed to be
+in the range `[0xD800, 0xDBFF]` and the second, or *trail*, is
+guaranteed to be in the range `[0xDC00, 0xDFFF]`.
+
+Armed with this knowledge of UTF-16 we can return to
+`unsafeHead`. Note the case-split on `m`, which determines whether `m`
+is a lead surrogate. If `m` is a lead surrogate then we know there
+must be a trail surrogate at `off+1`; we can define a specialized
+version of `unsafeIndex` that encodes this domain knowledge.
+
+\begin{code}
+{-@ unsafeIndexF :: a:Array -> o:AValidO a -> l:AValidL o a
+                 -> i:{v:Nat | (o <= v && v < (o + l))}
+                 -> {v:Word16 | (if (55296 <= v && v <= 56319)
+                                 then (SpanChar 2 a o l i)
+                                 else (SpanChar 1 a o l i))}
+  @-}
+unsafeIndexF :: Array -> Int -> Int -> Int -> Word16
+unsafeIndexF a o l i = let x = unsafeIndex a i
+                       in liquidAssume (axiom_lead_surr x a o l i) x
+\end{code}
+
+Our variant `unsafeIndexF` (F as in "forward") takes an array, an
+offset, and a length (which together must form a valid `Text`); a
+valid index into the `Text`; and returns a `Word16` with an
+interesting type. The best way to read this type would be "if `v` is
+in the range `[0xD800, 0xDBFF]`, then the character that starts at
+index `i` in the array `a` spans two slots, otherwise it only spans
+one slot." Intuitively, we know what it means for a character to span
+`n` slots, but LiquidHaskell needs to know three things:
+
+1. `a[o:i+n]` contains one more character than `a[o:i]` (borrowing
+   Python's wonderful slicing syntax)
+2. `a[o:i+n]` contains no more characters than `a[o:l]`
+3. `i-o+n <= l`
+
+2 and 3 encode the well-formedness of a `Text` value, i.e. `i+1`
+*must* be a valid index if a lead surrogate is at index `i`.
+
+We can encode these properties in the refinement logic as follows.
+
+\begin{code}
+{-@ measure numchars :: Array -> Int -> Int -> Int @-}
+{-@ predicate SpanChar N A O L I =
+      (((numchars (A) (O) ((I-O)+N)) = (1 + (numchars (A) (O) (I-O))))
+    && ((numchars (A) (O) ((I-O)+N)) <= (numchars A O L))
+    && (((I-O)+N) <= L))
+  @-}
+\end{code}
+
+The `numchars` measure takes an array, an offset, and a length
+(e.g. the `arr`, `off`, and `len` fields of a `Text`) and denotes the
+number of characters contained in the `length` slots beginning at
+`offset`. Since we can't compute this in the refinement logic, we
+leave the measure abstract. We can, however, provide LiquidHaskell
+with a few invariants about the behavior of `numchars`, specifically
+that (1) `numchars` always returns a `Nat`, (2) there are no
+characters contained in a empty span, and (3) there are at most as
+many characters as words in a `Text`. We encode these using a special
+`invariant` annotation.
+
+\begin{code}
+{-@ invariant {v:Text | (numchars (tarr v) (toff v) (tlen v)) >= 0}        @-}
+{-@ invariant {v:Text | (numchars (tarr v) (toff v) 0)         = 0}        @-}
+{-@ invariant {v:Text | (numchars (tarr v) (toff v) (tlen v)) <= (tlen v)} @-}
+\end{code}
+
+Finally returning to `unsafeHead`, we can use `unsafeIndexF` to
+strengthen the inferred type for `m`. LiquidHaskell can now prove that
+the second `unsafeIndex` is in fact safe, because it is only demanded
+if `m` is a lead surrogate.
+
+\begin{code}
+{-@ unsafeHead' :: TextNE -> Char @-}
+unsafeHead' :: Text -> Char
+unsafeHead' (Text arr off _len)
+    | m < 0xD800 || m > 0xDBFF = unsafeChr m
+    | otherwise                = chr2 m n
+    where m = unsafeIndexF arr off _len off
+          {-@ LAZYVAR n @-}
+          n = unsafeIndex arr (off+1)
+\end{code}
+
+The `LAZYVAR` annotation is currently required because LiquidHaskell
+doesn't know that `n` will only be demanded in one branch; one can
+imagine a transformation that would push the `where` bindings inward
+to the use-site, which would alleviate this issue.
+
+Before signing off, let's take a look at a slightly more interesting
+function, `take`.
+
+\begin{code}
+{-@ take :: n:Nat -> t:Text -> {v:Text | (Min (tlength v) (tlength t) n)} @-}
+take :: Int -> Text -> Text
+take n t@(Text arr off len)
+    | n <= 0    = empty
+    | n >= len  = t
+    | otherwise = Text arr off (loop 0 0)
+  where
+     loop !i !cnt
+          | i >= len || cnt >= n = i
+          | otherwise            = let d = iter_ t i
+                                   in loop (i+d) (cnt+1)
+\end{code}
+
+`take` gets a `Nat` and a `Text`, and returns a `Text` that contains
+the first `n` characters of `t`. That is, unless `n >= tlength t`, in
+which case it just returns `t`.
+
+`tlength` is a simple wrapper around `numchars`.
+
+\begin{code}
+{-@ measure tlength :: Text -> Int
+    tlength (Text a o l) = (numchars a o l)
+  @-}
+\end{code}
+
+The bulk of the work is done by the
+inner `loop`, which has to track the current index `i` and the number
+of characters we have seen, `cnt`. `loop` uses an auxiliary function
+`iter_` to determine the *width* of the character that starts at `i`,
+bumps `cnt`, and recursively calls itself at `i+d` until it either
+reaches the end of `t` or sees `n` characters, returning the final
+index.
+
+The `iter_` function is quite simple, it just determines whether the
+word at index `i` is a lead surrogate, and returns the appropriate
+span.
+
+\begin{code}
+{-@ predicate SpanCharT N T I =
+      (SpanChar N (tarr T) (toff T) (tlen T) ((toff T)+I))
+  @-}
+
+{-@ iter_ :: t:Text -> i:TValidI t
+          -> {v:Nat | (SpanCharT v t i)}
+  @-}
+iter_ :: Text -> Int -> Int
+iter_ (Text arr off len) i
+    | m < 0xD800 || m > 0xDBFF = 1
+    | otherwise                = 2
+ where m = unsafeIndexF arr off len (off+i)
+\end{code}
+
+Again, we use `unsafeIndexF` to learn more about the structure of `t`
+by observing a small piece of it. It's also worth noting that we've
+encoded all of the domain knowledge we need into a single function,
+which has the benefit of letting us focus our attention on one type
+when we try to ensure that we've encoded it correctly.
+
+Next time, we'll continue our exploration of `text` and see how to
+construct a `Text` while ensuring the absence of out-of-bounds writes.
diff --git a/docs/blog/2014-02-23-text-write.lhs b/docs/blog/2014-02-23-text-write.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2014-02-23-text-write.lhs
@@ -0,0 +1,323 @@
+---
+layout: post
+title: "Text Write"
+date: 2014-02-23
+comments: true
+external-url:
+author: Eric Seidel
+published: false
+categories: benchmarks, text
+demo: TextWrite.hs
+---
+
+Last time, we showed how to reason about Unicode and a variable-width
+encoding of `Char`s when consuming a `Text` value, today we'll look at
+the same issue from the perspective of *building* a `Text`.
+
+
+
+
+
+We mentioned previously that `text` uses stream fusion to optimize
+multiple loops over a `Text` into a single loop; as a result many of
+the top-level API functions are simple wrappers around equivalent
+functions over `Stream`s. The creation of `Text` values is then
+largely handled by a single function, `unstream`, which converts a
+`Stream` into a `Text`.
+
+\begin{code}
+unstream :: Stream Char -> Text
+unstream (Stream next0 s0 len) = runST $ do
+  let mlen = upperBound 4 len
+  arr0 <- new mlen
+  let outer arr top = loop
+       where
+        loop !s !i =
+            case next0 s of
+              Done          -> do
+                arr' <- unsafeFreeze arr
+                return $! Text arr' 0 i
+              Skip s'       -> loop s' i
+              Yield x s'
+                | j >= top  -> do
+                  let top' = (top + 1) `shiftL` 1
+                  arr' <- new top'
+                  copyM arr' 0 arr 0 top
+                  outer arr' top' s i
+                | otherwise -> do
+                  d <- writeChar arr i x
+                  loop s' (i+d)
+                where j | ord x < 0x10000 = i
+                        | otherwise       = i + 1
+  outer arr0 mlen s0 0
+\end{code}
+
+Since we're focusing on memory safety here we won't go into detail
+about how `Stream`s work. Let's instead jump right into the inner
+`loop` and look at the `Yield` case. Here we need to write a char `x`
+into `arr`, so we compute the maximal index `j` to which we will
+write -- i.e. if `x >= U+10000` then `j = i + 1` -- and determine
+whether we can safely write at `j`. If the write is unsafe we have to
+allocate a larger array before continuing, otherwise we write `x` and
+increment `i` by `x`s width.
+
+Since `writeChar` has to handle writing *any* Unicode value, we need
+to assure it that there will always be room to write `x` into `arr`,
+regardless of `x`s width. Indeed, this is expressed in the type we
+give to `writeChar`.
+
+\begin{code}
+{-@ writeChar :: ma:MArray s -> i:Nat -> {v:Char | (Room v ma i)}
+              -> ST s {v:Nat | (RoomN v ma i)}
+  @-}
+\end{code}
+
+The predicate aliases `Room` and `RoomN` express that a character can
+fit in the array at index `i` and that there are at least `n` slots
+available starting at `i` respectively.
+
+\begin{code}
+{-@ predicate Room C MA I = (((One C) => (RoomN 1 MA I))
+                          && ((Two C) => (RoomN 2 MA I)))
+  @-}
+{-@ predicate RoomN N MA I = (I+N <= (malen MA)) @-}
+\end{code}
+
+The `One` and `Two` predicates express that a character will be
+encoded in one or two 16-bit words, by reasoning about its ordinal
+value.
+
+\begin{code}
+{-@ predicate One C = ((ord C) <  65536) @-}
+{-@ predicate Two C = ((ord C) >= 65536) @-}
+\end{code}
+
+As with `numchars`, we leave `ord` abstract, but inform LiquidHaskell
+that the `ord` *function* does in fact return the ordinal value of the
+character.
+
+\begin{code}
+{-@ measure ord :: Char -> Int @-}
+{-@ ord :: c:Char -> {v:Int | v = (ord c)} @-}
+\end{code}
+
+Since `writeChar` assumes that it will never be called unless there is room to
+write `c`, it is safe to just split `c` into 16-bit words and write them into
+the array.
+
+\begin{code}
+writeChar :: MArray s -> Int -> Char -> ST s Int
+writeChar marr i c
+    | n < 0x10000 = do
+        unsafeWrite marr i (fromIntegral n)
+        return 1
+    | otherwise = do
+        unsafeWrite marr i lo
+        unsafeWrite marr (i+1) hi
+        return 2
+    where n = ord c
+          m = n - 0x10000
+          lo = fromIntegral $ (m `shiftR` 10) + 0xD800
+          hi = fromIntegral $ (m .&. 0x3FF) + 0xDC00
+\end{code}
+
+In typical design-by-contract style, we're putting the burden of proof to
+establish safety on `writeChar`s caller. Now, scroll back up to
+`unstream` and mouse over `j` to see its inferred type.
+\begin{code} You should see something like
+{v:Int | ((ord x >= 65536) => (v == i+1))
+      && ((ord x <  65536) => (v == i))}
+\end{code}
+which, combined with the case-split on `j >= top`, provides the proof that
+writing `x` will be safe!
+
+Stay tuned, next time we'll look at another example of building a `Text` where
+LiquidHaskell fails to infer this crucial refinement...
diff --git a/docs/blog/2014-03-01-text-bug.lhs b/docs/blog/2014-03-01-text-bug.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2014-03-01-text-bug.lhs
@@ -0,0 +1,333 @@
+---
+layout: post
+title: "Text Bug"
+date: 2014-03-01
+comments: true
+external-url:
+author: Eric Seidel
+published: false
+categories: benchmarks, text
+demo: TextBug.hs
+---
+
+For our last post on `text`, we return to the topic of building a new `Text`
+value, i.e. proving the safety of write operations.
+
+
+
+
+
+Let's take a look at `mapAccumL`, which combines a map and a fold
+over a `Stream` and bundles the result of the map into a new `Text`.
+Again, we'll want to focus our attention on the `Yield` case of the
+inner loop.
+
+\begin{code}
+mapAccumL f z0 (Stream next0 s0 len) =
+  (nz, Text na 0 nl)
+ where
+  mlen = upperBound 4 len
+  (na,(nz,nl)) = runST $ do
+       (marr,x) <- (new mlen >>= \arr ->
+                    outer arr mlen z0 s0 0)
+       arr      <- unsafeFreeze marr
+       return (arr,x)
+  outer arr top = loop
+   where
+    loop !z !s !i =
+      case next0 s of
+        Done          -> return (arr, (z,i))
+        Skip s'       -> loop z s' i
+        Yield x s'
+          | j >= top  -> do
+            let top' = (top + 1) `shiftL` 1
+            arr' <- new top'
+            copyM arr' 0 arr 0 top
+            outer arr' top' z s i
+          | otherwise -> do
+            let (z',c) = f z x
+            d <- writeChar arr i c
+            loop z' s' (i+d)
+          where j | ord x < 0x10000 = i
+                  | otherwise       = i + 1
+\end{code}
+
+If you recall `unstream` from last time, you'll notice that this loop body
+looks almost identical to the one found in `unstream`, but LiquidHaskell has
+flagged the `writeChar` call as unsafe! What's going on here?
+
+Let's take a look at `j`, recalling that it carried a crucial part of the safety
+\begin{code} proof last time, and see what LiquidHaskell was able to infer.
+{v:Int | ((ord x >= 65536) => (v == i+1))
+      && ((ord x <  65536) => (v == i))}
+\end{code}
+
+Well that's not very useful at all! LiquidHaskell can prove that it's safe to
+write `x` but here we are trying to write `c` into the array. This is actually
+a *good* thing though, because `c` is the result of calling an arbitrary
+function `f` on `x`! We haven't constrained `f` in any way, so it could easily
+return a character above `U+10000` given any input.
+
+So `mapAccumL` is actually *unsafe*, and our first wild bug caught by
+LiquidHaskell! The fix is luckily easy, we simply have to lift the
+`let (z',c) = f z x` binder into the `where` clause, and change `j` to
+depend on `ord c` instead.
+
+\begin{code}
+mapAccumL' f z0 (Stream next0 s0 len) =
+  (nz, Text na 0 nl)
+ where
+  mlen = upperBound 4 len
+  (na,(nz,nl)) = runST $ do
+       (marr,x) <- (new mlen >>= \arr ->
+                    outer arr mlen z0 s0 0)
+       arr      <- unsafeFreeze marr
+       return (arr,x)
+  outer arr top = loop
+   where
+    loop !z !s !i =
+      case next0 s of
+        Done          -> return (arr, (z,i))
+        Skip s'       -> loop z s' i
+        Yield x s'
+          | j >= top  -> do
+            let top' = (top + 1) `shiftL` 1
+            arr' <- new top'
+            copyM arr' 0 arr 0 top
+            outer arr' top' z s i
+          | otherwise -> do
+            d <- writeChar arr i c
+            loop z' s' (i+d)
+          where (z',c) = f z x
+                j | ord c < 0x10000 = i
+                  | otherwise       = i + 1
+\end{code}
+
+LiquidHaskell happily accepts our revised `mapAccumL`, as did the `text`
+maintainers.
+
+We hope you've enjoyed this whirlwind tour of using LiquidHaskell to verify
+production code, we have many more examples in the `benchmarks` folder of
+our GitHub repository for the intrepid reader.
diff --git a/docs/blog/2014-05-28-pointers-gone-wild.lhs b/docs/blog/2014-05-28-pointers-gone-wild.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2014-05-28-pointers-gone-wild.lhs
@@ -0,0 +1,467 @@
+---
+layout: post
+title: "Pointers Gone Wild"
+date: 2014-05-28
+comments: true
+external-url:
+author: Eric Seidel
+published: true
+categories: benchmarks, text
+demo: TextInternal.hs
+---
+
+A large part of the allure of Haskell is its elegant, high-level ADTs
+that ensure[^compilercorrectness] that programs won't be plagued by problems
+like the infamous [SSL heartbleed bug](http://en.wikipedia.org/wiki/Heartbleed).
+
+[^compilercorrectness]: Assuming the absence of errors in the compiler and run-time...
+
+However, another part of Haskell's charm is that when you really really 
+need to, you can drop down to low-level pointer twiddling to squeeze the 
+most performance out of your machine. But of course, that opens the door 
+to the #heartbleeds.
+
+Can we have have our cake and eat it too? 
+
+Can we twiddle pointers and still get the nice safety assurances of high-level types?
+
+
+
+To understand the potential for potential bleeding,
+let's study the popular `text` library for efficient 
+text processing. The library provides the high-level 
+API Haskellers have come to expect while using stream 
+fusion and byte arrays under the hood to guarantee 
+high performance.
+
+Suppose we wanted to get the *i*th `Char` of a `Text`,
+\begin{code} we could write a function[^bad]
+charAt (Text a o l) i = word2char $ unsafeIndex a (o+i)
+  where 
+    word2char         = chr . fromIntegral
+\end{code}
+which extracts the underlying array `a`, indexes into it starting
+at the offset `o` and casts the `Word16` to a `Char`, using 
+functions exported by `text`.
+
+[^bad]: This function is bad for numerous reasons, least of which is that `Data.Text.index` is already provided, but stay with us...
+
+\begin{code}Let's try this out in GHCi.
+ghci> let t = pack ['d','o','g']
+ghci> charAt t 0
+'d'
+ghci> charAt t 2
+'g'
+\end{code}
+
+\begin{code}Looks good so far, what happens if we keep going?
+ghci> charAt t 3
+'\NUL'
+ghci> charAt t 100
+'\8745'
+\end{code}
+
+Oh dear, not only did we not get any sort of exception from Haskell, 
+we weren't even stopped by the OS with a segfault. This is quite 
+dangerous since we have no idea what sort of data we just read! 
+To be fair to the library's authors, we did use a function that 
+was clearly branded `unsafe`, but these functions, while not 
+intended for *clients*, pervade the implementation of the *library*.
+
+Wouldn't it be nice to have these last two calls *rejected at compile time*?
+
+In this post we'll see exactly how prevent invalid memory accesses 
+like this with LiquidHaskell.
+
+
+
+
+The `Text` Lifecycle
+--------------------
+`text` splits the reading and writing array operations between two
+types of arrays, immutable `Array`s and mutable `MArray`s. This leads to
+the following general lifecycle:
+
+![The lifecycle of a `Text`](/images/text-lifecycle.png)
+
+The main four array operations we care about are:
+
+1. **creating** an `MArray`,
+2. **writing** into an `MArray`,
+3. **freezing** an `MArray` into an `Array`, and
+4. **reading** from an `Array`.
+
+Creating an `MArray`
+--------------------
+
+The (mutable) `MArray` is a thin wrapper around GHC's primitive
+`MutableByteArray#`, additionally carrying the number of `Word16`s it
+can store.
+
+\begin{code}
+data MArray s = MArray { maBA  :: MutableByteArray# s
+                       , maLen :: !Int
+                       }
+\end{code}
+
+It doesn't make any sense to have a negative length, so we *refine*
+the data definition to require that `maLen` be non-negative. 
+
+\begin{code}
+{-@ data MArray s = MArray { maBA  :: MutableByteArray# s
+                           , maLen :: Nat
+                           }
+  @-}
+\end{code}
+
+
+\begin{code} As an added bonus, the above specification generates **field-accessor measures** that we will use inside the refined types:
+{-@ measure maLen :: MArray s -> Int
+    maLen (MArray a l) = l
+  @-}
+\end{code}
+
+We can use these accessor measures to define `MArray`s of size `N`:
+
+\begin{code}
+{-@ type MArrayN a N = {v:MArray a | (maLen v) = N} @-}
+\end{code}
+
+and we can use the above alias, to write a type that tracks the size
+of an `MArray` at the point where it is created:
+
+\begin{code}
+{-@ new :: forall s. n:Nat -> ST s (MArrayN s n) @-}
+new n
+  | n < 0 || n .&. highBit /= 0 = error "size overflow"
+  | otherwise = ST $ \s1# ->
+       case newByteArray# len# s1# of
+         (# s2#, marr# #) -> (# s2#, MArray marr# n #)
+  where !(I# len#) = bytesInArray n
+        highBit    = maxBound `xor` (maxBound `shiftR` 1)
+        bytesInArray n = n `shiftL` 1
+\end{code}
+
+`new n` is an `ST` action that produces an `MArray s` with `n` slots each 
+of which is 2 bytes (as internally `text` manipulates `Word16`s).
+
+The verification process here is quite simple; LH recognizes that 
+the `n` used to construct the returned array (`MArray marr# n`) 
+the same `n` passed to `new`. 
+
+Writing into an `MArray`
+------------------------
+
+Once we have *created* an `MArray`, we'll want to write our data into it. 
+
+A `Nat` is a valid index into an `MArray` if it is *strictly less than* 
+the size of the array.
+
+\begin{code}
+{-@ type MAValidI MA = {v:Nat | v < (maLen MA)} @-}
+\end{code}
+
+We use this valid index alias to refine the type of `unsafeWrite`
+
+\begin{code}
+{-@ unsafeWrite :: ma:MArray s -> MAValidI ma -> Word16 -> ST s () @-}
+unsafeWrite MArray{..} i@(I# i#) (W16# e#)
+  | i < 0 || i >= maLen = assert False $ error "out of bounds"
+  | otherwise = ST $ \s1# ->
+      case writeWord16Array# maBA i# e# s1# of
+        s2# -> (# s2#, () #)
+\end{code}
+
+Note that, when compiled with appropriate options, the implementation of
+`text` checks the bounds at run-time. However, LiquidHaskell can statically
+prove that the error branch is unreachable, i.e. the `assert` **cannot fail**
+(as long as the inputs adhere to the given specification) by giving `assert`
+the type:
+
+\begin{code}
+{-@ assert assert :: {v:Bool | (Prop v)} -> a -> a @-}
+\end{code}
+
+Bulk Writing into an `MArray`
+-----------------------------
+
+So now we can write individual `Word16`s into an array, but maybe we
+have a whole bunch of text we want to dump into the array. Remember,
+`text` is supposed to be fast! C has `memcpy` for cases like this but 
+it's notoriously unsafe; with the right type however, we can regain safety. 
+`text` provides a wrapper around `memcpy` to copy `n` elements from 
+one `MArray` to another.
+
+`copyM` requires two `MArray`s and valid offsets into each -- note
+that a valid offset is **not** necessarily a valid *index*, it may
+be one element out-of-bounds
+
+\begin{code}
+{-@ type MAValidO MA = {v:Nat | v <= (maLen MA)} @-}
+\end{code}
+
+-- and a `count` of elements to copy.
+The `count` must represent a valid region in each `MArray`, in
+other words `offset + count <= length` must hold for each array.
+
+\begin{code}
+{-@ copyM :: dest:MArray s
+          -> didx:MAValidO dest
+          -> src:MArray s
+          -> sidx:MAValidO src
+          -> {v:Nat | (((didx + v) <= (maLen dest))
+                    && ((sidx + v) <= (maLen src)))}
+          -> ST s ()
+  @-}
+copyM dest didx src sidx count
+    | count <= 0 = return ()
+    | otherwise =
+    assert (sidx + count <= maLen src) .
+    assert (didx + count <= maLen dest) .
+    unsafeIOToST $ memcpyM (maBA dest) (fromIntegral didx)
+                           (maBA src) (fromIntegral sidx)
+                           (fromIntegral count)
+\end{code}
+
+Again, the two `assert`s in the function were in the original code as 
+(optionally compiled out) run-time checks of the precondition, but with 
+LiquidHaskell we can actually *prove* that the `assert`s **always succeed**.
+
+Freezing an `MArray` into an `Array`
+------------------------------------
+
+Before we can package up our `MArray` into a `Text`, we need to
+*freeze* it, preventing any further mutation. The key property 
+here is of course that the frozen `Array` should have the same 
+length as the `MArray`.
+
+Just as `MArray` wraps a mutable array, `Array` wraps an *immutable*
+`ByteArray#` and carries its length in `Word16`s.
+
+\begin{code}
+data Array = Array { aBA  :: ByteArray#
+                   , aLen :: !Int
+                   }
+\end{code}
+
+As before, we get free accessor measures `aBA` and `aLen` just by
+refining the data definition
+
+\begin{code}
+{-@ data Array = Array { aBA  :: ByteArray#
+                       , aLen :: Nat
+                       }
+  @-}
+\end{code}
+
+so we can refer to the components of an `Array` in our refinements.
+Using these measures, we can define
+
+\begin{code}
+{-@ type ArrayN N = {v:Array | (aLen v) = N} @-}
+{-@ unsafeFreeze :: ma:MArray s -> ST s (ArrayN (maLen ma)) @-}
+unsafeFreeze MArray{..} = ST $ \s# ->
+                          (# s#, Array (unsafeCoerce# maBA) maLen #)
+\end{code}
+
+Again, LiquidHaskell is happy to prove our specification as we simply
+copy the length parameter `maLen` over into the `Array`.
+
+Reading from an `Array`
+------------------------
+Finally, we will eventually want to read a value out of the
+`Array`. As with `unsafeWrite` we require a valid index into the
+`Array`, which we denote using the `AValidI` alias.
+
+\begin{code}
+{-@ type AValidI A = {v:Nat | v < (aLen A)} @-}
+{-@ unsafeIndex :: a:Array -> AValidI a -> Word16 @-}
+unsafeIndex Array{..} i@(I# i#)
+  | i < 0 || i >= aLen = assert False $ error "out of bounds"
+  | otherwise = case indexWord16Array# aBA i# of
+                  r# -> (W16# r#)
+\end{code}
+
+As before, LiquidHaskell can easily prove that the error branch
+is unreachable, i.e. is *never* executed at run-time.
+
+Wrapping it all up
+------------------
+
+Now we can finally define the core datatype of the `text` package!
+A `Text` value consists of three fields:
+
+A. an `Array`,
+
+B. an `Int` offset into the *middle* of the array, and
+
+C. an `Int` length denoting the number of valid indices *after* the offset.
+
+We can specify the invariants for fields (b) and (c) with the refined type:
+
+\begin{code}
+{-@ data Text
+      = Text { tArr :: Array
+             , tOff :: {v:Nat | v      <= (aLen tArr)}
+             , tLen :: {v:Nat | v+tOff <= (aLen tArr)}
+             }
+  @-}
+\end{code}
+
+These invariants ensure that any *index* we pick between `tOff` and
+`tOff + tLen` will be a valid index into `tArr`. 
+
+As shown above with `new`, `unsafeWrite`, and `unsafeFreeze`, we can type the
+top-level function that creates a `Text` from a `[Char]` as:
+
+\begin{code}
+{-@ pack :: s:String -> {v:Text | (tLen v) = (len s)} @-}
+\end{code}
+
+Preventing Bleeds
+-----------------
+
+Now, let us close the circle and return to potentially *bleeding* function:
+
+\begin{code}
+charAt' (Text a o l) i = word2char $ unsafeIndex a (o+i)
+  where 
+    word2char          = chr . fromIntegral
+\end{code}
+
+Aha! LiquidHaskell flags the call to `unsafeIndex` because of course, `i` may fall
+outside the bounds of the given array `a`! We can remedy that by specifying
+a bound for the index:
+
+\begin{code}
+{-@ charAt :: t:Text -> {v:Nat | v < (tLen t)} -> Char @-}
+charAt (Text a o l) i = word2char $ unsafeIndex a (o+i)
+  where 
+    word2char         = chr . fromIntegral
+\end{code}
+
+That is, we can access the `i`th `Char` as long as `i` is a `Nat` less
+than the the size of the text, namely `tLen t`. Now LiquidHaskell is convinced
+that the call to `unsafeIndex` is safe, but of course, we have passed
+the burden of proof onto users of `charAt`.
+
+Now, if we try calling `charAt` as we did at the beginning
+
+\begin{code}
+test = [good,bad]
+  where
+    dog  = ['d','o','g']
+    good = charAt (pack dog) 2
+    bad  = charAt (pack dog) 3
+\end{code}
+
+we see that LiquidHaskell verifies the `good` call, but flags `bad` as
+**unsafe**.
+
+Enforcing Sanitization
+----------------------
+
+EDIT: As several folks have pointed out, the #heartbleed error was
+due to inputs not being properly sanitized. The above approach 
+**ensures, at compile time**, that proper sanitization has been 
+performed. 
+
+To see this in action, lets write a little function that just shows the 
+character at a given position:
+
+\begin{code}
+{-@ showCharAt :: t:_ -> {v:Nat | v < (tLen t)} -> _ @-}
+showCharAt t i = putStrLn $ show $ charAt t i
+\end{code}
+
+Now, the following function, that correctly sanitizes is **accepted**
+
+\begin{code}
+goodMain :: IO ()
+goodMain 
+  = do txt <- pack <$> getLine
+       i   <- readLn
+       if 0 <= i && i < tLength txt 
+         then showCharAt txt i 
+         else putStrLn "Bad Input!"
+\end{code}
+
+but this function, which has insufficient sanitization, is **rejected**
+
+\begin{code}
+badMain :: IO ()
+badMain 
+  = do txt <- pack <$> getLine 
+       i   <- readLn
+       if 0 <= i 
+         then showCharAt txt i 
+         else putStrLn "Bad Input!"
+\end{code}
+
+Thus, we can use LiquidHaskell to block, at compile time, any serious bleeding
+from pointers gone wild.
diff --git a/docs/blog/2014-08-15-a-finer-filter.lhs b/docs/blog/2014-08-15-a-finer-filter.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2014-08-15-a-finer-filter.lhs
@@ -0,0 +1,303 @@
+---
+layout: post
+title: "A Finer Filter"
+date: 2014-08-15 16:12
+author: Ranjit Jhala
+published: true
+comments: true
+external-url:
+categories: abstract-refinements 
+demo: filter.hs
+---
+
+This morning, I came across this [nice post](https://twitter.com/ertesx/status/500034598042996736) which describes how one can write a very expressive type for 
+`filter` using [singletons](https://hackage.haskell.org/package/singletons).
+
+Lets see how one might achieve this with [abstract refinements][absref].
+
+
+
+
+
+Goal
+----
+
+What we're after is a way to write a `filter` function such that:
+
+\begin{code} 
+{-@ getPoss  :: [Int] -> [Pos] @-}
+getPoss      = filter isPos
+
+{-@ getEvens :: [Int] -> [Even] @-}
+getEvens     = filter isEven
+
+{-@ getOdds  :: [Int] -> [Odd] @-}
+getOdds      = filter isOdd
+\end{code}
+
+where `Pos`, `Even` and `Odd` are just subsets of `Int`:
+
+\begin{code}
+{-@ type Pos  = {v:Int| 0 < v}        @-}
+
+{-@ type Even = {v:Int| v mod 2 == 0} @-}
+
+{-@ type Odd  = {v:Int| v mod 2 /= 0} @-}
+\end{code}
+
+Take 1: Map, maybe?
+-------------------
+
+Bowing to the anti-boolean sentiment currently in the air, lets eschew 
+the classical approach where the predicates (`isPos` etc.) return `True` 
+or `False` and instead implement `filter` using a map.
+
+\begin{code}
+filter1          :: (a -> Maybe b) -> [a] -> [b]
+
+filter1 f []     = []
+filter1 f (x:xs) = case f x of
+                     Just y  -> y : filter1 f xs 
+                     Nothing ->     filter1 f xs
+\end{code}
+
+To complete the picture, we need just define the predicates as
+functions returning a `Maybe`:
+
+\begin{code}
+{- isPos          :: Int -> Maybe Pos  @-}
+isPos x
+  | x > 0          = Just x
+  | otherwise      = Nothing
+
+{- isEven         :: Int -> Maybe Even @-}
+isEven x
+  | x `mod` 2 == 0 = Just x
+  | otherwise      = Nothing
+
+{- isOdd          :: Int -> Maybe Odd  @-}
+isOdd x
+  | x `mod` 2 /= 0 = Just x
+  | otherwise      = Nothing
+\end{code}
+
+and now, we can achieve our goal!
+
+\begin{code}
+{-@ getPoss1 :: [Int] -> [Pos] @-}
+getPoss1     = filter1 isPos
+
+{-@ getEvens1 :: [Int] -> [Even] @-}
+getEvens1    = filter1 isEven
+
+{-@ getOdds1 :: [Int] -> [Odd] @-}
+getOdds1     = filter1 isOdd
+\end{code}
+
+**The Subset Guarantee**
+
+Well that was easy! Or was it?
+
+I fear we've *cheated* a little bit.
+
+One of the nice things about the *classical* `filter` is that by eyeballing
+the signature:
+
+\begin{spec}
+filter :: (a -> Bool) -> [a] -> [a]
+\end{spec}
+
+we are guaranteed, via parametricity, that the output list's elements are
+a *subset of* the input list's elements. The signature for our new-fangled
+
+\begin{spec}
+filter1 :: (a -> Maybe b) -> [a] -> [b]
+\end{spec}
+
+yields no such guarantee!
+
+In this case, things work out, because in each case, LiquidHaskell *instantiates*
+the type variables `a` and `b` in the signature of `filter1` suitably:
+
+* In `getPoss ` LH instantiates `a := Int` and `b := Pos`
+* In `getEvens` LH instantiates `a := Int` and `b := Even`
+* In `getOdds ` LH instantiates `a := Int` and `b := Odd`
+
+(Hover over the different instances of `filter1` above to confirm this.)
+
+But in general, we'd rather *not* lose the nice "subset" guarantee that the
+classical `filter` provides.
+
+
+Take 2: One Type Variable
+-------------------------
+
+Easy enough! Why do we need *two* type variables anyway?
+
+\begin{code}
+filter2          :: (a -> Maybe a) -> [a] -> [a]
+
+filter2 f []     = []
+filter2 f (x:xs) = case f x of
+                     Just y  -> y : filter2 f xs 
+                     Nothing ->     filter2 f xs
+\end{code}
+
+There! Now the `f` is forced to take or leave its input `x`, 
+and so we can breathe easy knowing that `filter2` returns a 
+subset of its inputs.
+
+But...
+
+\begin{code}
+{-@ getPoss2 :: [Int] -> [Pos] @-}
+getPoss2     = filter2 isPos
+
+{-@ getEvens2 :: [Int] -> [Even] @-}
+getEvens2    = filter2 isEven
+
+{-@ getOdds2 :: [Int] -> [Odd] @-}
+getOdds2     = filter2 isOdd
+\end{code}
+
+Yikes, LH is not impressed -- the red highlight indicates that LH is not
+convinced that the functions have the specified types.
+
+Perhaps you know why already?
+
+Since we used **the same** type variable `a` for *both* the 
+input *and* output, LH must instantiate `a` with a type that 
+matches *both* the input and output, i.e. is a *super-type*
+of both, which is simply `Int` in all the cases. 
+
+Consequently, we get the errors above -- "expected `Pos` but got `Int`".
+
+Take 3: Add Abstract Refinement
+-------------------------------
+
+What we need is a generic way of specifying that the 
+output of the predicate is not just an `a` but an `a` 
+that *also* enjoys whatever property we are filtering for. 
+
+This sounds like a job for [abstract refinements][absref] which
+let us parameterize a signature over its refinements:
+
+\begin{code}
+{-@ filter3      :: forall a 
 Prop>.
+                      (a -> Maybe a
) -> [a] -> [a
] @-}
+filter3 f []     = []
+filter3 f (x:xs) = case f x of
+                     Just x'  -> x' : filter3 f xs 
+                     Nothing ->       filter3 f xs
+\end{code}
+
+ Now, we've **decoupled** the filter-property from the type variable `a`.
+
+The input still is a mere `a`, but the output is an `a` with bells on,
+specifically, which satisfies the (abstract) refinement `p`.
+
+Voila!
+
+\begin{code}
+{-@ getPoss3  :: [Int] -> [Pos] @-}
+getPoss3      = filter3 isPos
+
+{-@ getEvens3 :: [Int] -> [Even] @-}
+getEvens3     = filter3 isEven
+
+{-@ getOdds3  :: [Int] -> [Odd] @-}
+getOdds3      = filter3 isOdd
+\end{code}
+
+Now, LH happily accepts each of the above.
+
+At each *use* of `filter` LH separately *instantiates* the `a` and
+the `p`. In each case, the `a` is just `Int` but the `p` is instantiated as:
+
++ In `getPoss ` LH instantiates `p := \v -> 0 <= v`
++ In `getEvens` LH instantiates `p := \v -> v mod 2 == 0`
++ In `getOdds ` LH instantiates `p := \v -> v mod 2 /= 0`
+
+That is, in each case, LH instantiates `p` with the refinement that describes
+the output type we are looking for.
+
+**Edit:** At this point, I was ready to go to bed, and so happily 
+declared victory and turned in. The next morning, [mypetclone](http://www.reddit.com/r/haskell/comments/2dozs5/liquidhaskell_a_finer_filter/cjrrx3y)
+graciously pointed out my folly: the signature for `filter3` makes no guarantees
+about the subset property. In fact, 
+
+\begin{code}
+doubles = filter3 (\x -> Just (x + x)) 
+\end{code}
+
+typechecks just fine, while `doubles` clearly violates the subset property. 
+
+Take 4: 
+-------
+
+I suppose the moral is that it may be tricky -- for me at least! -- to read more into
+a type than what it *actually says*. Fortunately, with refinements, our types can say
+quite a lot.
+
+In particular, lets make the subset property explicit, by
+
+1. Requiring the predicate return its input (or nothing), and,
+2. Ensuring  the output is indeed a subset of the inputs.
+
+\begin{code}
+{-@ filter      :: forall a 
 Prop>.
+                       (x:a -> Maybe {v:a
 | v = x})
+                    -> xs:[a]
+                    -> {v:[a
] | Set_sub (elts v) (elts xs)} @-}
+
+filter f []     = []
+filter f (x:xs) = case f x of
+                    Just x'  -> x' : filter f xs 
+                    Nothing ->       filter f xs
+\end{code}
+
+where `elts` describes the [set of elements in a list][sets].
+
+**Note:** The *implementation* of each of the above `filter` functions are
+the same; they only differ in their type *specification*.
+
+Conclusion
+----------
+
+And so, using abstract refinements, we've written a `filter` whose signature guarantees:
+
+* The outputs must be a *subset* of the inputs, and
+* The outputs indeed satisfy the property being filtered for.
+
+Another thing that I've learnt from this exercise, is that the old 
+school `Boolean` approach has its merits. Take a look at the clever 
+"latent predicates" technique of [Tobin-Hochstadt and Felleisen][racket]
+or this lovely new [paper by Kaki and Jagannathan][catalyst] which
+shows how refinements can be further generalized to make Boolean filters fine.
+
+[sets]:   /blog/2013/03/26/talking-about-sets.lhs/ 
+[absref]:   /blog/2013/06/03/abstracting-over-refinements.lhs/ 
+[racket]:   http://www.ccs.neu.edu/racket/pubs/popl08-thf.pdf
+[catalyst]: http://gowthamk.github.io/docs/icfp77-kaki.pdf
diff --git a/docs/blog/2015-01-30-okasakis-lazy-queue.lhs b/docs/blog/2015-01-30-okasakis-lazy-queue.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2015-01-30-okasakis-lazy-queue.lhs
@@ -0,0 +1,338 @@
+---
+layout: post
+title: "Okasaki's Lazy Queues"
+date: 2015-01-28
+comments: true
+external-url:
+author: Ranjit Jhala 
+published: true
+categories: measures
+demo: LazyQueue.hs
+---
+
+The "Hello World!" example for fancy type systems is probably the sized vector
+or list `append` function ("The output has size equal to the *sum* of the
+inputs!").  One the one hand, it is perfect: simple enough to explain without
+pages of code, yet complex enough to show off whats cool about dependency. On
+the other hand, like the sweater I'm sporting right now, it's a bit well-worn and
+worse, was never wholly convincing ("Why do I *care* what the *size* of the
+output list is anyway?")
+
+Recently, I came across a nice example that is almost as simple, but is also
+well motivated: Okasaki's beautiful [Lazy Amortized Queues][okasaki95].  This
+structure leans heavily on an invariant to provide fast *insertion* and
+*deletion*. Let's see how to enforce that invariant with LiquidHaskell.
+
+
+
+

+
+Queues 
+------
+
+A [queue][queue-wiki] is a structure into which we can `insert` and `remove` data
+such that the order in which the data is removed is the same as the order in which
+it was inserted.
+
+![A Queue](/images/queue.png)
+
+To implement a queue *efficiently* one needs to have rapid access to both
+the "head" as well as the "tail" because we `remove` elements from former
+and `insert` elements into the latter. This is quite straightforward with
+explicit pointers and mutation -- one uses an old school linked list and
+maintains pointers to the head and the tail. But can we implement the
+structure efficiently without having stoop so low?
+
+Queues = Pair of Lists
+----------------------
+
+Almost two decades ago, Chris Okasaki came up with a very cunning way
+to implement queues using a *pair* of lists -- let's call them `front`
+and `back` which represent the corresponding parts of the Queue.
+
++ To `insert` elements, we just *cons* them onto the `back` list,
++ To `remove` elements, we just *un-cons* them from the `front` list.
+
+![A Queue is Two Lists](/images/queue-lists.png)
+
+
+The catch is that we need to shunt elements from the back to the
+front every so often, e.g. when
+
+1. a `remove` call is triggered, and
+2. the `front` list is empty,
+
+We can transfer the elements from the `back` to the `front`.
+
+
+![Transferring Elements from Back to Front](/images/queue-rotate.png)
+
+Okasaki observed that every element is only moved *once* from the
+front to the back; hence, the time for `insert` and `lookup` could be
+`O(1)` when *amortized* over all the operations. Awesome, right?!
+
+Almost. Some set of unlucky `remove` calls (which occur when
+the `front` is empty) are stuck paying the bill. They have a
+rather high latency up to `O(n)` where `n` is the total number
+of operations. Oops.
+
+Queue = Balanced Lazy Lists
+---------------------------
+
+This is where Okasaki's beautiful insights kick in. Okasaki
+observed that all we need to do is to enforce a simple invariant:
+
+**Invariant:** Size of `front` >= Size of `back`
+
+Now, if the lists are *lazy* i.e. only constructed as the head
+value is demanded, then a single `remove` needs only a tiny `O(log n)`
+in the worst case, and so no single `remove` is stuck paying the bill.
+
+Let's see how to represent these Queues and ensure the crucial invariant(s)
+with LiquidHaskell. What we need are the following ingredients:
+
+1. A type for `List`s, and a way to track their `size`,
+
+2. A type for `Queue`s which encodes the *balance* invariant -- ``front longer than back",
+
+3. A way to implement the `insert`, `remove` and `transfer` operations.
+
+Sized Lists
+------------
+
+The first part is super easy. Let's define a type:
+
+\begin{code}
+data SList a = SL { size :: Int, elems :: [a]}
+\end{code}
+
+We have a special field that saves the `size` because otherwise, we
+have a linear time computation that wrecks Okasaki's careful
+analysis. (Actually, he presents a variant which does *not* require
+saving the size as well, but that's for another day.)
+
+But how can we be sure that `size` is indeed the *real size* of `elems`?
+
+Let's write a function to *measure* the real size:
+
+\begin{code}
+{-@ measure realSize @-}
+realSize      :: [a] -> Int
+realSize []     = 0
+realSize (_:xs) = 1 + realSize xs
+\end{code}
+
+and now, we can simply specify a *refined* type for `SList` that ensures
+that the *real* size is saved in the `size` field:
+
+\begin{code}
+{-@ data SList a = SL {
+       size  :: Nat 
+     , elems :: {v:[a] | realSize v = size}
+     }
+  @-}
+\end{code}
+
+As a sanity check, consider this:
+
+\begin{code}
+okList  = SL 1 ["cat"]    -- accepted
+
+badList = SL 1 []         -- rejected
+\end{code}
+
+It is helpful to define a few aliases for `SList`s of a size `N` and
+non-empty `SList`s:
+
+\begin{code}
+-- | SList of size N
+
+{-@ type SListN a N = {v:SList a | size v = N} @-}
+
+-- | Non-Empty SLists:
+
+{-@ type NEList a = {v:SList a | size v > 0} @-}
+
+\end{code}
+
+Finally, we can define a basic API for `SList`.
+
+**To Construct** lists, we use `nil` and `cons`:
+
+\begin{code}
+{-@ nil          :: SListN a 0  @-}
+nil              = SL 0 []
+
+{-@ cons         :: a -> xs:SList a -> SListN a {size xs + 1}   @-}
+cons x (SL n xs) = SL (n+1) (x:xs)
+\end{code}
+
+**To Destruct** lists, we have `hd` and `tl`.
+
+\begin{code}
+{-@ tl           :: xs:NEList a -> SListN a {size xs - 1}  @-}
+tl (SL n (_:xs)) = SL (n-1) xs
+
+{-@ hd           :: xs:NEList a -> a @-}
+hd (SL _ (x:_))  = x 
+\end{code}
+
+Don't worry, they are perfectly *safe* as LiquidHaskell will make
+sure we *only* call these operators on non-empty `SList`s. For example,
+
+\begin{code}
+okHd  = hd okList       -- accepted
+
+badHd = hd (tl okList)  -- rejected
+\end{code}
+
+
+Queue Type
+-----------
+
+Now, it is quite straightforward to define the `Queue` type, as a pair of lists,
+`front` and `back`, such that the latter is always smaller than the former:
+
+\begin{code}
+{-@ data Queue a = Q {
+       front :: SList a 
+     , back  :: SListLE a (size front)
+     }
+  @-}
+\end{code}
+
+Where the alias `SListLE a L` corresponds to lists with less than `N` elements:
+
+\begin{code}
+{-@ type SListLE a N = {v:SList a | size v <= N} @-}
+\end{code}
+
+As a quick check, notice that we *cannot represent illegal Queues*:
+
+\begin{code}
+okQ  = Q okList nil  -- accepted, |front| > |back| 
+
+badQ = Q nil okList  -- rejected, |front| < |back|
+\end{code}
+
+**To Measure Queue Size** let us define a function
+
+\begin{code}
+{-@ measure qsize @-}
+qsize         :: Queue a -> Int
+qsize (Q l r) = size l + size r
+\end{code}
+
+This will prove helpful to define `Queue`s of a given size `N` and
+non-empty `Queue`s (from which values can be safely removed.)
+
+\begin{code}
+{-@ type QueueN a N = {v:Queue a | N = qsize v} @-}
+{-@ type NEQueue a  = {v:Queue a | 0 < qsize v} @-}
+\end{code}
+
+
+Queue Operations
+----------------
+
+Almost there! Now all that remains is to define the `Queue` API. The
+code below is more or less identical to Okasaki's (I prefer `front`
+and `back` to his `left` and `right`.)
+
+
+**The Empty Queue** is simply one where both `front` and `back` are `nil`.
+
+\begin{code}
+{-@ emp :: QueueN a 0 @-}
+emp = Q nil nil
+\end{code}
+
+**To Insert** an element we just `cons` it to the `back` list, and call
+the *smart constructor* `makeq` to ensure that the balance invariant holds:
+
+\begin{code}
+{-@ insert       :: a -> q:Queue a -> QueueN a {qsize q + 1}   @-}
+insert e (Q f b) = makeq f (e `cons` b)
+\end{code}
+
+**To Remove** an element we pop it off the `front` by using `hd` and `tl`.
+Notice that the `remove` is only called on non-empty `Queue`s, which together
+with the key balance invariant, ensures that the calls to `hd` and `tl` are safe.
+
+\begin{code}
+{-@ remove       :: q:NEQueue a -> (a, QueueN a {qsize q - 1}) @-}
+remove (Q f b)   = (hd f, makeq (tl f) b)
+\end{code}
+
+*Aside:* Why didn't we (or Okasaki) use a pattern match here?
+
+**To Ensure the Invariant** we use the smart constructor `makeq`,
+which is where the heavy lifting, such as it is, happens. The
+constructor takes two lists, the front `f` and back `b` and if they
+are balanced, directly returns the `Queue`, and otherwise transfers
+the elements from `b` over using `rot`ate.
+
+\begin{code}
+{-@ makeq :: f:SList a
+          -> b:SListLE a {size f + 1 }
+          -> QueueN a {size f + size b}
+  @-}
+makeq l r
+  | size r <= size l = Q l r
+  | otherwise        = Q (rot l r nil) nil
+\end{code}
+
+**The Rotate** function is only called when the `back` is one larger
+than the `front` (we never let things drift beyond that). It is
+arranged so that it the `hd` is built up fast, before the entire
+computation finishes; which, combined with laziness provides the
+efficient worst-case guarantee.
+
+\begin{code}
+{-@ rot :: l:SList a
+        -> r:SListN _ {1 + size l}
+        -> a:SList _
+        -> SListN _ {size l + size r + size a}
+  @-}
+rot l r a
+  | size l == 0 = hd r `cons` a
+  | otherwise   = hd l `cons` rot (tl l) (tl r) (hd r `cons` a)
+\end{code}
+
+Conclusion
+----------
+
+Well there you have it; Okasaki's beautiful lazy Queue, with the
+invariants easily expressed and checked with LiquidHaskell. I find
+this example particularly interesting because the refinements express
+invariants that are critical for efficiency, and furthermore the code
+introspects on the `size` in order to guarantee the invariants.  Plus,
+it's just marginally more complicated than `append` and so, (I hope!)
+was easy to follow.
+
+
+
+[okasaki95]: http://www.westpoint.edu/eecs/SiteAssets/SitePages/Faculty%20Publication%20Documents/Okasaki/jfp95queue.pdf
+
+[queue-wiki]: http://en.wikipedia.org/wiki/Queue_%28abstract_data_type%29
diff --git a/docs/blog/2015-06-13-bounded-refinement-types.lhs b/docs/blog/2015-06-13-bounded-refinement-types.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2015-06-13-bounded-refinement-types.lhs
@@ -0,0 +1,337 @@
+---
+layout: post
+title: "Bounded Refinement Types"
+date: 2015-06-13
+comments: true
+external-url:
+author: Niki Vazou
+published: true
+categories: bounded-refinements, abstract-refinements, function-composition
+demo: BoundedRefinementTypes.hs
+---
+
+While refinement types let SMT solvers do a lot of the "boring" analysis,
+they are limited to decidable (first order) logics which can prevent us
+from writing *modular* and *reusable* specifications for *higher-order*
+functions. Next, lets see why modularity is important, and how we can
+recover it using a new technique called **Bounded Refinements**.
+
+
+
+
+
+Reusable Specifications
+-----------------------
+
+Let us suppose, for just a moment, that we live in a dystopian future
+where parametric polymorphism and typeclasses have been eliminated
+from Haskell. Now, consider the function that returns the largest
+element of a list:
+
+\begin{code}
+maximum         :: [Int] -> Int
+maximum [x]    = x
+maximum (x:xs) = max x (maximum xs)
+  where
+    max a b    = if a < b then b else a
+\end{code}
+
+Now, suppose we have refinements:
+
+\begin{code}
+{-@ type Pos  = {v:Int | 0 < v} @-}
+{-@ type Neg  = {v:Int | 0 > v} @-}
+\end{code}
+
+**Here's the problem:** how can *specify* the behavior of `maximum`
+in a way that lets us verify that:
+
+\begin{code}
+{-@ posMax :: [Int] -> Pos @-}
+posMax xs = maximum [x | x <- xs, x > 0]
+
+{-@ negMax :: [Int] -> Neg @-}
+negMax xs = maximum [x | x <- xs, x < 0]
+\end{code}
+
+In the first case, the output of `maximum` must be
+a `Pos` because *every* input was a `Pos`. Thus, we
+might try to type:
+
+\begin{spec}
+maximum :: [Pos] -> Pos
+\end{spec}
+
+But this specification will not let us verify `negMax`.
+Thus, we have a problem: how can we write a precise
+specification for `maximum` that we can *reuse* at
+different call-sites. Further, how can we do so
+enumerating *a priori* the possible contexts (e.g.
+`Pos` and `Neg` lists) in which the function may
+be used?
+
+Abstracting Refinements
+-----------------------
+
+The first idea is one we've [seen before][AbstractRefinements].
+Notice that `maximum` returns _one of_ the elements in its input
+list. Thus, if *every* element of the list satisfies some
+refinement `p` then the output value is also guaranteed to
+satisfy `p`. We formalize this notion by *abstracting refinements*
+over type specifications. That is, we can type `maximum` as:
+
+\begin{code}
+{-@ maximum :: forall  Prop>. [Int
] -> Int
 @-}
+\end{code}
+
+Informally, `Int
` stands for `{v:Int | p v}`, that is, `Int`s that
+satisfy the property `p`. The signature states that for any property
+`p` (of `Int`s), if the input is a list of elements satisfying `p` then
+the output is an `Int` satisfying `p`. We can coax SMT solvers into
+proving the above type by encoding `p v` as an [uninterpreted function](https://en.wikipedia.org/wiki/Uninterpreted_function)
+in the refinement logic.
+
+Thus, refinement abstraction is analagous to type abstraction: it lets us
+parameterize signatures over *all* refinements (analogously, types) that
+may be _passed in_ at the call-site.
+
+Capturing Dependencies between Relations
+----------------------------------------
+
+Unfortunately, in the dependent setting, this is not enough.
+Consider `incr` which bumps up its input by 1:
+
+\begin{code}
+{-@ incr :: x:Int -> {v:Int | v = x + 1} @-}
+incr x = x + 1
+\end{code}
+
+We can use `incr` to write and check:
+
+\begin{code}
+{-@ incr2 :: x:Int -> {v:Int | v = x + 2} @-}
+incr2 x = let y = incr x
+              z = incr y
+          in
+              z
+\end{code}
+
+LH uses the specification of `incr` to infer that
+
++ `y :: {v:Int | v = x + 1}`
++ `z :: {v:Int | v = y + 1}`
+
+and hence, that the result `z` equals `x + 2`.
+
+Now, you're probably wondering to yourself: isn't
+this what _function composition_ is for? Indeed!
+Lets define:
+
+\begin{code}
+{-@ compose' :: (b -> c) -> (a -> b) -> a -> c @-}
+compose' f g x = f (g x)
+\end{code}
+
+Now, we might try:
+
+\begin{code}
+{-@ incr2' :: x:Int -> {v:Int | v = x + 2} @-}
+incr2' = compose' incr incr
+\end{code}
+
+**Problem 1: Cannot Relate Abstracted Types**
+
+LH _rejects_ the above. This might seem counterintuitive but
+in fact, its the right thing to do given the specification of
+`compose'` -- at this call-site, each of `a`, `b` and `c` are
+instantiated with `Int` as we have no way of *relating* the
+invariants associated with those types, e.g. that `b` is one
+greater than `a` and `c` is one greater than `b`.
+
+**Problem 2: Cannot Reuse Concrete Types**
+
+At the other extreme, we might try to give compose a concrete
+signature:
+
+\begin{code}
+{-@ compose'' :: (y:Int -> {z:Int | z = y + 1})
+              -> (x:Int -> {z:Int | z = x + 1})
+              ->  x:Int -> {z:Int | z = x + 2} @-}
+compose'' f g x = f (g x)
+\end{code}
+
+This time, LH does verify
+
+\begin{code}
+{-@ incr2'' :: x:Int -> {v:Int | v = x + 2} @-}
+incr2'' = compose'' incr incr
+\end{code}
+
+but this is a pyrhhic victory as we can only `compose` the
+toy `incr` function (with itself!) and any attempt to use
+it elsewhere will throw a type error.
+
+Goal: Relate Refinements But Keep them Abstract
+-----------------------------------------------
+
+The above toy example illustrates the _real_ problem: how
+can we **relate** the invariants of the type parameters for
+`compose` while simultaneously keeping them **abstract** ?
+
+**Can Abstract Refinements Help?**
+
+HEREHEREHERE
+
+Onto abstracting the type of compose we follow the route of [Abstract Refinements][AbstractRefinements].
+We make a second attempt to type function composition and give
+`compose2` a type that states that
+forall abstract refinements `p`, `q` and `r`
+if (1) the first functional argument `f` returns a value that satisfies a relation `p` with respect to its argument `y`, and
+   (2) the second functional argument `g` returns a value that satisfies a relation `q` with respect to its argument `x`,
+then the result function returns a value that satisfies a relation `r` with respect to its argument `x`:
+
+\begin{code}
+{-@ compose''' :: forall 
 c -> Prop,
+                          q :: a -> b -> Prop,
+                          r :: a -> c -> Prop>.
+                   (y:b -> c
)
+                -> (x:a -> b)
+                -> x:a -> c                   @-}
+\end{code}
+
+With this type for `compose2` liquidHaskell will prove that composing `incr` by itself
+gives a function that increased its argument by `2`:
+
+\begin{code}
+{-@ incr2'' :: x:Int -> {v:Int | v = x + 2} @-}
+incr2''      = compose2 incr incr
+\end{code}
+
+To do so, liquidHaskell will employ the Abstract Refinement Types inference and guess
+the appropriate instantiations for `p`, `q`, and `r`.
+That is, liquidHaskell will infer that `p` and `q` relate two consecutive numbers
+`p, q := \x v -> v = x + 1`
+while `r` relates two numbers with distance `2`:
+`r := \x v -> v = x + 2`.
+Thus, at this specific call site the abstract type of `compose2` will be instantiated to
+the concrete type we gave to `compose1`.
+And, verification of `incr2''` will succeed.
+
+
+What is the catch now?
+In this second attempt we abstracted the type of `compose2` too much!
+In fact, LiquidHaskell cannot prove that the body of `compose2` satisfies its type, just because it does not.
+
+\begin{code}
+compose2 f g x = let z = g x in f z
+\end{code}
+
+By the precondition of `compose2` we know the result refinements of the functional arguments `f` and `g`.
+From the type of `g` we know that `z` satisfies `q` on `x`, i.e. `q x z` holds.
+Similarly, from the type of `f` we know that `f z` satisfies `q` on `x`, i.e. `q x z` holds.
+
+With these, liquidHaskell needs to prove that the result `f z` satisfies `r` on `x`, i.e., `r x z` holds.
+The required property `r x z` is not satisfied for _arbitrary_ abstract refinements `p`, `q` and `r`, but only for ones that satisfy a _chain property_ that states that for all `x`, `y` and `z`, if `q x y` and `p y z` holds, then `r x z` holds:
+
+

+
+`\ x y z -> q x y ==> p y z ==> r x z`
+
+Bound Abstract Refinements by the Chain Property
+------------------------------------------------
+
+We made two attempts to type `compose`.
+The first one "failed" as our type was unrealistically specific.
+The second failed as it was unsoundly general.
+In our third and final attempt
+we give `compose` a type that is abstracted over three abstract refinements `p`, `q` and `r`.
+But, this time the three refinements are not arbitrary:
+they are bounded to satisfy the chain property.
+
+We encode the chain property as a boolean Haskell function:
+
+\begin{code}
+chain :: (b -> c -> Bool) -> (a -> b -> Bool)
+      -> (a -> c -> Bool) ->  a -> b -> c -> Bool
+chain p q r = \ x y z -> q x y ==> p y z ==> r x z
+\end{code}
+
+Then we use the new liquidHaskell keyword `bound` to lift the
+`chain` function into the a logical bound that
+can be used to constrain abstract refinements
+
+\begin{code}
+{-@ bound chain @-}
+\end{code}
+
+The above bound annotation defines the bound `Chain` that is used as a
+constraint that relates the abstract refinements `p`, `q` and `r`
+in the type signature of `compose`
+
+\begin{code}
+{-@
+compose :: forall 
 c -> Prop,
+                   q :: a -> b -> Prop,
+                   r :: a -> c -> Prop>.
+           (Chain b c a p q r)
+        => (y:b -> c
)
+        -> (z:a -> b)
+        ->  x:a -> c
+@-}
+\end{code}
+
+This type of `compose` is both sound and general enough,
+as now we can easily prove that composing `incr` with `incr2`
+results in a function that increases its argument by `3`.
+
+\begin{code}
+{-@ incr2''' :: x:Int -> {v:Int | v = x + 2} @-}
+incr2'''      = compose incr incr
+
+{-@ incr3'' :: x:Int -> {v:Int | v = x + 3} @-}
+incr3''      = compose incr2'' incr
+\end{code}
+
+
+Conclusion
+----------
+We saw how bounds in refinement types allow us to specify a
+precise and general type for function composition.
+Bounds in refinement types are (haskell typeclases-like) constraints
+that constraint the abstract refinement variables to specify certain properties.
+
+We note that liquidHaskell desugars bounds to unbounded refinement types,
+thus verification is still performed decidably using the power of the SMT solvers.
+
+Moreover, function composition is not the exclusive user of
+Bounded Refinement Types.
+On the contrary, we used Bounded Refinement Types
+to verify a variety of code, from list-filtering to relational databases.
+
+Read more about bounds in our [ICFP'15 paper][icfp15],
+and stay tuned!
+
+

+
+
+[icfp15]: http://goto.ucsd.edu/~nvazou/icfp15/main.pdf
+[AbstractRefinements]: http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/blog/2013/06/03/abstracting-over-refinements.lhs
+[queue-wiki]: http://en.wikipedia.org/wiki/Queue_%28abstract_data_type%29
diff --git a/docs/blog/2016-09-01-normal-forms.lhs b/docs/blog/2016-09-01-normal-forms.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2016-09-01-normal-forms.lhs
@@ -0,0 +1,411 @@
+---
+layout: post
+title: "Normal Forms"
+date: 2016-09-05
+comments: true
+external-url:
+author: Ranjit Jhala
+published: true
+categories: measures
+demo: ANF.hs
+---
+
+I have been preparing an undergraduate course on
+Compilers in which we build a compiler that crunches
+an ML-like language to X86 assembly.
+One of my favorite steps in the compilation is the
+[conversion to A-Normal Form (ANF)][anf-felleisen]
+where, informally speaking, each call or primitive
+operation's arguments are **immediate** values,
+i.e. constants or variable lookups whose values can
+be loaded with a single machine instruction. For example,
+the expression
+
+```haskell
+((2 + 3) * (12 - 4)) * (7 + 8)
+```
+
+has the A-Normal Form:
+
+```haskell
+"let anf0 = 2 + 3
+     anf1 = 12 - 4
+     anf2 = anf0 * anf1
+     anf3 = 7 + 8
+  in
+    anf2 * anf3
+```
+
+The usual presentation of ANF conversion
+is very elegant but relies upon a clever
+use of [continuations][anf-might].
+Lets look at another perhaps simpler approach,
+where we can use refinements to light the way.
+
+
+
+
+
+Source Language
+---------------
+
+Lets commence by defining the source language that we wish to work with:
+
+\begin{code}
+data Expr
+  = EInt  Int               -- ^ Integers
+  | EVar  Var               -- ^ Variables
+  | EBin  Op   Expr Expr    -- ^ Binary Operators
+  | ELet  Var  Expr Expr    -- ^ Let-binders
+  | ELam  Var  Expr         -- ^ Function definitions
+  | EApp  Expr Expr         -- ^ Function applications
+  deriving (Show)
+\end{code}
+
+The language, defined by `Expr` has integers, variables, binary operators,
+let-binders and function definitions (lambdas) and calls (applications).
+In the above, `Var` and `Op` are simply:
+
+\begin{code}
+type Var = String
+
+data Op  = Plus | Minus | Times
+         deriving (Show)
+\end{code}
+
+For example, the source expression above corresponds to the value:
+
+\begin{code}
+-- ((2 + 3) * (12 - 4)) * (7 + 8)
+srcExpr :: Expr
+srcExpr = EBin Times
+            (EBin Times
+              (EBin Plus  (EInt  2) (EInt 3))
+              (EBin Minus (EInt 12) (EInt 4)))
+            (EBin Plus (EInt 7) (EInt 8))
+\end{code}
+
+A-Normal Form
+-------------
+
+Before we can describe a _conversion_ to A-Normal Form (ANF),
+we must pin down what ANF _is_. Our informal description was:
+``each call or primitive operation's arguments are immediate
+  values, i.e. constants or variable lookups''.
+
+We _could_ define a brand new datatypes, say `IExpr` and `AExpr`
+whose values correspond to _immediate_ and _ANF_ terms.
+(Try it, as an exercise.) Unfortunately, doing so leads to a
+bunch of code duplication, e.g. duplicate printers for `Expr`
+and `AExpr`. Instead, lets see how we can use refinements to
+carve out suitable subsets.
+
+**Immediate Expressions**
+
+An `Expr` is **immediate** if it is a `Number` or a `Var`;
+we can formalize this as a Haskell predicate:
+
+\begin{code}
+{-@ measure isImm @-}
+isImm :: Expr -> Bool
+isImm (EInt _) = True
+isImm (EVar _) = True
+isImm _        = False
+\end{code}
+
+and then we can use the predicate to define a refinement type
+for _immediate_ expressions:
+
+\begin{code}
+{-@ type ImmExpr = {v:Expr | isImm v} @-}
+\end{code}
+
+For example, `e1` is immediate but `e2` is not:
+
+\begin{code}
+{-@ e1 :: ImmExpr @-}
+e1 = EInt 7
+
+{-@ e2 :: ImmExpr @-}
+e2 = EBin Plus e1 e1
+\end{code}
+
+**ANF Expressions**
+
+Similiarly, an `Expr` is in **ANF** if all arguments for operators
+and applications are **immediate**. Once again, we can formalize
+this intuition as a Haskell predicate:
+
+\begin{code}
+{-@ measure isAnf @-}
+isAnf :: Expr -> Bool
+isAnf (EInt {})      = True
+isAnf (EVar {})      = True
+isAnf (EBin _ e1 e2) = isImm e1 && isImm e2  -- args for operators
+isAnf (EApp e1 e2)   = isImm e1 && isImm e2  -- must be immediate,
+isAnf (ELet _ e1 e2) = isAnf e1 && isAnf e2  -- and sub-expressions
+isAnf (ELam _ e)     = isAnf e               -- must be in ANF
+\end{code}
+
+and then use the predicate to define the subset of _legal_ ANF expressions:
+
+\begin{code}
+{-@ type AnfExpr = {v:Expr | isAnf v} @-}
+\end{code}
+
+For example, `e2` above _is_ in ANF but `e3` is not:
+
+\begin{code}
+{-@ e2' :: AnfExpr @-}
+e2' = EBin Plus e1 e1
+
+{-@ e3 :: AnfExpr @-}
+e3 = EBin Plus e2' e2'
+\end{code}
+
+ANF Conversion: Intuition
+-------------------------
+
+Now that we have clearly demarcated the territories belonging to plain `Expr`,
+immediate `ImmExpr` and A-Normal `AnfExpr`, lets see how we can convert the
+former to the latter.
+
+Our goal is to convert expressions like
+
+```haskell
+((2 + 3) * (12 - 4)) * (7 + 8)
+```
+
+into
+
+```haskell
+let anf0 = 2 + 3
+    anf1 = 12 - 4
+    anf2 = anf0 * anf1
+    anf3 = 7 + 8
+in
+    anf2 * anf3
+```
+
+Generalising a bit, we want to convert
+
+```haskell
+e1 + e2
+```
+
+into
+
+```
+let x1  = a1  ... xn  = an
+    x1' = a1' ... xm' = am'
+in
+    v1 + v2
+```
+
+where, `v1` and `v2` are immediate, and `ai` are ANF.
+
+**Making Arguments Immediate**
+
+In other words, the key requirement is a way to crunch
+arbitrary _argument expressions_ like `e1` into **a pair**
+
+```haskell
+([(x1, a1) ... (xn, an)], v1)
+```
+
+where
+
+1. `a1...an` are `AnfExpr`, and
+2. `v1` is an immediate `ImmExpr`
+
+such that `e1` is _equivalent_ to `let x1 = a1 ... xn = an in v1`.
+Thus, we need a function
+
+```haskell
+imm :: Expr -> ([(Var, AnfExpr)], ImmExpr)
+```
+
+which we will use to **make arguments immediate** thereby yielding
+a top level conversion function
+
+```haskell
+anf :: Expr -> AnfExpr
+```
+
+As we need to generate "temporary" intermediate
+binders, it will be convenient to work within a
+monad that generates `fresh` variables:
+
+\begin{code}
+type AnfM a = State Int a
+
+fresh :: AnfM Var
+fresh = do
+  n <- get
+  put (n+1)
+  return ("anf" ++ show n)
+\end{code}
+
+Thus, the conversion functions will have the types:
+
+```haskell
+anf :: Expr -> AnfM AnfExpr
+imm :: Expr -> AnfM ([(Var, AnfExpr)], ImmExpr)
+```
+
+ANF Conversion: Code
+--------------------
+
+We can now define the top-level conversion thus:
+
+\begin{code}
+--------------------------------------------------------------------------------
+{-@ anf :: Expr -> AnfM AnfExpr @-}
+--------------------------------------------------------------------------------
+anf (EInt n) =
+  return (EInt n)
+
+anf (EVar x) =
+  return (EVar x)
+
+anf (ELet x e1 e2) = do
+  a1 <- anf e1
+  a2 <- anf e2
+  return (ELet x a1 a2)
+
+anf (EBin o e1 e2) = do
+  (b1s, v1) <- imm e1
+  (b2s, v2) <- imm e2
+  return (mkLet (b1s ++ b2s) (EBin o v1 v2))
+
+anf (ELam x e) = do
+  a <- anf e
+  return (ELam x a)
+
+anf (EApp e1 e2) = do
+  (b1s, v1) <- imm e1
+  (b2s, v2) <- imm e2
+  return (mkLet (b1s ++ b2s) (EApp v1 v2))
+\end{code}
+
+In `anf` the real work happens inside `imm` which takes an arbitary
+_argument_ expression and makes it **immediate** by generating temporary
+(ANF) bindings. The resulting bindings (and immediate values) are
+composed by the helper `mkLet` that takes a list of binders and a body
+`AnfExpr` and stitches them into a single `AnfExpr`:
+
+\begin{code}
+{-@ mkLet :: [(Var, AnfExpr)] -> AnfExpr -> AnfExpr @-}
+mkLet []         e' = e'
+mkLet ((x,e):bs) e' = ELet x e (mkLet bs e')
+\end{code}
+
+The arguments are made immediate by `imm` defined as:
+
+\begin{code}
+--------------------------------------------------------------------------------
+{-@ imm :: Expr -> AnfM ([(Var, AnfExpr)], ImmExpr) @-}
+--------------------------------------------------------------------------------
+imm (EInt n)       = return ([], EInt n)
+imm (EVar x)       = return ([], EVar x)
+imm e@(ELet {})    = immExpr e
+imm e@(ELam {})    = immExpr e
+imm (EBin o e1 e2) = imm2 e1 e2 (EBin o)
+imm (EApp e1 e2)   = imm2 e1 e2 EApp
+\end{code}
+
+* Numbers and variables are already immediate, and are returned directly.
+
+* Let-binders and lambdas are simply converted to ANF, and assigned to a fresh
+  binder:
+
+\begin{code}
+{-@ immExpr :: Expr -> AnfM ([(Var, AnfExpr)], ImmExpr) @-}
+immExpr e = do
+  a <- anf e
+  t <- fresh
+  return ([(t, a)], EVar t)
+\end{code}
+
+* Finally, binary operators and applications are converted by `imm2` that
+  takes two arbitrary expressions and an expression constructor, yielding
+  the anf-binders and immediate expression.
+
+\begin{code}
+imm2 :: Expr -> Expr -> (ImmExpr -> ImmExpr -> AnfExpr)
+     -> AnfM ([(Var, AnfExpr)], ImmExpr)
+imm2 e1 e2 f = do
+  (b1s, v1) <- imm e1
+  (b2s, v2) <- imm e2
+  t         <- fresh
+  let bs'    = b1s ++ b2s ++ [(t, f v1 v2)]
+  return      (bs', EVar t)
+\end{code}
+
+
+You can run it thus:
+
+\begin{code}
+toAnf :: Expr -> AnfExpr
+toAnf e = evalState (anf e) 0
+\end{code}
+
+```haskell
+ghci> toAnf srcExpr
+ELet "anf0" (EBin Plus (EInt 2) (EInt 3))
+ (ELet "anf1" (EBin Minus (EInt 12) (EInt 4))
+   (ELet "anf2" (EBin Times (EVar "anf0") (EVar "anf1"))
+     (ELet "anf3" (EBin Plus (EInt 7) (EInt 8))
+       (EBin Times (EVar "anf2") (EVar "anf3")))))
+```
+
+which, can be pretty-printed to yield exactly the outcome desired at the top:
+
+```haskell
+let anf0 = 2 + 3
+    anf1 = 12 - 4
+    anf2 = anf0 * anf1
+    anf3 = 7 + 8
+in
+    anf2 * anf3
+```
+
+
+There! The refinements make this tricky conversion quite
+straightforward and natural, without requiring us to
+duplicate types and code. As an exercise, can you use
+refinements to:
+
+1. Port the classic [continuation-based conversion ?][anf-might]
+2. Check that the conversion yields [well-scoped terms ?][lh-scoped]
+
+[lh-scoped]: http://ucsd-progsys.github.io/liquidhaskell-tutorial/10-case-study-associative-maps.html#/using-maps-well-scoped-expressions
+[anf-felleisen]: https://users.soe.ucsc.edu/~cormac/papers/pldi93.pdf
+[anf-might]: http://matt.might.net/articles/a-normalization/
diff --git a/docs/blog/2016-09-18-refinement-reflection.lhs b/docs/blog/2016-09-18-refinement-reflection.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2016-09-18-refinement-reflection.lhs
@@ -0,0 +1,408 @@
+---
+layout: post
+title: "Refinement Reflection: Haskell as a theorem prover"
+date: 2016-09-18
+comments: true
+external-url:
+author: Niki Vazou
+published: true
+categories: reflection
+demo: RefinementReflection.hs
+---
+
+We've taught LiquidHaskell a new trick that we call ``Refinement Reflection''
+which lets us turn Haskell into a theorem prover capable of proving arbitrary
+properties of code. The key idea is to **reflect** the code of the function into
+its **output type**, which lets us then reason about the function at the
+(refinement) type level. Lets see how to use refinement types to express a
+theorem, for example that fibonacci is a monotonically increasing function, 
+then write plain Haskell code to reify a paper-and-pencil-style proof 
+for that theorem, that can be machine checked by LiquidHaskell.
+
+
+
+

+

+

+
+

+  

+  Reflection
+       

+       

+       

+       The beauty of Liquid Reflection.
+       

+       

+       

+  

+

+
+
+
+
+Shallow vs. Deep Specifications
+-------------------------------
+
+Up to now, we have been using Liquid Haskell to specify and verify "shallow"
+specifications that abstractly describe the behavior of functions.  For example,
+below, we specify and verify that `fib`restricted to natural numbers, always
+terminates returning a natural number.
+
+\begin{code}
+{-@ fib :: i:Nat -> Nat / [i] @-}
+fib i | i == 0    = 0 
+      | i == 1    = 1 
+      | otherwise = fib (i-1) + fib (i-2)
+\end{code}
+
+In this post we present how refinement reflection is used to verify 
+"deep" specifications that use the exact definition of Haskell functions. 
+For example, we will prove that the Haskell `fib` function is increasing.
+
+
+
+Propositions
+------------
+
+To begin, we import [ProofCombinators][proofcomb], a (Liquid) Haskell 
+library that defines and manipulates logical proofs. 
+
+```haskell
+import Language.Haskell.Liquid.ProofCombinators
+```
+
+A `Proof` is a data type that carries no run time information
+
+```haskell
+type Proof = ()
+```
+
+but can be refined with desired logical propositions.
+For example, the following type states that `1 + 1 == 2`
+
+\begin{code}
+{-@ type OnePlusOne = {v: Proof | 1 + 1 == 2} @-}
+\end{code}
+
+Since the `v` and `Proof` are irrelevant, we may as well abbreviate 
+the above to 
+
+\begin{code}
+{-@ type OnePlusOne' = { 1 + 1 == 2 } @-}
+\end{code}
+
+
+As another example, the following function type declares 
+that _for each_ `x` and `y` the plus operator commutes. 
+
+\begin{code}
+{-@ type PlusComm = x:Int -> y:Int -> {x + y == y + x} @-} 
+\end{code}
+
+
+
+Trivial Proofs
+--------------
+
+We prove the above theorems using Haskell programs. 
+The `ProofCombinators` module defines the `trivial` proof
+
+```haskell
+trivial :: Proof 
+trivial = ()
+```
+
+and the "casting" operator `(***)` that makes proof terms look 
+nice:
+
+```haskell
+data QED = QED
+
+(***) :: a -> QED -> Proof
+_ *** _ = ()
+```
+
+Using the underlying SMT's knowledge on linear arithmetic, 
+we can trivially prove the above propositions.
+
+\begin{code}
+{-@ propOnePlusOne :: _ -> OnePlusOne @-} 
+propOnePlusOne _ = trivial *** QED 
+
+{-@ propPlusComm :: PlusComm @-} 
+propPlusComm _ _ = trivial *** QED 
+\end{code}
+
+
+We saw how we use SMT's knowledge on linear arithmetic 
+to trivially prove arithmetic properties. But how can 
+we prove ``deep'' properties on Haskell's functions?
+
+
+Refinement Reflection 
+---------------------
+
+Refinement Reflection allows deep specification and 
+verification by reflecting the code implementing a Haskell
+function into the function’s output refinement type.
+
+Refinement Reflection proceeds in 3 steps: definition, reflection, and application.
+Consider reflecting the definition of `fib` into the logic
+
+\begin{code}
+{-@ reflect fib @-}
+\end{code}
+
+then the following three reflection steps will occur. 
+
+Step 1: Definition 
+------------------
+
+Reflection of the Haskell function `fib` defines in logic 
+an _uninterpreted_ function `fib` that satisfies the congruence axiom.
+
+In the logic the function `fib` is defined.
+
+```haskell
+fib :: Int -> Int 
+```
+
+SMT only knows that `fib` satisfies the congruence axiom.
+
+\begin{code}
+{-@ fibCongruence :: i:Nat -> j:Nat -> {i == j => fib i == fib j} @-}
+fibCongruence _ _ = trivial *** QED 
+\end{code}
+
+Other than congruence, SMT knowns nothing for the function `fib`,
+until reflection happens!
+
+
+Step 2: Reflection
+------------------
+
+As a second step, Liquid Haskell connects the Haskell function `fib`
+with the homonymous logical function, 
+by reflecting the implementation of `fib` in its result type. 
+
+
+The result type of `fib` is automatically strengthened to the following.
+
+```haskell
+fib :: i:Nat -> {v:Nat | v == fib i && v = fibP i }
+```
+
+That is, the result satisfies the `fibP` predicate
+exactly reflecting the implementation of `fib`.
+
+```haskell
+fibP i = if i == 0 then 0 else
+         if i == 1 then 1 else
+         fib (i-1) + fib (i-2)
+```
+
+Step 3: Application 
+-------------------
+
+With the reflected refinement type,
+each application of `fib` automatically unfolds the definition of `fib` 
+once. 
+As an example, applying `fib` to `0`, `1`, and `2` allows us to prove that `fib 2 == 1`:
+
+\begin{code}
+{-@ fibTwo :: _ -> { fib 2 == 1 } @-}
+fibTwo _ = [fib 0, fib 1, fib 2] *** QED
+\end{code}
+
+Though valid, the above `fibTwo` proof is not pretty! 
+
+
+Structuring Proofs 
+------------------
+
+To make our proofs look nice, we use combinators from 
+the `ProofCombinators` library, which exports a family 
+of operators `(*.)` where `*` comes from the theory of 
+linear arithmetic and the refinement type of `x *. y` 
+
++ **requires** that `x *. y` holds and 
++ **ensures** that the returned value is equal to `x`.
+
+For example, `(==.)` and `(<=.)` are predefined in `ProofCombinators` as
+
+```haskell
+(==.) :: x:a -> y:{a| x==y} -> {v:a| v==x}
+x ==. _ = x
+
+(<=.) :: x:a -> y:{a| x<=y} -> {v:a| v==x}
+x <=. _ = x
+```
+
+Using these predefined operators, we construct paper and pencil-like proofs 
+for the `fib` function.
+
+\begin{code}
+{-@ fibTwoPretty :: { fib 2 == 1 } @-}
+fibTwoPretty 
+  =   fib 2 
+  ==. fib 1 + fib 0 
+  *** QED
+\end{code}
+
+
+
+Because operator 
+-----------------
+
+To allow the reuse of existing proofs, `ProofCombinators` defines the because 
+operator `(∵)`
+
+```haskell
+(∵) :: (Proof -> a) -> Proof -> a
+f ∵ y = f y
+```
+
+For example, `fib 3 == 2` holds because `fib 2 == 1`:
+
+\begin{code}
+{-@ fibThree :: _ -> { fib 3 == 2 } @-}
+fibThree _ 
+  =   fib 3 
+  ==. fib 2 + fib 1
+  ==. 1     + 1      ∵ fibTwoPretty
+  ==. 2 
+  *** QED
+\end{code}
+
+
+
+Proofs by Induction (i.e. Recursion) 
+------------------------------------
+
+Next, combining the above operators we specify and prove that 
+`fib` is increasing, that is for each natural number `i`, 
+`fib i <= fib (i+1)`. 
+
+We specify the theorem as a refinement type for `fibUp`
+and use Haskell code to persuade Liquid Haskell that 
+the theorem holds. 
+
+\begin{code}
+{-@ fibUp :: i:Nat -> {fib i <= fib (i+1)} @-}
+fibUp i
+  | i == 0
+  =   fib 0 <. fib 1
+  *** QED
+
+  | i == 1
+  =   fib 1 <=. fib 1 + fib 0 <=. fib 2
+  *** QED
+
+  | otherwise
+  =   fib i
+  ==. fib (i-1) + fib (i-2)
+  <=. fib i     + fib (i-2) ∵ fibUp (i-1)
+  <=. fib i     + fib (i-1) ∵ fibUp (i-2)
+  <=. fib (i+1)
+  *** QED
+\end{code}
+
+The proof proceeds _by induction on_ `i`. 
+
++ The base cases `i == 0` and `i == 1` are represented 
+  as Haskell's case splitting. 
+
++ The inductive hypothesis is represented by recursive calls 
+  on smaller inputs. 
+
+Finally, the SMT solves arithmetic reasoning to conclude the proof.  
+
+Higher Order Theorems
+----------------------
+
+Refinement Reflection can be used to express and verify higher order theorems!
+For example, `fMono` specifies that each locally increasing function is monotonic! 
+
+\begin{code}
+{-@ fMono :: f:(Nat -> Int)
+          -> fUp:(z:Nat -> {f z <= f (z+1)})
+          -> x:Nat
+          -> y:{Nat|x < y}
+          -> {f x <= f y} / [y] 
+  @-}
+fMono f thm x y  
+  | x + 1 == y
+  = f y ==. f (x + 1)
+         >. f x       ∵ thm x
+        *** QED
+
+  | x + 1 < y
+  = f x
+  <.  f (y-1)         ∵ fMono f thm x (y-1)
+  <.  f y             ∵ thm (y-1)
+  *** QED
+\end{code}
+
+Again, the recursive implementation of `fMono` depicts the paper and pencil 
+proof of `fMono` by induction on the decreasing argument `/ [y]`. 
+
+Since `fib` is proven to be locally increasing by `fUp`, we use `fMono` 
+to prove that `fib` is monotonic. 
+
+\begin{code}
+{-@ fibMono :: n:Nat -> m:{Nat | n < m }  -> {fib n <= fib m} @-}
+fibMono = fMono fib fibUp
+\end{code}
+
+
+Conclusion
+----------
+
+We saw how refinement reflection turns Haskell
+into a theorem prover by reflecting the code 
+implementing a Haskell function into the 
+function’s output refinement type.
+
+Refinement Types are used to express theorems, 
+Haskell code is used to prove such theorems
+expressing paper pencil proofs, and Liquid Haskell 
+verifies the validity of the proofs!
+
+Proving `fib` monotonic is great, but this is Haskell!
+Wouldn’t it be nice to prove theorems about inductive data types 
+and higher order functions? Like fusions and folds? 
+Or program equivalence on run-time optimizations like map-reduce?
+
+Stay tuned!
+
+Even better, if you happen you be in Nara for ICFP'16, 
+come to my [CUFP tutorial][cufp16] for more!
+
+
+[cufp16]: http://cufp.org/2016/t6-niki-vazou-liquid-haskell-intro.html
+[proofcomb]:https://github.com/ucsd-progsys/liquidhaskell/blob/develop/include/Language/Haskell/Liquid/ProofCombinators.hs
diff --git a/docs/blog/2016-10-06-structural-induction.lhs b/docs/blog/2016-10-06-structural-induction.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2016-10-06-structural-induction.lhs
@@ -0,0 +1,280 @@
+---
+layout: post
+title: "Refinement Reflection on ADTs: Lists are Monoids"
+date: 2016-10-06
+comments: true
+external-url:
+author: Niki Vazou
+published: true
+categories: reflection, induction, measures, monoids
+demo: MonoidList.hs
+---
+
+[Previously][refinement-reflection] we saw how Refinement Reflection
+can be used to write and prove **in Haskell** theorems **about Haskell**
+functions and have such proofs machine checked.
+
+Today, we will see how Refinement Reflection works on **recursive data types**.
+
+As an example, we will prove that **lists are monoids** (under nil and append).
+
+Lets see how to express
+
+* the (monoid) laws as liquid types,
+* the (monoid) proofs as plain haskell functions,
+
+and have LiquidHaskell check that the code indeed
+proves the corresponding laws.
+
+
+
+

+

+

+
+

+  

+  Recursion
+       

+       

+       

+       Recursive Paper and Pencil Proofs.
+       "Drawing Hands" by Escher.
+       

+       

+       

+  

+

+
+
+
+
+Lists
+-----
+
+First, lets define the `List a` data type
+
+\begin{code}
+data List a = N | C a (List a)
+\end{code}
+
+Induction on Lists
+------------------
+
+As we will see, *proofs* by structural induction will correspond to
+*programs* that perform *recursion* on lists. To keep things legit,
+we must verify that those programs are total and terminating.
+
+To that end, lets define a `length` function that
+computes the natural number that is the size of a
+list.
+
+\begin{code}
+{-@ measure length               @-}
+{-@ length      :: List a -> Nat @-}
+length N        = 0
+length (C x xs) = 1 + length xs
+\end{code}
+
+We lift `length` in the logic, as a [measure][the-advantage-of-measures].
+
+We can now tell Liquid Haskell that when proving termination
+on recursive functions with a list argument `xs`, it should
+check whether the `length xs` is decreasing.
+
+\begin{code}
+{-@ data List [length] a = N | C {hd :: a, tl :: List a} @-}
+\end{code}
+
+
+Reflecting Lists into the Logic
+-------------------------------
+
+To talk about lists in the logic, we use the annotation
+
+\begin{code}
+{-@ LIQUID "--exact-data-cons" @-}
+\end{code}
+
+which **automatically** derives measures for
+
+* *testing* if a value has a given data constructor, and
+* *extracting* the corresponding field's value.
+
+For our example, LH will automatically derive the following
+functions in the refinement logic.
+
+\begin{spec}
+isN :: L a -> Bool         -- Haskell's null
+isC :: L a -> Bool         -- Haskell's not . null
+
+select_C_1 :: L a -> a     -- Haskell's head
+select_C_2 :: L a -> L a   -- Haskell's tail
+\end{spec}
+
+A programmer *never* sees the above operators; they are internally
+used by LH to **reflect** Haskell functions into the refinement logic,
+as we shall see shortly.
+
+Defining the Monoid Operators
+-----------------------------
+
+A structure is a monoid, when it has two operators:
+
+* the identity element `empty` and
+* an associative operator `<>`.
+
+Lets define these two operators for our `List`.
+
+* the identity element is the empty list, and
+* the associative operator `<>` is list append.
+
+\begin{code}
+{-@ reflect empty @-}
+empty  :: List a
+empty  = N
+
+{-@ infix   <> @-}
+{-@ reflect <> @-}
+(<>)           :: List a -> List a -> List a
+N        <> ys = ys
+(C x xs) <> ys = C x (xs <> ys)
+\end{code}
+
+LiquidHaskell automatically checked that the recursive `(<>)` 
+is terminating, by checking that the `length` of its first
+argument is decreasing. Since both the above operators are 
+provably terminating, LH lets us reflect them into logic.
+
+As with our [previous][refinement-reflection]
+`fibonacci` example, reflection of a function
+into logic, means strengthening the result type
+of the function with its implementation.
+
+Thus, the **automatically** derived, strengthened
+types for `empty` and `(<>)` will be
+
+\begin{spec}
+empty   :: {v:List a | v == empty && v == N }
+
+(<>) :: xs:List a -> ys:List a
+     -> {v:List a | v == xs <> ys &&
+                    v == if isN xs then ys else
+                         C (select_C_1 xs) (select_C_2 xs <> ys)
+        }
+\end{spec}
+
+In effect, the derived checker and selector functions are used
+to translate Haskell to logic. The above is just to *explain*
+how LH reasons about the operators; the programmer never (directly) 
+reads or writes the operators `isN` or `select_C_1` etc.
+
+Proving the Monoid Laws
+------------------------
+
+Finally, we have set everything up, (actually LiquidHaskell
+did most of the work for us) and we are ready to prove the
+monoid laws for the `List`.
+
+First we prove left identity of `empty`.
+
+\begin{code}
+{-@ leftId  :: x:List a -> { empty <> x == x } @-}
+leftId x
+   =   empty <> x
+   ==. N <> x
+   ==. x
+   *** QED
+\end{code}
+
+This proof was trivial, because left identity is satisfied
+by the way we defined `(<>)`.
+
+Next, we prove right identity of `empty`.
+
+\begin{code}
+{-@ rightId  :: x:List a -> { x <> empty  == x } @-}
+rightId N
+   =   N <> empty
+   ==. N
+   *** QED
+
+rightId (C x xs)
+   =   (C x xs) <> empty
+   ==. C x (xs <> empty)
+   ==. C x xs        ∵ rightId xs
+   *** QED
+\end{code}
+
+This proof is more tricky, as it requires **structural induction** which is
+encoded in LH proofs simply as **recursion**.  LH ensures that the inductive
+hypothesis is appropriately applied by checking that the recursive proof is
+total and terminating.  In the `rightId` case, for termination, Liquid Haskell
+checked that `length xs < length (C x xs)`.
+
+It turns out that we can prove lots of properties about lists using structural 
+induction, encoded in Haskell as
+
+* case splitting,
+* recursive calls, and
+* rewriting,
+
+To see a last example, lets prove the associativity of `(<>)`.
+
+\begin{code}
+{-@ associativity :: x:List a -> y:List a -> z:List a
+                  -> { x <> (y <> z) == (x <> y) <> z } @-}
+associativity N y z
+  =   N <> (y <> z)
+  ==. y <> z
+  ==. (N <> y) <> z
+  *** QED
+
+associativity (C x xs) y z
+  =  (C x xs) <> (y <> z)
+  ==. C x (xs <> (y <> z))
+  ==. C x ((xs <> y) <> z) ∵ associativity xs y z
+  ==. (C x (xs <> y)) <> z
+  ==. ((C x xs) <> y) <> z
+  *** QED
+\end{code}
+
+The above proof of associativity reifies the paper and pencil 
+proof by structural induction.
+
+With that, we can safely conclude that our user defined list
+is a monoid!
+
+
+Conclusion
+----------
+
+We saw how Refinement Reflection can be used to
+
+- specify properties of `ADTs`,
+- naturally encode structural inductive proofs of these properties, and
+- have these proofs machine checked by Liquid Haskell.
+
+Why is this useful? Because the theorems we prove refer to your Haskell
+functions!  Thus you (or in the future, the compiler) can use properties like
+monoid or monad laws to optimize your Haskell code.  In the future, we will
+present examples of code optimizations using monoid laws. Stay tuned!
+
+
+[refinement-reflection]: http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/blog/2016/09/18/refinement-reflection.lhs/
+[the-advantage-of-measures]: http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/blog/2014/02/11/the-advantage-of-measures.lhs/
diff --git a/docs/blog/2016-12-25-isomorphisms.lhs b/docs/blog/2016-12-25-isomorphisms.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2016-12-25-isomorphisms.lhs
@@ -0,0 +1,342 @@
+---
+layout: post
+title: Isomorphisms for Proof Reductions
+date: 2016-12-25
+comments: true
+external-url:
+author: Vikraman Choudhury and Niki Vazou
+published: true
+categories: reflection 
+demo: Iso.hs
+---
+
+[Previously][refinement-reflection] we saw how Refinement Reflection
+can be used to write and prove **in Haskell** theorems **about Haskell**
+functions and have such proofs machine checked by Liquid Haskell.
+
+As a limitation, Liquid Haskell offers no proof generation techniques: 
+The user needs to manually provide all the proofs. 
+
+Today we will see how proof generation can be simplified by data type isomorphisms. 
+
+As an example, a user defined `Peano` data type enjoyes all the 
+arithmetic properties of natural numbers since `Peano` and natural numbers 
+are provably **isomorphic**. 
+
+
+
+

+

+

+
+

+  

+  Recursion
+       

+       

+       

+       Recursive Paper and Pencil Proofs.
+       "Drawing Hands" by Escher.
+       

+       

+       

+  

+

+
+
+
+
+First, we define `Peano` numbers as a data type 
+and the function `leqPeano` that compares two peano numbers.
+
+
+\begin{code}
+{-@ data Peano [toNat] = Z | S Peano @-}
+data Peano = Z | S Peano deriving (Eq)
+
+{-@ axiomatize leqPeano @-}
+leqPeano :: Peano -> Peano -> Bool
+leqPeano Z _         = True
+leqPeano _ Z         = False
+leqPeano (S n) (S m) = leqPeano n m
+\end{code}
+
+We can use Refinement Reflection to provide an 
+explicit proof that comparison on peano numbers is *total*, 
+that is, for every two numbers `n` and `m` 
+either `leqPeano n m` or `leqPeano m n` always holds. 
+
+\begin{code}
+{-@ leqNTotal :: n:Peano -> m:Peano 
+              -> {(leqPeano n m) || (leqPeano m n)} 
+              / [toNat n + toNat m] @-}
+leqNTotal :: Peano -> Peano -> Proof
+leqNTotal Z m = leqPeano Z m *** QED
+leqNTotal n Z = leqPeano Z n *** QED
+leqNTotal (S n) (S m)
+  =   (leqPeano (S n) (S m) || leqPeano (S m) (S n))
+  ==. (leqPeano n m || leqPeano (S m) (S n)) 
+      ? (leqNTotal n m)
+  ==. (leqPeano n m || leqPeano m n) 
+      ? (leqNTotal m n)
+  *** QED
+\end{code}
+
+The proof proceeds by induction on the sum of `n` and `m`. 
+Liquid Haskell captures this generalized induction by 
+ensuring that the value `toNat n + toNat m` is decreasing
+where `toNat` maps Peano to Natural numbers. 
+
+\begin{code}
+{-@ measure toNat @-}
+{-@ toNat :: Peano -> Nat @-}
+toNat :: Peano -> Int
+toNat Z = 0
+toNat (S n) = 1 + toNat n
+\end{code}
+
+Note, that the type `Nat` is just a refinement for the Haskell's integers
+\begin{spec}
+type Nat = {v:Int | 0 <= v}
+\end{spec}
+
+
+First, we'll express verified typeclasses using Haskell records, but with LiquidHaskell refinements to express laws. As
+an example, let's define `VerifiedOrd`, which is the same as the `Ord` typeclass, but with total order laws added.
+
+\begin{code}
+{-@ data VerifiedOrd a = VerifiedOrd {
+      leq     :: a -> a -> Bool
+    , refl    :: x:a -> { leq x x }
+    , antisym :: x:a -> y:a -> { leq x y && leq y x ==> x == y }
+    , trans   :: x:a -> y:a -> z:a -> { leq x y && leq y z ==> leq x z }
+    , total   :: x:a -> y:a -> { leq x y || leq y x }
+    }
+@-}
+data VerifiedOrd a = VerifiedOrd {
+    leq     :: a -> a -> Bool
+  , refl    :: a -> Proof
+  , antisym :: a -> a -> Proof
+  , trans   :: a -> a -> a -> Proof
+  , total   :: a -> a -> Proof
+}
+\end{code}
+
+The `leq` function represents the `<=` operator in `Ord`, and `refl`, `antisym`, `trans`, `total`, express the
+reflexivity, antisymmetry, transitivity and totality properties respectively, that a total order requires. Notice how
+the refinements express the laws, and the actual code is simply a function that returns `Proof` or `()`.
+
+Now, let's see how to define some simple verified instances. We need to instantiate `leq` for our type, "reflect" it
+into the logic, and prove all the required properties. For primitive types like `Int` or `Double`, it's "trivial"
+because we trust the SMT solver which already knows about integers.
+
+\begin{code}
+{-@ axiomatize leqInt @-}
+leqInt :: Int -> Int -> Bool
+leqInt x y = x <= y
+
+{-@ leqIntRefl :: x:Int -> { leqInt x x } @-}
+leqIntRefl :: Int -> Proof
+leqIntRefl x = leqInt x x ==. x <= x *** QED
+
+{-@ leqIntAntisym :: x:Int -> y:Int -> { leqInt x y && leqInt y x ==> x == y } @-}
+leqIntAntisym :: Int -> Int -> Proof
+leqIntAntisym x y = (leqInt x y && leqInt y x) ==. (x <= y && y <= x) ==. x == y *** QED
+
+{-@ leqIntTrans :: x:Int -> y:Int -> z:Int -> { leqInt x y && leqInt y z ==> leqInt x z } @-}
+leqIntTrans :: Int -> Int -> Int -> Proof
+leqIntTrans x y z = (leqInt x y && leqInt y z) ==. (x <= y && y <= z) ==. x <= z ==. leqInt x z *** QED
+
+{-@ leqIntTotal :: x:Int -> y:Int -> { leqInt x y || leqInt y x } @-}
+leqIntTotal :: Int -> Int -> Proof
+leqIntTotal x y = (leqInt x y || leqInt y x) ==. (x <= y || y <= x) *** QED
+
+vordInt :: VerifiedOrd Int
+vordInt = VerifiedOrd leqInt leqIntRefl leqIntAntisym leqIntTrans leqIntTotal
+\end{code}
+
+How about a complex datatype? Let's consider an inductive datatype, the peano natural numbers. Not surprisingly, the
+proofs follow by induction. For conciseness, we only show totality and elide the rest.
+
+Writing down proofs for more complex datatypes is tedious, it requires case analysis for each constructor and using the
+induction hypothesis. However, we can decompose Haskell datatypes into sums and products, and we can build up compound
+proofs using isomorphisms! To that end, we design some machinery to express isomorphisms, and prove that laws are
+preserved under isomorphic images.
+
+\begin{code}
+{-@ data Iso a b = Iso {
+      to   :: a -> b
+    , from :: b -> a
+    , tof  :: y:b -> { to (from y) == y }
+    , fot  :: x:a -> { from (to x) == x }
+    }
+@-}
+data Iso a b = Iso {
+    to   :: a -> b
+  , from :: b -> a
+  , tof  :: b -> Proof
+  , fot  :: a -> Proof
+}
+\end{code}
+
+An isomorphism between types `a` and `b` is a pair of functions `to :: a -> b` and `from :: b -> a` that are mutually
+inverse to each other. We now claim that total order laws are preserved under `Iso`; this amounts to building up a
+`VerifiedOrd b`, given a `VerifiedOrd a` and an `Iso a b`.
+
+\begin{code}
+{-@ axiomatize leqFrom @-}
+leqFrom :: (a -> a -> Bool)
+        -> (b -> a)
+        -> (b -> b -> Bool)
+leqFrom leqa from x y = leqa (from x) (from y)
+
+{-@ leqFromRefl :: leqa:(a -> a -> Bool) -> leqaRefl:(x:a -> { leqa x x })
+                -> from:(b -> a)
+                -> x:b -> { leqFrom leqa from x x }
+@-}
+leqFromRefl :: (a -> a -> Bool) -> (a -> Proof)
+            -> (b -> a)
+            -> b -> Proof
+leqFromRefl leqa leqaRefl from x =
+      leqFrom leqa from x x
+  ==. leqa (from x) (from x)
+  ==. True ? leqaRefl (from x)
+  *** QED
+
+{-@ leqFromAntisym :: leqa:(a -> a -> Bool)
+                   -> leqaAntisym:(x:a -> y:a -> { leqa x y && leqa y x ==> x == y })
+                   -> to:(a -> b) -> from:(b -> a) -> tof:(y:b -> { to (from y) == y })
+                   -> x:b -> y:b -> { leqFrom leqa from x y && leqFrom leqa from y x ==> x == y }
+@-}
+leqFromAntisym :: (Eq a, Eq b)
+               => (a -> a -> Bool) -> (a -> a -> Proof)
+               -> (a -> b) -> (b -> a) -> (b -> Proof)
+               -> b -> b -> Proof
+leqFromAntisym leqa leqaAntisym to from tof x y
+  =   (leqFrom leqa from x y && leqFrom leqa from y x)
+  ==. (leqa (from x) (from y) && leqa (from y) (from x))
+  ==. from x == from y ? leqaAntisym (from x) (from y)
+  ==. to (from x) == to (from y)
+  ==. x == to (from y) ? tof x
+  ==. x == y           ? tof y
+  *** QED
+
+{-@ leqFromTrans :: leqa:(a -> a -> Bool)
+                 -> leqaTrans:(x:a -> y:a -> z:a -> { (leqa x y) && (leqa y z) ==> (leqa x z) })
+                 -> from:(b -> a)
+                 -> x:b -> y:b -> z:b
+                 -> { leqFrom leqa from x y && leqFrom leqa from y z ==> leqFrom leqa from x z }
+@-}
+leqFromTrans :: (a -> a -> Bool) -> (a -> a -> a -> Proof)
+             -> (b -> a)
+             -> b -> b -> b -> Proof
+leqFromTrans leqa leqaTrans from x y z =
+      (leqFrom leqa from x y && leqFrom leqa from y z)
+  ==. (leqa (from x) (from y) && leqa (from y) (from z))
+  ==. leqa (from x) (from z) ? leqaTrans (from x) (from y) (from z)
+  ==. leqFrom leqa from x z
+  *** QED
+
+{-@ leqFromTotal :: leqa:(a -> a -> Bool) -> leqaTotal:(x:a -> y:a -> { (leqa x y) || (leqa y x) })
+                 -> from:(b -> a) -> x:b -> y:b -> { leqFrom leqa from x y || leqFrom leqa from y x }
+@-}
+leqFromTotal :: (a -> a -> Bool) -> (a -> a -> Proof)
+             -> (b -> a) -> b -> b -> Proof
+leqFromTotal leqa leqaTotal from x y =
+      (leqFrom leqa from x y || leqFrom leqa from y x)
+  ==. (leqa (from x) (from y) || leqa (from y) (from x))
+  ==. True ? leqaTotal (from x) (from y)
+  ==. leqFrom leqa from y x
+  *** QED
+
+vordIso :: (Eq a, Eq b) => Iso a b -> VerifiedOrd a -> VerifiedOrd b
+vordIso (Iso to from tof fot) (VerifiedOrd leqa leqaRefl leqaAntisym leqaTrans leqaTotal) =
+  VerifiedOrd
+    (leqFrom leqa from)
+    (leqFromRefl leqa leqaRefl from)
+    (leqFromAntisym leqa leqaAntisym to from tof)
+    (leqFromTrans leqa leqaTrans from)
+    (leqFromTotal leqa leqaTotal from)
+\end{code}
+
+We can now write a `VerifiedOrd` for `Peano` by mapping it onto `type Nat = { n:Int | 0 <= n }`, which is easier to
+prove properties about because it's just an integer!
+
+\begin{code}
+{-@ type Nat = { n:Int | 0 <= n } @-}
+type Nat = Int
+
+{-@ axiomatize fromNat @-}
+{-@ fromNat :: Nat -> Peano @-}
+fromNat :: Nat -> Peano
+fromNat n
+  | n == 0 = Z
+  | otherwise = S (fromNat (n - 1))
+
+{-@ toFrom :: x:Nat -> { toNat (fromNat x) == x } @-}
+toFrom :: Nat -> Proof
+toFrom n
+  | n == 0 = toNat (fromNat 0) ==. toNat Z ==. 0 *** QED
+  | n > 0 = toNat (fromNat n)
+        ==. toNat (S (fromNat (n - 1)))
+        ==. 1 + toNat (fromNat (n - 1))
+        ==. 1 + (n - 1) ? toFrom (n - 1)
+        ==. n
+        *** QED
+
+{-@ fromTo :: x:Peano -> { fromNat (toNat x) == x } @-}
+fromTo :: Peano -> Proof
+fromTo Z = fromNat (toNat Z) ==. fromNat 0 ==. Z *** QED
+fromTo (S n) = fromNat (toNat (S n))
+           ==. fromNat (1 + toNat n)
+           ==. S (fromNat ((1 + toNat n) - 1))
+           ==. S (fromNat (toNat n))
+           ==. S n ? fromTo n
+           *** QED
+
+{-@ isoNatPeano :: Iso Nat Peano @-}
+isoNatPeano :: Iso Nat Peano
+isoNatPeano = Iso fromNat toNat fromTo toFrom
+
+vordNat :: VerifiedOrd Nat
+vordNat = VerifiedOrd leqInt leqIntRefl leqIntAntisym leqIntTrans leqIntTotal
+
+vordPeano :: VerifiedOrd Peano
+vordPeano = vordIso isoNatPeano vordNat
+\end{code}
+
+Similarly, we can break down compound datatypes into sums and products, just like what happens in `GHC.Generics`, and
+use the isomorphism to write down `VerifiedOrd` instances. We do however need to provide instances of `VerifiedOrd` for
+sums and products.
+
+\begin{code}
+vordProd :: VerifiedOrd a -> VerifiedOrd b -> VerifiedOrd (a, b)
+vordSum :: VerifiedOrd a -> VerifiedOrd b -> VerifiedOrd (Either a b)
+\end{code}
+
+\begin{comment}
+\begin{code}
+vordSum = undefined
+vordProd = undefined
+\end{code}
+\end{comment}
+
+Our [library](https://github.com/iu-parfunc/verified-instances) explores this idea to build some verified typeclasses,
+such as `VerifiedOrd` and `VerifiedMonoid`. We also provide combinators to build verified instances by using
+isomorphisms. Also, using a [reflection hack](https://www.schoolofhaskell.com/user/thoughtpolice/using-reflection), we
+can reify these "verified" terms to typeclass dictionaries at runtime, to call legacy functions which require `Ord`
+constraints and so on.
diff --git a/docs/blog/2017-01-06-reductions.lhs b/docs/blog/2017-01-06-reductions.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2017-01-06-reductions.lhs
@@ -0,0 +1,261 @@
+---
+layout: post
+title: Proof Reductions on Homomorphisms
+date: 2017-01-02
+comments: true
+external-url:
+author: Niki Vazou and Vikraman Choudhury
+published: true
+categories: reflection, abstract-refinements
+demo: Reductions.hs
+---
+
+[Previously][refinement-reflection] we saw how Refinement Reflection
+can be used to specify and prove theorems about Haskell code.
+
+Today we will see how proof generation can be simplified by 
+proof reduction on homomorphic data types. 
+
+As an example, we define a user-defined `Peano` data type
+and prove that it enjoys various arithmetic properties 
+(like totality of comparison) by 
+
+1. creating a proof that an arithmetic property holds on Natural numbers, and then 
+2. reduce the proof from Natural numbers to Peano numbers. 
+This proof reduction is possible since Peano numbers are homomorphic to Natural numbers. 
+
+
+
+

+

+

+
+

+  

+  Picasso bull
+       

+       

+       

+  

+

+
+
+
+
+Properties of Peano Numbers
+----------------------------
+
+First, we define `Peano` numbers as a data type 
+and the function `leqPeano` that compares two Peano numbers.
+
+
+\begin{code}
+{-@ data Peano [toNat] = Z | S {prev :: Peano } @-}
+data Peano = Z | S { prev :: Peano } deriving (Eq)
+
+{-@ reflect leqPeano @-}
+leqPeano :: Peano -> Peano -> Bool
+leqPeano Z _         = True
+leqPeano _ Z         = False
+leqPeano (S n) (S m) = leqPeano n m
+\end{code}
+
+We can use Refinement Reflection to provide an 
+**explicit proof** that no Peano number is greater than zero (`Z`).
+
+\begin{code}
+{-@ geqZero :: n:Peano -> {leqPeano Z n} @-}
+geqZero n = leqPeano Z n *** QED 
+\end{code}
+
+The proof proceeds simply by invocation of the 
+first case of the `leqPeano` definition. 
+
+As another Peano property, we can use Refinement Reflection to 
+show that comparison on Peano numbers is *total*, 
+that is, for every two numbers `n` and `m` 
+either `leqPeano n m` or `leqPeano m n` always holds. 
+
+\begin{code}
+{-@ leqTotal :: n:Peano -> m:Peano 
+             -> {(leqPeano n m) || (leqPeano m n)} 
+             /  [toNat n + toNat m] @-}
+leqTotal Z m = leqPeano Z m *** QED
+leqTotal n Z = leqPeano Z n *** QED
+leqTotal (S n) (S m)
+  =   (leqPeano (S n) (S m) || leqPeano (S m) (S n))
+  ==. (leqPeano n m || leqPeano (S m) (S n)) 
+      ? (leqTotal n m)
+  ==. (leqPeano n m || leqPeano m n) 
+      ? (leqTotal m n)
+  *** QED
+\end{code}
+
+The proof proceeds by induction on the sum of `n` and `m`. 
+Liquid Haskell captures this generalized induction by 
+ensuring that the value `toNat n + toNat m` is decreasing
+where `toNat` maps Peano to Natural numbers. 
+
+\begin{code}
+{-@ measure toNat @-}
+{-@ toNat :: Peano -> Nat @-}
+toNat Z     = 0
+toNat (S n) = 1 + toNat n
+\end{code}
+
+Note, that the type `Nat` is just a refinement on the Haskell's integers
+\begin{code}
+{-@ type Nat = { n:Int | 0 <= n } @-}
+type Nat     = Int
+\end{code}
+
+Following the totality proof, 
+one can prove further properties of Peano comparisons, 
+like reflexivity and transitivity.
+
+The above totality proof is verbose! 
+Moreover, it is very similar 
+to the classic totality on Natural numbers. 
+Since the SMT knowns that comparison of Nat is total, we can just reduce 
+Peano to Natural number totality!
+
+
+Reduction of Operators 
+-----------------------
+
+Since `toNat` is a homomorphism (i.e., a transformation) from `Peano` to `Nat`
+one can compare two Peano numbers via comparison of Natural numbers. 
+
+\begin{code}
+{-@ reflect leqPeanoNat @-}
+leqPeanoNat :: Peano -> Peano -> Bool 
+leqPeanoNat n m = toNat n `leqInt` toNat m  
+\end{code}
+
+where `leqInt` the Haskell comparison operator restricted to `Ints`.
+
+\begin{code}
+{-@ reflect leqInt @-}
+leqInt :: Int -> Int -> Bool 
+leqInt x y = x <= y
+\end{code}
+
+Note that `leqPeanoNat` is exactly equivalent to `leqPeano`. 
+For this blog post, we leave the equivalence proof as an exercise for the reader.
+
+
+Proof Reductions
+-----------------
+
+After reducing the Peano comparison operator to
+comparison on Natural numbers, we can reduce 
+proofs on Peano numbers to proofs on Natural numbers.
+The great benefit of this reduction is that proofs on Natural number
+are automated by the underlying SMT solver!
+
+For example, we prove that no Natural number is less than `0`
+by unfolding `leqInt` on `0` 
+and then let linear arithmetic decision procedure of the SMT complete the proof. 
+\begin{code}
+{-@ geqZeroNat :: n:Nat -> {leqInt 0 n} @-}
+geqZeroNat n = leqInt 0 n *** QED 
+\end{code}
+
+
+We then reduce the above property to the respective property on Peano numbers.
+\begin{code}
+{-@ geqZeroByReduction :: n:Peano -> {leqPeanoNat Z n} @-}
+geqZeroByReduction n 
+  = leqPeanoNat Z n ==. True 
+  ? reduction toNat geqZeroNat n 
+  *** QED 
+\end{code}
+
+The reduction occurs via the function `reduction`.
+The function `reduction f thm n`, for each homomorphism `f :: a -> b`, 
+reduces a theorem `thm x` on `a`s to the respective theorems on `b` via 
+[Abstract Refinements][abstract-refinements].
+\begin{code}
+{-@ reduction :: forall
 Proof -> Bool>. 
+                 f:(b -> a) 
+              -> (x:a -> Proof
) 
+              -> (y:b -> Proof
) @-}
+reduction :: (b -> a) -> (a -> Proof) -> (b -> Proof)
+reduction f thm y = thm (f y)              
+\end{code}
+
+Users with model theoretic background may observe that `reduction` 
+is actually encoding [Łoś–Tarski preservation theorem][preservation-theorem]!
+
+Similarly, `reduction2` reduces theorems with two `a` arguments
+to theorems with two `b` arguments via a homomorphism. 
+
+\begin{code}
+{-@ reduction2 :: forall
 a -> Proof -> Bool >. 
+                  f:(b -> a) 
+               -> (x1:a -> x2:a -> Proof
) 
+               -> (y1:b -> y2:b-> Proof
) @-}
+reduction2 :: (b -> a) -> (a -> a -> Proof) -> (b -> b -> Proof)
+reduction2 f thm y1 y2  = thm (f y1) (f y2)
+\end{code}
+
+For example, the SMT-automated proof of totality on Natural numbers 
+\begin{code}
+{-@ leqTotalNat :: n:Nat -> m:Nat -> { leqInt n m || leqInt m n } @-}
+leqTotalNat n m = (leqInt n m || leqInt m n) *** QED 
+\end{code}
+
+can be easily reduced to totality on Peano numbers
+
+\begin{code}
+{-@ leqTotalByReduction :: n:Peano -> m:Peano
+   -> { leqPeanoNat n m || leqPeanoNat m n } @-}
+leqTotalByReduction n m 
+  = (leqPeanoNat n m || leqPeanoNat m n) ==. True 
+  ? reduction2 toNat leqTotalNat n m  
+  *** QED 
+\end{code}
+
+
+Conclusion
+-----------
+
+We presented an example of how the SMT-automated proofs on 
+Natural numbers can be reduced to the respective proofs on the 
+Peano numbers, because Peano are homomorphic to Natural numbers. 
+
+Proof reduction greatly simplifies proof composition
+as it allows for shorter and more elegant proofs 
+that take advantage of SMT-automated or other existing
+proofs on homomorphic data structures. 
+
+
+[refinement-reflection]: http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/blog/2016/09/18/refinement-reflection.lhs/
+[reduction-lib]: https://github.com/ucsd-progsys/liquidhaskell/tree/develop/include/Language/Haskell/Liquid/Reduction.hs
+[abstract-refinements]: http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/blog/2013/06/03/abstracting-over-refinements.lhs/
+[preservation-theorem]: https://en.wikipedia.org/wiki/%C5%81o%C5%9B%E2%80%93Tarski_preservation_theorem
diff --git a/docs/blog/2017-03-20-arithmetic-overflows.lhs b/docs/blog/2017-03-20-arithmetic-overflows.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/2017-03-20-arithmetic-overflows.lhs
@@ -0,0 +1,363 @@
+---
+layout: post
+title: Arithmetic Overflows
+date: 2017-03-20
+author: Ranjit Jhala
+published: true
+comments: true
+tags: basic
+demo: overflow.hs
+---
+
+
+Computers are great at crunching numbers.
+However, if programmers aren't careful, their
+machines can end up biting off more than
+they can chew: simple arithmetic operations
+over very large (or very tiny) inputs can
+*overflow* leading to bizarre crashes
+or vulnerabilities. For example,
+[Joshua Bloch's classic post][bloch]
+argues that nearly all binary searches
+are broken due to integer overflows.
+Lets see how we can teach LiquidHaskell
+to spot such overflows.
+
+
+
+

+
+1. The Problem
+--------------
+
+
+LiquidHaskell, like some programmers, likes to make believe
+that `Int` represents the set of integers. For example, you
+might define a function `plus` as:
+
+\begin{code}
+{-@ plus :: x:Int -> y:Int -> {v:Int | v == x + y} @-}
+plus :: Int -> Int -> Int
+plus x y = x Prelude.+ y
+\end{code}
+
+The output type of the function states that the returned value
+is equal to the \emph{logical} result of adding the two inputs.
+
+The above signature lets us "prove" facts like addition by one
+yields a bigger number:
+
+\begin{code}
+{-@ monoPlus :: Int -> {v:Bool | v <=> true } @-}
+monoPlus :: Int -> Bool
+monoPlus x = x < plus x 1
+\end{code}
+
+Unfortunately, the signature for plus and hence, the above
+"fact" are both lies.
+
+LH _checks_ `plus` as the same signature is _assumed_
+for the primitive `Int` addition operator `Prelude.+`.
+LH has to assume _some_ signature for this "foreign"
+machine operation, and by default, LH assumes that
+machine addition behaves like logical addition.
+
+However, this assumption, and its consequences are
+only true upto a point:
+
+```haskell
+λ>  monoPlus 0
+True
+λ>  monoPlus 100
+True
+λ>  monoPlus 10000
+True
+λ>  monoPlus 1000000
+True
+```
+
+Once we get to `maxBound` at the very edge of `Int`,
+a tiny bump is enough to send us tumbling backwards
+into a twilight zone.
+
+```haskell
+λ> monoPlus maxBound
+False
+
+λ> plus maxBound 1
+-9223372036854775808
+```
+
+2. Keeping Int In Their Place
+-----------------------------
+
+The news isn't all bad: the glass half full
+view is that for "reasonable" values
+like 10, 100, 10000 and 1000000, the
+machine's arithmetic _is_ the same as
+logical arithmetic. Lets see how to impart
+this wisdom to LH. We do this in two steps:
+define the *biggest* `Int` value, and then,
+use this value to type the arithmetic operations.
+
+**A. The Biggest Int**
+
+First, we need a way to talk about
+"the edge" -- i.e. the largest `Int`
+value at which overflows occur.
+
+We could use the concrete number
+
+```haskell
+λ> maxBound :: Int
+9223372036854775807
+```
+
+However, instead of hardwiring a particular number,
+a more general strategy is to define a symbolic
+constant `maxInt` to represent _any_ arbitrary
+overflow value and thus, make the type checking
+robust to different machine integer widths.
+
+\begin{code}
+-- defines an Int constant called `maxInt`
+{-@ measure maxInt :: Int @-}
+\end{code}
+
+To tell LH that `maxInt` is the "biggest" `Int`,
+we write a predicate that describes values bounded
+by `maxInt`:
+
+\begin{code}
+{-@ predicate Bounded N = 0 < N + maxInt && N < maxInt @-}
+\end{code}
+
+Thus, `Bounded n` means that the number `n` is in
+the range `[-maxInt, maxInt]`.
+
+**B.  Bounded Machine Arithmetic**
+
+Next, we can assign the machine arithmetic operations
+types that properly capture the possibility of arithmetic
+overflows. Here are _two_ possible specifications.
+
+**Strict: Thou Shalt Not Overflow** A _strict_ specification
+simply prohibits any overflow:
+
+\begin{code}
+{-@ plusStrict :: x:Int -> y:{Int|Bounded(x+y)} -> {v:Int|v = x+y} @-}
+plusStrict x y = x Prelude.+ y
+\end{code}
+
+The inputs `x` and `y` _must_ be such that the result is `Bounded`,
+and in that case, the output value is indeed their logical sum.
+
+**Lazy: Overflow at Thine Own Risk** Instead, a _lazy_
+specification could permit overflows but gives no
+guarantees about the output when they occur.
+
+\begin{code}
+{-@ plusLazy :: x:Int -> y:Int -> {v:Int|Bounded(x+y) => v = x+y} @-}
+plusLazy x y = x Prelude.+ y
+\end{code}
+
+The lazy specification says that while `plusLazy`
+can be called with any values you like, the
+result is the logical sum
+*only if there is no overflow*.
+
+
+To understand the difference between the two
+specifications, lets revisit the `monoPlus`
+property using the new machine-arithmetic
+sensitive signatures:
+
+\begin{code}
+{-@ monoPlusStrict :: Int -> {v:Bool | v <=> true } @-}
+monoPlusStrict x = x < plusStrict x 1
+
+{-@ monoPlusLazy :: Int -> {v:Bool | v <=> true } @-}
+monoPlusLazy x = x < plusLazy x 1
+\end{code}
+
+Both are rejected by LH, since, as we saw earlier,
+the functions _do not_ always evaluate to `True`.
+However, in the strict version the error is at the
+possibly overflowing call to `plusStrict`.
+In the lazy version, the call to `plusLazy` is
+accepted, but as the returned value is some
+arbitrary `Int` (not the logical `x+1`), the
+comparison may return `False` hence the output
+is not always `True`.
+
+**Exercise:** Can you fix the specification
+for `monoPlusStrict` and `monoPlusLazy` to
+get LH to verify the implementation?
+
+
+3. A Typeclass for Machine Arithmetic
+-------------------------------------
+
+Its a bit inconvenient to write `plusStrict` and `plusLazy`,
+and really, we'd just like to write `+` and `-` and so on.
+We can do so, by tucking the above specifications into
+a _bounded numeric_ typeclass whose signatures capture machine
+arithmetic. First, we define a `BoundedNum` variant of `Num`
+
+\begin{code}
+class BoundedNum a where
+  (+) :: a -> a -> a
+  (-) :: a -> a -> a
+  -- other operations ...
+\end{code}
+
+and now, we can define its `Int` instance just as wrappers
+around the `Prelude` operations:
+
+\begin{code}
+instance BoundedNum Int where
+  x + y = x Prelude.+ y
+  x - y = x Prelude.- y
+\end{code}
+
+Finally, we can tell LH that the above above instance obeys the
+(strict) specifications for machine arithmetic:
+
+\begin{code}
+{-@ instance BoundedNum Int where
+      + :: x:Int -> y:{Int | Bounded (x+y)} -> {v:Int | v == x+y };
+      - :: x:Int -> y:{Int | Bounded (x-y)} -> {v:Int | v == x-y }
+  @-}
+\end{code}
+
+With the above instance in scope, we can just use the plain `+`
+operator and have LH flag potential overflows:
+
+\begin{code}
+{-@ mono :: Int -> {v:Bool | v <=> true} @-}
+mono x = x < x + 1
+\end{code}
+
+
+4. An Application: Binary Search
+--------------------------------
+
+The above seems a bit paranoid. Do overflows _really_ matter?
+And if they do, is it really practical to check for them using
+the above?
+
+[Joshua Bloch's][bloch] famous article describes a
+tricky overflow bug in an implementation of binary-search
+that lay hidden in plain sight in classic textbooks and his
+own implementation in the JDK for nearly a decade.
+Gabriel Gonzalez wrote a lovely [introduction to LH][lh-gonzalez]
+using binary-search as an example, and a careful reader
+[pointed out][lh-overflow-reddit] that it had the same
+overflow bug!
+
+Lets see how we might spot and fix such bugs using `BoundedNum`.
+
+

+

+**A. Off by One** Lets begin by just using
+the default `Num Int` which ignores overflow.
+As Gabriel explains, LH flags a bunch of errors
+if we start the search with `loop x v 0 n` as
+the resulting search can access `v` at any
+index between `0` and `n` inclusive, which
+may lead to an out of bounds at `n`.
+We can fix the off-by-one by correcting the
+upper bound to `n-1`, at which point LH
+reports the code free of errors.
+

+
+

+
+

+

+
+

+
+
+

+

+
+

+
+

+**B. Lots of Overflows** To spot arithmetic overflows, we need
+only hide the default `Prelude` and instead import the `BoundedNum`
+instance described above. Upon doing so, LH flags a whole bunch of
+potential errors -- essentially *all* the arithmetic operations which
+seems rather dire!
+

+

+
+
+

+

+**C. Vector Sizes are Bounded** Of course, things
+aren't _so_ bad. LH is missing the information that
+the size of any `Vector` must be `Bounded`. Once we
+inform LH about this invariant with the
+[`using` directive][lh-invariants], it infers that
+as the `lo` and `hi` indices are upper-bounded by
+the `Vector`'s size, all the arithmetic on them is
+also `Bounded` and hence, free of overflows.
+

+
+

+
+

+

+
+

+
+

+

+
+

+
+

+**D. Staying In The Middle**
+Well, *almost* all. The one pesky pink highlight that
+remains is exactly the bug that Bloch made famous. Namely:
+the addition used to compute the new midpoint between `lo`
+and `hi` could overflow e.g. if the array was large and both
+those indices were near the end. To ensure the machine doesn't
+choke, we follow Bloch's suggestion and re-jigger the computation
+to instead compute the midpoint by splitting the difference
+between `hi` and `lo`! the code is now free of arithmetic
+overflows and truly memory safe.
+

+

+
+
+[lh-invariants]: https://github.com/ucsd-progsys/liquidhaskell/blob/develop/README.md#invariants
+[lh-gonzalez]: http://www.haskellforall.com/2015/12/compile-time-memory-safety-using-liquid.html
+[bloch]: https://research.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html
+[lh-overflow-reddit]: https://www.reddit.com/r/haskell/comments/3ysh9k/haskell_for_all_compiletime_memory_safety_using/cyg8g60/
diff --git a/docs/blog/todo/Iso.lhs b/docs/blog/todo/Iso.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/Iso.lhs
@@ -0,0 +1,281 @@
+---
+layout: post
+title: "Isomorphisms"
+date: 2016-24-12 
+author: Vikraman Choudhury 
+published: false
+comments: true
+external-url:
+categories: basic
+demo: Iso.hs
+---
+
+\begin{comment}
+\begin{code}
+{-@ LIQUID "--higherorder" @-}
+{-@ LIQUID "--totalhaskell" @-}
+{-@ LIQUID "--exactdc" @-}
+{-@ LIQUID "--diffcheck" @-}
+
+module Iso where
+
+import Language.Haskell.Liquid.ProofCombinators
+\end{code}
+\end{comment}
+
+In this blog post, we show how to use Liquid Haskell to build "verified" typeclasses. A verified typeclass allows one to
+express typeclass laws directly as Haskell code. We also show a technique to build verified instances and scale them up
+to compound datatypes using isomorphisms.
+
+First, we'll express verified typeclasses using Haskell records, but with LiquidHaskell refinements to express laws. As
+an example, let's define `VerifiedOrd`, which is the same as the `Ord` typeclass, but with total order laws added.
+
+\begin{code}
+{-@ data VerifiedOrd a = VerifiedOrd {
+      leq     :: a -> a -> Bool
+    , refl    :: x:a -> { Prop (leq x x) }
+    , antisym :: x:a -> y:a -> { Prop (leq x y) && Prop (leq y x) ==> x == y }
+    , trans   :: x:a -> y:a -> z:a -> { Prop (leq x y) && Prop (leq y z) ==> Prop (leq x z) }
+    , total   :: x:a -> y:a -> { Prop (leq x y) || Prop (leq y x) }
+    }
+@-}
+data VerifiedOrd a = VerifiedOrd {
+    leq     :: a -> a -> Bool
+  , refl    :: a -> Proof
+  , antisym :: a -> a -> Proof
+  , trans   :: a -> a -> a -> Proof
+  , total   :: a -> a -> Proof
+}
+\end{code}
+
+The `leq` function represents the `<=` operator in `Ord`, and `refl`, `antisym`, `trans`, `total`, express the
+reflexivity, antisymmetry, transitivity and totality properties respectively, that a total order requires. Notice how
+the refinements express the laws, and the actual code is simply a function that returns `Proof` or `()`.
+
+Now, let's see how to define some simple verified instances. We need to instantiate `leq` for our type, "reflect" it
+into the logic, and prove all the required properties. For primitive types like `Int` or `Double`, it's "trivial"
+because we trust the SMT solver which already knows about integers.
+
+\begin{code}
+{-@ axiomatize leqInt @-}
+leqInt :: Int -> Int -> Bool
+leqInt x y = x <= y
+
+{-@ leqIntRefl :: x:Int -> { leqInt x x } @-}
+leqIntRefl :: Int -> Proof
+leqIntRefl x = leqInt x x ==. x <= x *** QED
+
+{-@ leqIntAntisym :: x:Int -> y:Int -> { leqInt x y && leqInt y x ==> x == y } @-}
+leqIntAntisym :: Int -> Int -> Proof
+leqIntAntisym x y = (leqInt x y && leqInt y x) ==. (x <= y && y <= x) ==. x == y *** QED
+
+{-@ leqIntTrans :: x:Int -> y:Int -> z:Int -> { leqInt x y && leqInt y z ==> leqInt x z } @-}
+leqIntTrans :: Int -> Int -> Int -> Proof
+leqIntTrans x y z = (leqInt x y && leqInt y z) ==. (x <= y && y <= z) ==. x <= z ==. leqInt x z *** QED
+
+{-@ leqIntTotal :: x:Int -> y:Int -> { leqInt x y || leqInt y x } @-}
+leqIntTotal :: Int -> Int -> Proof
+leqIntTotal x y = (leqInt x y || leqInt y x) ==. (x <= y || y <= x) *** QED
+
+vordInt :: VerifiedOrd Int
+vordInt = VerifiedOrd leqInt leqIntRefl leqIntAntisym leqIntTrans leqIntTotal
+\end{code}
+
+How about a complex datatype? Let's consider an inductive datatype, the peano natural numbers. Not surprisingly, the
+proofs follow by induction. For conciseness, we only show totality and elide the rest.
+
+\begin{code}
+{-@ data Peano [toNat] = Z | S Peano @-}
+data Peano = Z | S Peano deriving (Eq)
+
+{-@ measure toNat @-}
+{-@ toNat :: Peano -> { n:Int | 0 <= n } @-}
+toNat :: Peano -> Int
+toNat Z = 0
+toNat (S n) = 1 + toNat n
+
+{-@ axiomatize leqPeano @-}
+leqPeano :: Peano -> Peano -> Bool
+leqPeano Z _ = True
+leqPeano _ Z = False
+leqPeano (S n) (S m) = leqPeano n m
+
+{-@ leqNTotal :: n:Peano -> m:Peano -> {(leqPeano n m) || (leqPeano m n)} / [toNat n + toNat m] @-}
+leqNTotal :: Peano -> Peano -> Proof
+leqNTotal Z m = leqPeano Z m *** QED
+leqNTotal n Z = leqPeano Z n *** QED
+leqNTotal (S n) (S m)
+  =   (leqPeano (S n) (S m) || leqPeano (S m) (S n))
+  ==. (leqPeano n m || leqPeano (S m) (S n)) ? (leqNTotal n m )
+  ==. (leqPeano n m || leqPeano m n) ? (leqNTotal m n)
+  *** QED
+\end{code}
+
+Writing down proofs for more complex datatypes is tedious, it requires case analysis for each constructor and using the
+induction hypothesis. However, we can decompose Haskell datatypes into sums and products, and we can build up compound
+proofs using isomorphisms! To that end, we design some machinery to express isomorphisms, and prove that laws are
+preserved under isomorphic images.
+
+\begin{code}
+{-@ data Iso a b = Iso {
+      to   :: a -> b
+    , from :: b -> a
+    , tof  :: y:b -> { to (from y) == y }
+    , fot  :: x:a -> { from (to x) == x }
+    }
+@-}
+data Iso a b = Iso {
+    to   :: a -> b
+  , from :: b -> a
+  , tof  :: b -> Proof
+  , fot  :: a -> Proof
+}
+\end{code}
+
+An isomorphism between types `a` and `b` is a pair of functions `to :: a -> b` and `from :: b -> a` that are mutually
+inverse to each other. We now claim that total order laws are preserved under `Iso`; this amounts to building up a
+`VerifiedOrd b`, given a `VerifiedOrd a` and an `Iso a b`.
+
+\begin{code}
+{-@ axiomatize leqFrom @-}
+leqFrom :: (a -> a -> Bool)
+        -> (b -> a)
+        -> (b -> b -> Bool)
+leqFrom leqa from x y = leqa (from x) (from y)
+
+{-@ leqFromRefl :: leqa:(a -> a -> Bool) -> leqaRefl:(x:a -> { Prop (leqa x x) })
+                -> from:(b -> a)
+                -> x:b -> { leqFrom leqa from x x }
+@-}
+leqFromRefl :: (a -> a -> Bool) -> (a -> Proof)
+            -> (b -> a)
+            -> b -> Proof
+leqFromRefl leqa leqaRefl from x =
+      leqFrom leqa from x x
+  ==. leqa (from x) (from x)
+  ==. True ? leqaRefl (from x)
+  *** QED
+
+{-@ leqFromAntisym :: leqa:(a -> a -> Bool)
+                   -> leqaAntisym:(x:a -> y:a -> { Prop (leqa x y) && Prop (leqa y x) ==> x == y })
+                   -> to:(a -> b) -> from:(b -> a) -> tof:(y:b -> { to (from y) == y })
+                   -> x:b -> y:b -> { leqFrom leqa from x y && leqFrom leqa from y x ==> x == y }
+@-}
+leqFromAntisym :: (Eq a, Eq b)
+               => (a -> a -> Bool) -> (a -> a -> Proof)
+               -> (a -> b) -> (b -> a) -> (b -> Proof)
+               -> b -> b -> Proof
+leqFromAntisym leqa leqaAntisym to from tof x y
+  =   (leqFrom leqa from x y && leqFrom leqa from y x)
+  ==. (leqa (from x) (from y) && leqa (from y) (from x))
+  ==. from x == from y ? leqaAntisym (from x) (from y)
+  ==. to (from x) == to (from y)
+  ==. x == to (from y) ? tof x
+  ==. x == y           ? tof y
+  *** QED
+
+{-@ leqFromTrans :: leqa:(a -> a -> Bool)
+                 -> leqaTrans:(x:a -> y:a -> z:a -> { Prop (leqa x y) && Prop (leqa y z) ==> Prop (leqa x z) })
+                 -> from:(b -> a)
+                 -> x:b -> y:b -> z:b
+                 -> { leqFrom leqa from x y && leqFrom leqa from y z ==> leqFrom leqa from x z }
+@-}
+leqFromTrans :: (a -> a -> Bool) -> (a -> a -> a -> Proof)
+             -> (b -> a)
+             -> b -> b -> b -> Proof
+leqFromTrans leqa leqaTrans from x y z =
+      (leqFrom leqa from x y && leqFrom leqa from y z)
+  ==. (leqa (from x) (from y) && leqa (from y) (from z))
+  ==. leqa (from x) (from z) ? leqaTrans (from x) (from y) (from z)
+  ==. leqFrom leqa from x z
+  *** QED
+
+{-@ leqFromTotal :: leqa:(a -> a -> Bool) -> leqaTotal:(x:a -> y:a -> { Prop (leqa x y) || Prop (leqa y x) })
+                 -> from:(b -> a) -> x:b -> y:b -> { leqFrom leqa from x y || leqFrom leqa from y x }
+@-}
+leqFromTotal :: (a -> a -> Bool) -> (a -> a -> Proof)
+             -> (b -> a) -> b -> b -> Proof
+leqFromTotal leqa leqaTotal from x y =
+      (leqFrom leqa from x y || leqFrom leqa from y x)
+  ==. (leqa (from x) (from y) || leqa (from y) (from x))
+  ==. True ? leqaTotal (from x) (from y)
+  ==. leqFrom leqa from y x
+  *** QED
+
+vordIso :: (Eq a, Eq b) => Iso a b -> VerifiedOrd a -> VerifiedOrd b
+vordIso (Iso to from tof fot) (VerifiedOrd leqa leqaRefl leqaAntisym leqaTrans leqaTotal) =
+  VerifiedOrd
+    (leqFrom leqa from)
+    (leqFromRefl leqa leqaRefl from)
+    (leqFromAntisym leqa leqaAntisym to from tof)
+    (leqFromTrans leqa leqaTrans from)
+    (leqFromTotal leqa leqaTotal from)
+\end{code}
+
+We can now write a `VerifiedOrd` for `Peano` by mapping it onto `type Nat = { n:Int | 0 <= n }`, which is easier to
+prove properties about because it's just an integer!
+
+\begin{code}
+{-@ type Nat = { n:Int | 0 <= n } @-}
+type Nat = Int
+
+{-@ axiomatize fromNat @-}
+{-@ fromNat :: Nat -> Peano @-}
+fromNat :: Nat -> Peano
+fromNat n
+  | n == 0 = Z
+  | otherwise = S (fromNat (n - 1))
+
+{-@ toFrom :: x:Nat -> { toNat (fromNat x) == x } @-}
+toFrom :: Nat -> Proof
+toFrom n
+  | n == 0 = toNat (fromNat 0) ==. toNat Z ==. 0 *** QED
+  | n > 0 = toNat (fromNat n)
+        ==. toNat (S (fromNat (n - 1)))
+        ==. 1 + toNat (fromNat (n - 1))
+        ==. 1 + (n - 1) ? toFrom (n - 1)
+        ==. n
+        *** QED
+
+{-@ fromTo :: x:Peano -> { fromNat (toNat x) == x } @-}
+fromTo :: Peano -> Proof
+fromTo Z = fromNat (toNat Z) ==. fromNat 0 ==. Z *** QED
+fromTo (S n) = fromNat (toNat (S n))
+           ==. fromNat (1 + toNat n)
+           ==. S (fromNat ((1 + toNat n) - 1))
+           ==. S (fromNat (toNat n))
+           ==. S n ? fromTo n
+           *** QED
+
+{-@ isoNatPeano :: Iso Nat Peano @-}
+isoNatPeano :: Iso Nat Peano
+isoNatPeano = Iso fromNat toNat fromTo toFrom
+
+vordNat :: VerifiedOrd Nat
+vordNat = VerifiedOrd leqInt leqIntRefl leqIntAntisym leqIntTrans leqIntTotal
+
+vordPeano :: VerifiedOrd Peano
+vordPeano = vordIso isoNatPeano vordNat
+\end{code}
+
+Similarly, we can break down compound datatypes into sums and products, just like what happens in `GHC.Generics`, and
+use the isomorphism to write down `VerifiedOrd` instances. We do however need to provide instances of `VerifiedOrd` for
+sums and products.
+
+\begin{code}
+vordProd :: VerifiedOrd a -> VerifiedOrd b -> VerifiedOrd (a, b)
+vordSum :: VerifiedOrd a -> VerifiedOrd b -> VerifiedOrd (Either a b)
+\end{code}
+
+\begin{comment}
+\begin{code}
+vordSum = undefined
+vordProd = undefined
+\end{code}
+\end{comment}
+
+Our [library](https://github.com/iu-parfunc/verified-instances) explores this idea to build some verified typeclasses,
+such as `VerifiedOrd` and `VerifiedMonoid`. We also provide combinators to build verified instances by using
+isomorphisms. Also, using a [reflection hack](https://www.schoolofhaskell.com/user/thoughtpolice/using-reflection), we
+can reify these "verified" terms to typeclass dictionaries at runtime, to call legacy functions which require `Ord`
+constraints and so on.
diff --git a/docs/blog/todo/LambdaEval.hs b/docs/blog/todo/LambdaEval.hs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/LambdaEval.hs
@@ -0,0 +1,125 @@
+module LambdaEval where
+
+import Data.List        (lookup)
+
+import Language.Haskell.Liquid.Prelude   
+
+---------------------------------------------------------------------
+----------------------- Datatype Definition -------------------------
+---------------------------------------------------------------------
+
+type Bndr 
+  = Int
+
+data Expr 
+  = Lam Bndr Expr
+  | Var Bndr  
+  | App Expr Expr
+  | Const Int
+  | Plus Expr Expr
+  | Pair Expr Expr
+  | Fst Expr
+  | Snd Expr
+
+{-@
+measure isValue      :: Expr -> Prop
+isValue (Const i)    = true 
+isValue (Lam x e)    = true 
+isValue (Var x)      = false
+isValue (App e1 e2)  = false
+isValue (Plus e1 e2) = false 
+isValue (Fst e)      = false
+isValue (Snd e)      = false
+isValue (Pair e1 e2) = ((? (isValue(e1))) && (? (isValue(e2))))
+@-}
+
+{-@ type Value = {v: Expr | (? (isValue([v]))) } @-}
+
+---------------------------------------------------------------------
+-------------------------- The Evaluator ----------------------------
+---------------------------------------------------------------------
+
+evalVar :: Bndr -> [(Bndr, Expr)] -> Expr
+evalVar x ((y,v):sto) 
+  | x == y
+  = v
+  | otherwise
+  = evalVar x sto
+
+evalVar x []      
+  = error "unbound variable"
+
+
+{-@ eval :: [(Bndr, Value)] -> Expr -> ([(Bndr, Value)], Value) @-}
+eval sto (Const i) 
+  = (sto, Const i)
+
+eval sto (Var x)  
+  = (sto, evalVar x sto) 
+
+eval sto (Plus e1 e2)
+  = let (_, e1') = eval sto e1
+        (_, e2') = eval sto e2
+    in case (e1, e2) of
+         (Const i1, Const i2) -> (sto, Const (i1 + i2))
+         _                    -> error "non-integer addition"
+
+eval sto (App e1 e2)
+  = let (_,    v2 ) = eval sto e2 
+        (sto1, e1') = eval sto e1
+    in case e1' of
+         (Lam x e) -> eval ((x, v2): sto1) e
+         _         -> error "non-function application"
+
+eval sto (Lam x e) 
+  = (sto, Lam x e)
+
+eval sto (Pair e1 e2)
+  = (sto, Pair v1 v2)
+  where (_, v1) = eval sto e1
+        (_, v2) = eval sto e2
+
+eval sto (Fst e)
+  = let (sto', e') = eval sto e in
+    case e' of
+      Pair v _ -> (sto', v)
+      _        -> error "non-tuple fst"
+
+eval sto (Snd e)
+  = let (sto', e') = eval sto e in
+    case e' of
+      Pair _ v -> (sto', v)
+      _        -> error "non-tuple snd"
+
+---------------------------------------------------------------------
+-------------------------- Value Checker ----------------------------
+---------------------------------------------------------------------
+
+{-@ assert check :: {v: Expr | (? (isValue([v]))) } -> Bool @-}
+check (Const _)    = True
+check (Lam _ _)    = True
+check (Var _)      = liquidAssertB False
+check (App _ _)    = liquidAssertB False
+check (Pair v1 v2) = check v1 && check v2
+check (Fst _)      = liquidAssertB False
+check (Snd _)      = liquidAssertB False
+check (Plus _ _)   = liquidAssertB False
+
+---------------------------------------------------------------------
+-------------------------- Unit Tests -------------------------------
+---------------------------------------------------------------------
+
+tests =
+  let (f,g,x) = (0,1,2) 
+      e1      = Lam x (Var x)
+      e2      = App e1 e1 
+      e3      = Lam f (Lam g (Lam x (App (Var f)  (App (Var g) (Var x)))))
+      e4      = Const 10
+      e5      = App e1 e4
+      e6      = Lam x (Plus (Var x) e4)
+      e7      = App (App e3 e6) e6
+      e8      = Pair (App e7 (Const 0)) (App e7 (Const 100))
+      e9      = Fst e8
+      e10     = Snd e9
+      vs      = map (snd . eval []) [e1, e2, e3, e4, e5, e6, e7, e8, e9, e10]
+  in map check vs
diff --git a/docs/blog/todo/Termination.hs b/docs/blog/todo/Termination.hs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/Termination.hs
@@ -0,0 +1,29 @@
+{-# LANGUAGE BangPatterns #-}
+{-# LANGUAGE ScopedTypeVariables #-}
+
+module Term where
+
+import Data.Vector.Algorithms.Common (shiftRI)
+import Language.Haskell.Liquid.Prelude (choose)
+
+
+{-@ loop :: twit:Nat -> l:Nat -> u:{v:Nat | v = l + twit} -> Int @-}
+loop :: Int -> Int -> Int -> Int
+loop twit l u 
+   | u <= l    = l
+   | otherwise = case compare (choose 0) 0 of
+                   LT -> loop (u - (k + 1)) (k+1) u 
+                   EQ -> k
+                   GT -> loop (k - l) l     k 
+  where k = (u + l) `shiftRI` 1
+
+{-@ loop1 :: l:Nat -> u:{v:Nat | l <= v} -> Int / [u + l] @-}
+loop1 :: Int -> Int -> Int
+loop1 l u 
+   | u <= l    = l
+   | otherwise = case compare (choose 0) 0 of
+                   LT -> loop1 (k+1) u 
+                   EQ -> k
+                   GT -> loop1 l     k 
+  where k = (u + l) `shiftRI` 1
+
diff --git a/docs/blog/todo/TextBug.lhs b/docs/blog/todo/TextBug.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/TextBug.lhs
@@ -0,0 +1,345 @@
+---
+layout: post
+title: "Text Bug"
+date: 2014-03-01
+comments: true
+external-url:
+author: Eric Seidel
+published: false
+categories: benchmarks, text
+demo: TextBug.hs
+---
+
+For our last post on `text`, we return to the topic of building a new `Text`
+value, i.e. proving the safety of write operations.
+
+
+
+
+
+Let's take a look at `mapAccumL`, which combines a map and a fold
+over a `Stream` and bundles the result of the map into a new `Text`.
+Again, we'll want to focus our attention on the `Yield` case of the
+inner loop.
+
+\begin{code}
+mapAccumL f z0 (Stream next0 s0 len) =
+  (nz, Text na 0 nl)
+ where
+  mlen = upperBound 4 len
+  (na,(nz,nl)) = runST $ do
+       (marr,x) <- (new mlen >>= \arr ->
+                    outer arr mlen z0 s0 0)
+       arr      <- unsafeFreeze marr
+       return (arr,x)
+  outer arr top = loop
+   where
+    loop !z !s !i =
+      case next0 s of
+        Done          -> return (arr, (z,i))
+        Skip s'       -> loop z s' i
+        Yield x s'
+          | j >= top  -> do
+            let top' = (top + 1) `shiftL` 1
+            arr' <- new top'
+            copyM arr' 0 arr 0 top
+            outer arr' top' z s i
+          | otherwise -> do
+            let (z',c) = f z x
+            d <- writeChar arr i c
+            loop z' s' (i+d)
+          where j | ord x < 0x10000 = i
+                  | otherwise       = i + 1
+\end{code}
+
+If you recall `unstream` from last time, you'll notice that this loop body
+looks almost identical to the one found in `unstream`, but LiquidHaskell has
+flagged the `writeChar` call as unsafe! What's going on here?
+
+Let's take a look at `j`, recalling that it carried a crucial part of the safety
+\begin{code} proof last time, and see what LiquidHaskell was able to infer.
+{v:Int | ((ord x >= 65536) => (v == i+1))
+      && ((ord x <  65536) => (v == i))}
+\end{code}
+
+Well that's not very useful at all! LiquidHaskell can prove that it's safe to
+write `x` but here we are trying to write `c` into the array. This is actually
+a *good* thing though, because `c` is the result of calling an arbitrary
+function `f` on `x`! We haven't constrained `f` in any way, so it could easily
+return a character above `U+10000` given any input.
+
+So `mapAccumL` is actually *unsafe*, and our first wild bug caught by
+LiquidHaskell! The fix is luckily easy, we simply have to lift the
+`let (z',c) = f z x` binder into the `where` clause, and change `j` to
+depend on `ord c` instead.
+
+\begin{code}
+mapAccumL' f z0 (Stream next0 s0 len) =
+  (nz, Text na 0 nl)
+ where
+  mlen = upperBound 4 len
+  (na,(nz,nl)) = runST $ do
+       (marr,x) <- (new mlen >>= \arr ->
+                    outer arr mlen z0 s0 0)
+       arr      <- unsafeFreeze marr
+       return (arr,x)
+  outer arr top = loop
+   where
+    loop !z !s !i =
+      case next0 s of
+        Done          -> return (arr, (z,i))
+        Skip s'       -> loop z s' i
+        Yield x s'
+          | j >= top  -> do
+            let top' = (top + 1) `shiftL` 1
+            arr' <- new top'
+            copyM arr' 0 arr 0 top
+            outer arr' top' z s i
+          | otherwise -> do
+            d <- writeChar arr i c
+            loop z' s' (i+d)
+          where (z',c) = f z x
+                j | ord c < 0x10000 = i
+                  | otherwise       = i + 1
+\end{code}
+
+LiquidHaskell happily accepts our revised `mapAccumL`, as did the `text`
+maintainers.
+
+We hope you've enjoyed this whirlwind tour of using LiquidHaskell to verify
+production code, we have many more examples in the `benchmarks` folder of
+our GitHub repository for the intrepid reader.
diff --git a/docs/blog/todo/TextInternal.lhs b/docs/blog/todo/TextInternal.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/TextInternal.lhs
@@ -0,0 +1,384 @@
+---
+layout: post
+title: "Text Internals"
+date: 2014-02-09
+comments: true
+external-url:
+author: Eric Seidel
+published: false
+categories: benchmarks, text
+demo: TextInternal.hs
+---
+
+So far we have mostly discussed LiquidHaskell in the context of
+recursive data structures like lists, but there comes a time in 
+many programs when you have to put down the list and pick up an 
+array for the sake of performance. 
+In this series we're going to examine the `text` library, which 
+does exactly this in addition to having extensive Unicode support.
+
+`text` is a popular library for efficient text processing. 
+It provides the high-level API haskellers have come to expect while 
+using stream fusion and byte arrays under the hood to guarantee high
+performance. 
+
+The thing that makes `text` stand out as an interesting target for 
+LiquidHaskell, however, is its use of Unicode. 
+Specifically, `text` uses UTF-16 as its internal encoding, where 
+each character is represented with either two or four bytes. 
+We'll see later on how this encoding presents a challenge for 
+verifying memory-safety, but first let us look at how a `Text` 
+is represented.
+
+
+
+
+
+`text` splits the reading and writing array operations between two
+types of arrays, immutable `Array`s and mutable `MArray`s. This leads to
+the following general lifecycle:
+
+![The lifecycle of a `Text`](/images/text-lifecycle.png)
+
+
+\begin{code}
+data Array = Array {
+    aBA  :: ByteArray#
+  , aLen :: !Int
+  }
+
+{-@ measure alen     :: Array -> Int
+    alen (Array a n) = n
+  @-}
+
+data MArray s = MArray {
+    maBA  :: MutableByteArray# s
+  , maLen :: !Int
+  }
+
+{-@ measure malen :: MArray s -> Int
+    malen (MArray a n) = n
+  @-}
+
+\end{code}
+
+Both types carry around with them the number of `Word16`s they can
+hold (this is actually only true when you compile with asserts turned
+on, but we use this to ease the verification process).
+
+The main three array operations we care about are: 
+
+1. **writing** into an `MArray`, 
+2. **reading** from an `Array`, and 
+3. **freezing** an `MArray` into an `Array`. 
+
+But first, let's see how one creates an `MArray`.
+
+\begin{code}
+{-@ type MArrayN s N = {v:MArray s | (malen v) = N} @-}
+
+{-@ new :: forall s. n:Nat -> ST s (MArrayN s n) @-}
+new n
+  | n < 0 || n .&. highBit /= 0 = error $ "new: size overflow"
+  | otherwise = ST $ \s1# ->
+       case newByteArray# len# s1# of
+         (# s2#, marr# #) -> (# s2#, MArray marr# n #)
+  where !(I# len#) = bytesInArray n
+        highBit    = maxBound `xor` (maxBound `shiftR` 1)
+        bytesInArray n = n `shiftL` 1
+\end{code}
+
+`new n` is an `ST` action that produces an `MArray s` with `n` slots,
+denoted by the type alias `MArrayN s n`. Note that we are not talking
+about bytes here, `text` deals with `Word16`s internally and as such
+we actualy allocate `2*n` bytes.  While this may seem like a lot of
+code to just create an array, the verification process here is quite
+simple. LiquidHaskell simply recognizes that the `n` used to construct
+the returned array (`MArray marr# n`) is the same `n` passed to
+`new`. It should be noted that we're abstracting away some detail here
+with respect to the underlying `MutableByteArray#`, specifically we're
+making the assumption that any *unsafe* operation will be caught and
+dealt with before the `MutableByteArray#` is touched.
+
+Once we have an `MArray` in hand, we'll want to be able to write our
+data into it. A `Nat` is a valid index into an `MArray` `ma` if it is
+less than the number of slots, for which we have another type alias
+`MAValidI ma`. `text` includes run-time assertions that check this
+property, but LiquidHaskell can statically prove the assertions will
+always pass.
+
+\begin{code}
+{-@ type MAValidI MA = {v:Nat | v < (malen MA)} @-}
+{-@ unsafeWrite :: ma:MArray s -> MAValidI ma -> Word16 -> ST s () @-}
+unsafeWrite MArray{..} i@(I# i#) (W16# e#)
+  | i < 0 || i >= maLen = liquidError "out of bounds"
+  | otherwise = ST $ \s1# ->
+      case writeWord16Array# maBA i# e# s1# of
+        s2# -> (# s2#, () #)
+\end{code}
+
+So now we can write individual `Word16`s into an array, but maybe we
+have a whole bunch of text we want to dump into the array. Remember,
+`text` is supposed to be fast!
+C has `memcpy` for cases like this but it's notoriously unsafe; with
+the right type however, we can regain safety. `text` provides a wrapper around
+`memcpy` to copy `n` elements from one `MArray` to another.
+
+\begin{code}
+{-@ type MAValidO MA = {v:Nat | v <= (malen MA)} @-}
+{-@ copyM :: dest:MArray s
+          -> didx:MAValidO dest
+          -> src:MArray s 
+          -> sidx:MAValidO src
+          -> {v:Nat | (((didx + v) <= (malen dest))
+                    && ((sidx + v) <= (malen src)))}
+          -> ST s ()
+  @-}
+copyM dest didx src sidx count
+    | count <= 0 = return ()
+    | otherwise =
+    liquidAssert (sidx + count <= maLen src) .
+    liquidAssert (didx + count <= maLen dest) .
+    unsafeIOToST $ memcpyM (maBA dest) (fromIntegral didx)
+                           (maBA src) (fromIntegral sidx)
+                           (fromIntegral count)
+\end{code}
+
+`copyM` requires two `MArray`s and valid offsets into each -- note 
+that a valid offset is **not** necessarily a valid *index*, it may 
+be one element out-of-bounds -- and a `count` of elements to copy.
+The `count` must represent a valid region in each `MArray`, in 
+other words `offset + count <= length` must hold for each array. 
+`memcpyM` is an FFI function writen in C, which we don't currently
+support, so we simply leave it `undefined`.
+
+Before we can package up our `MArray` into a `Text`, we need to
+*freeze* it, preventing any further mutation. The key property here is
+of course that the frozen `Array` should have the same length as the
+`MArray`.
+
+\begin{code}
+{-@ type ArrayN N = {v:Array | (alen v) = N} @-}
+{-@ unsafeFreeze :: ma:MArray s -> ST s (ArrayN (malen ma)) @-}
+unsafeFreeze MArray{..} = ST $ \s# ->
+                          (# s#, Array (unsafeCoerce# maBA) maLen #)
+\end{code}
+
+Again, LiquidHaskell is happy to prove our specification as we simply
+copy the length parameter `maLen` over into the `Array`.
+
+Finally, we will eventually want to read a value out of the
+`Array`. As with `unsafeWrite` we require a valid index into the
+`Array`, which we denote using the `AValidI` alias.
+
+\begin{code}
+{-@ type AValidI A = {v:Nat | v < (alen A)} @-}
+{-@ unsafeIndex :: a:Array -> AValidI a -> Word16 @-}
+unsafeIndex Array{..} i@(I# i#)
+  | i < 0 || i >= aLen = liquidError "out of bounds"
+  | otherwise = case indexWord16Array# aBA i# of
+                  r# -> (W16# r#)
+\end{code}
+
+As before, LiquidHaskell can easily prove that the run-time assertions
+will never fail.
+
+
+Now we can finally define the core datatype of the `text` package! 
+A `Text` value consists of an *array*, an *offset*, and a *length*. 
+The offset and length are `Nat`s satisfying two properties: 
+
+1. `off <= alen arr`, and 
+2. `off + len <= alen arr`
+
+These invariants ensure that any *index* we pick between `off` and
+`off + len` will be a valid index into `arr`. If you're not quite
+convinced, consider the following `Text`s.
+
+![Multiple valid `Text` configurations, all using an `Array` with 10 slots. The valid slots are shaded. Note that the key invariant is that `off + len <= alen`.](/images/text-layout.png)
+
+\begin{code}
+data Text = Text Array Int Int
+{-@ data Text [tlen] = Text (arr :: Array)
+                            (off :: TValidO arr)
+                            (len :: TValidL off arr)
+  @-}
+
+{-@ measure tarr :: Text -> Array
+    tarr (Text a o l) = a
+  @-}
+
+{-@ measure toff :: Text -> Int
+    toff (Text a o l) = o
+  @-}
+
+{-@ measure tlen :: Text -> Int
+    tlen (Text a o l) = l
+  @-}
+\end{code}
+
+The liquid-type for `Text` makes use of the following two type-aliases to
+express the core invariant.
+
+\begin{code}
+{-@ type TValidO A   = {v:Nat | v     <= (alen A)} @-}
+{-@ type TValidL O A = {v:Nat | (v+O) <= (alen A)} @-}
+\end{code}
+
+Before we go, let's take a quick look at a function that combines
+`MArray`s, `Array`s, and `Text`s. `unstream` is a major workhorse of
+the `text` library. It transforms a `Stream` of `Char`s into a `Text`,
+and enables GHC use a technique called *stream fusion* to combine
+multiple loops over a sequence into a single loop.
+
+\begin{code}
+unstream :: Stream Char -> Text
+unstream (Stream next0 s0 len) = runST $ do
+  let mlen = upperBound 4 len
+  arr0 <- new mlen
+  let outer arr top = loop
+       where
+        loop !s !i =
+            case next0 s of
+              Done          -> do
+                arr' <- unsafeFreeze arr
+                return $! Text arr' 0 i
+              Skip s'       -> loop s' i
+              Yield x s'
+                | j >= top  -> do
+                  let top' = (top + 1) `shiftL` 1
+                  arr' <- new top'
+                  copyM arr' 0 arr 0 top
+                  outer arr' top' s i
+                | otherwise -> do
+                  d <- writeChar arr i x
+                  loop s' (i+d)
+                where j | ord x < 0x10000 = i
+                        | otherwise       = i + 1
+  outer arr0 mlen s0 0
+\end{code}
+
+`unstream` repeatedly writes the characters coming out of the `Stream`
+into the `arr`, until it runs out of room. Then it has to allocate a
+new, larger `MArray` and copy everything into the new array before
+continuing. Note that LiquidHaskell has successfully inferred that
+`arr'` is longer than `arr` and that `top` is a valid offset into
+both, thus proving that the call to `copyM` is safe! Unfortunately for
+us, however, the `writeChar` call is flagged as *unsafe*.. Astute
+readers will notice that `writeChar` (whose implementation we haven't
+yet seen) has a slightly odd type, it requires that the index `i` be
+less than `malen arr - 1`. This is indeed odd and, I should add, not
+the final type, but it is a safe approximation because not all `Char`s
+are created equal. Depending on your encoding, some won't fit into a
+single `Word16`, so we may need extra room to write!
+
+Stay tuned, next time we'll dig into how `text` uses Unicode to
+represent `Char`s internally.
diff --git a/docs/blog/todo/TextRead.lhs b/docs/blog/todo/TextRead.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/TextRead.lhs
@@ -0,0 +1,357 @@
+---
+layout: post
+title: "Text Read"
+date: 2014-02-16
+comments: true
+external-url:
+author: Eric Seidel
+published: false
+categories: benchmarks, text
+demo: TextRead.hs
+---
+
+Welcome back! Last time we left off on a bit of a cliffhanger with the
+`unstream` example. Remember, the issue we found was that some `Char`s
+can't fit into a single `Word16`, so the safety of a write depends not
+only on the *index*, but also on the *value* being written! Before we
+can resolve this issue with `unstream` we'll have to learn about
+UTF-16, so let's take a short detour and look at how one *consumes* a
+`Text`.
+
+
+
+
+
+Let's begin with a simple example, `unsafeHead`.
+
+\begin{code}
+{-@ type TextNE = {v:Text | (tlen v) > 0} @-}
+
+{-@ unsafeHead :: TextNE -> Char @-}
+unsafeHead :: Text -> Char
+unsafeHead (Text arr off _len)
+    | m < 0xD800 || m > 0xDBFF = unsafeChr m
+    | otherwise                = chr2 m n
+    where m = unsafeIndex arr off
+          n = unsafeIndex arr (off+1)
+\end{code}
+
+LiquidHaskell can prove the first `unsafeIndex` is safe because the
+precondition states that the `Text` must not be empty, i.e. `_len > 0`
+must hold. Combine this with the core `Text` invariant that
+`off + _len <= alen arr` and we get that `off < alen arr`, which satisfies
+the precondition for `unsafeIndex`.
+
+However, the same calculation *fails* for the second index because we
+can't prove that `off + 1 < alen arr`. The solution is going to
+require some understanding of UTF-16, so let's take a brief detour.
+
+The UTF-16 standard represents all code points below `U+10000` with a
+single 16-bit word; all others are split into two 16-bit words, known
+as a *surrogate pair*. The first word, or *lead*, is guaranteed to be
+in the range `[0xD800, 0xDBFF]` and the second, or *trail*, is
+guaranteed to be in the range `[0xDC00, 0xDFFF]`.
+
+Armed with this knowledge of UTF-16 we can return to
+`unsafeHead`. Note the case-split on `m`, which determines whether `m`
+is a lead surrogate. If `m` is a lead surrogate then we know there
+must be a trail surrogate at `off+1`; we can define a specialized
+version of `unsafeIndex` that encodes this domain knowledge.
+
+\begin{code}
+{-@ unsafeIndexF :: a:Array -> o:AValidO a -> l:AValidL o a
+                 -> i:{v:Nat | (o <= v && v < (o + l))}
+                 -> {v:Word16 | (if (55296 <= v && v <= 56319)
+                                 then (SpanChar 2 a o l i)
+                                 else (SpanChar 1 a o l i))}
+  @-}
+unsafeIndexF :: Array -> Int -> Int -> Int -> Word16
+unsafeIndexF a o l i = let x = unsafeIndex a i
+                       in liquidAssume (axiom_lead_surr x a o l i) x
+\end{code}
+
+Our variant `unsafeIndexF` (F as in "forward") takes an array, an
+offset, and a length (which together must form a valid `Text`); a
+valid index into the `Text`; and returns a `Word16` with an
+interesting type. The best way to read this type would be "if `v` is
+in the range `[0xD800, 0xDBFF]`, then the character that starts at
+index `i` in the array `a` spans two slots, otherwise it only spans
+one slot." Intuitively, we know what it means for a character to span
+`n` slots, but LiquidHaskell needs to know three things:
+
+1. `a[o:i+n]` contains one more character than `a[o:i]` (borrowing
+   Python's wonderful slicing syntax)
+2. `a[o:i+n]` contains no more characters than `a[o:l]`
+3. `i-o+n <= l`
+
+2 and 3 encode the well-formedness of a `Text` value, i.e. `i+1`
+*must* be a valid index if a lead surrogate is at index `i`.
+
+We can encode these properties in the refinement logic as follows.
+
+\begin{code}
+{-@ measure numchars :: Array -> Int -> Int -> Int @-}
+{-@ predicate SpanChar N A O L I =
+      (((numchars (A) (O) ((I-O)+N)) = (1 + (numchars (A) (O) (I-O))))
+    && ((numchars (A) (O) ((I-O)+N)) <= (numchars A O L))
+    && (((I-O)+N) <= L))
+  @-}
+\end{code}
+
+The `numchars` measure takes an array, an offset, and a length
+(e.g. the `arr`, `off`, and `len` fields of a `Text`) and denotes the
+number of characters contained in the `length` slots beginning at
+`offset`. Since we can't compute this in the refinement logic, we
+leave the measure abstract. We can, however, provide LiquidHaskell
+with a few invariants about the behavior of `numchars`, specifically
+that (1) `numchars` always returns a `Nat`, (2) there are no
+characters contained in a empty span, and (3) there are at most as
+many characters as words in a `Text`. We encode these using a special
+`invariant` annotation.
+
+\begin{code}
+{-@ invariant {v:Text | (numchars (tarr v) (toff v) (tlen v)) >= 0}        @-}
+{-@ invariant {v:Text | (numchars (tarr v) (toff v) 0)         = 0}        @-}
+{-@ invariant {v:Text | (numchars (tarr v) (toff v) (tlen v)) <= (tlen v)} @-}
+\end{code}
+
+Finally returning to `unsafeHead`, we can use `unsafeIndexF` to
+strengthen the inferred type for `m`. LiquidHaskell can now prove that
+the second `unsafeIndex` is in fact safe, because it is only demanded
+if `m` is a lead surrogate.
+
+\begin{code}
+{-@ unsafeHead' :: TextNE -> Char @-}
+unsafeHead' :: Text -> Char
+unsafeHead' (Text arr off _len)
+    | m < 0xD800 || m > 0xDBFF = unsafeChr m
+    | otherwise                = chr2 m n
+    where m = unsafeIndexF arr off _len off
+          {-@ LAZYVAR n @-}
+          n = unsafeIndex arr (off+1)
+\end{code}
+
+The `LAZYVAR` annotation is currently required because LiquidHaskell
+doesn't know that `n` will only be demanded in one branch; one can
+imagine a transformation that would push the `where` bindings inward
+to the use-site, which would alleviate this issue.
+
+Before signing off, let's take a look at a slightly more interesting
+function, `take`.
+
+\begin{code}
+{-@ take :: n:Nat -> t:Text -> {v:Text | (Min (tlength v) (tlength t) n)} @-}
+take :: Int -> Text -> Text
+take n t@(Text arr off len)
+    | n <= 0    = empty
+    | n >= len  = t
+    | otherwise = Text arr off (loop 0 0)
+  where
+     loop !i !cnt
+          | i >= len || cnt >= n = i
+          | otherwise            = let d = iter_ t i
+                                   in loop (i+d) (cnt+1)
+\end{code}
+
+`take` gets a `Nat` and a `Text`, and returns a `Text` that contains
+the first `n` characters of `t`. That is, unless `n >= tlength t`, in
+which case it just returns `t`.
+
+`tlength` is a simple wrapper around `numchars`.
+
+\begin{code}
+{-@ measure tlength :: Text -> Int
+    tlength (Text a o l) = (numchars a o l)
+  @-}
+\end{code}
+
+The bulk of the work is done by the
+inner `loop`, which has to track the current index `i` and the number
+of characters we have seen, `cnt`. `loop` uses an auxiliary function
+`iter_` to determine the *width* of the character that starts at `i`,
+bumps `cnt`, and recursively calls itself at `i+d` until it either
+reaches the end of `t` or sees `n` characters, returning the final
+index.
+
+The `iter_` function is quite simple, it just determines whether the
+word at index `i` is a lead surrogate, and returns the appropriate
+span.
+
+\begin{code}
+{-@ predicate SpanCharT N T I =
+      (SpanChar N (tarr T) (toff T) (tlen T) ((toff T)+I))
+  @-}
+
+{-@ iter_ :: t:Text -> i:TValidI t
+          -> {v:Nat | (SpanCharT v t i)}
+  @-}
+iter_ :: Text -> Int -> Int
+iter_ (Text arr off len) i
+    | m < 0xD800 || m > 0xDBFF = 1
+    | otherwise                = 2
+ where m = unsafeIndexF arr off len (off+i)
+\end{code}
+
+Again, we use `unsafeIndexF` to learn more about the structure of `t`
+by observing a small piece of it. It's also worth noting that we've
+encoded all of the domain knowledge we need into a single function,
+which has the benefit of letting us focus our attention on one type
+when we try to ensure that we've encoded it correctly.
+
+Next time, we'll continue our exploration of `text` and see how to
+construct a `Text` while ensuring the absence of out-of-bounds writes.
diff --git a/docs/blog/todo/TextWrite.lhs b/docs/blog/todo/TextWrite.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/TextWrite.lhs
@@ -0,0 +1,335 @@
+---
+layout: post
+title: "Text Write"
+date: 2014-02-23
+comments: true
+external-url:
+author: Eric Seidel
+published: false
+categories: benchmarks, text
+demo: TextWrite.hs
+---
+
+Last time, we showed how to reason about Unicode and a variable-width
+encoding of `Char`s when consuming a `Text` value, today we'll look at
+the same issue from the perspective of *building* a `Text`.
+
+
+
+
+
+We mentioned previously that `text` uses stream fusion to optimize
+multiple loops over a `Text` into a single loop; as a result many of
+the top-level API functions are simple wrappers around equivalent
+functions over `Stream`s. The creation of `Text` values is then
+largely handled by a single function, `unstream`, which converts a
+`Stream` into a `Text`.
+
+\begin{code}
+unstream :: Stream Char -> Text
+unstream (Stream next0 s0 len) = runST $ do
+  let mlen = upperBound 4 len
+  arr0 <- new mlen
+  let outer arr top = loop
+       where
+        loop !s !i =
+            case next0 s of
+              Done          -> do
+                arr' <- unsafeFreeze arr
+                return $! Text arr' 0 i
+              Skip s'       -> loop s' i
+              Yield x s'
+                | j >= top  -> do
+                  let top' = (top + 1) `shiftL` 1
+                  arr' <- new top'
+                  copyM arr' 0 arr 0 top
+                  outer arr' top' s i
+                | otherwise -> do
+                  d <- writeChar arr i x
+                  loop s' (i+d)
+                where j | ord x < 0x10000 = i
+                        | otherwise       = i + 1
+  outer arr0 mlen s0 0
+\end{code}
+
+Since we're focusing on memory safety here we won't go into detail
+about how `Stream`s work. Let's instead jump right into the inner
+`loop` and look at the `Yield` case. Here we need to write a char `x`
+into `arr`, so we compute the maximal index `j` to which we will
+write -- i.e. if `x >= U+10000` then `j = i + 1` -- and determine
+whether we can safely write at `j`. If the write is unsafe we have to
+allocate a larger array before continuing, otherwise we write `x` and
+increment `i` by `x`s width.
+
+Since `writeChar` has to handle writing *any* Unicode value, we need
+to assure it that there will always be room to write `x` into `arr`,
+regardless of `x`s width. Indeed, this is expressed in the type we
+give to `writeChar`.
+
+\begin{code}
+{-@ writeChar :: ma:MArray s -> i:Nat -> {v:Char | (Room v ma i)}
+              -> ST s {v:Nat | (RoomN v ma i)}
+  @-}
+\end{code}
+
+The predicate aliases `Room` and `RoomN` express that a character can
+fit in the array at index `i` and that there are at least `n` slots
+available starting at `i` respectively.
+
+\begin{code}
+{-@ predicate Room C MA I = (((One C) => (RoomN 1 MA I))
+                          && ((Two C) => (RoomN 2 MA I)))
+  @-}
+{-@ predicate RoomN N MA I = (I+N <= (malen MA)) @-}
+\end{code}
+
+The `One` and `Two` predicates express that a character will be
+encoded in one or two 16-bit words, by reasoning about its ordinal
+value.
+
+\begin{code}
+{-@ predicate One C = ((ord C) <  65536) @-}
+{-@ predicate Two C = ((ord C) >= 65536) @-}
+\end{code}
+
+As with `numchars`, we leave `ord` abstract, but inform LiquidHaskell
+that the `ord` *function* does in fact return the ordinal value of the
+character.
+
+\begin{code}
+{-@ measure ord :: Char -> Int @-}
+{-@ ord :: c:Char -> {v:Int | v = (ord c)} @-}
+\end{code}
+
+Since `writeChar` assumes that it will never be called unless there is room to
+write `c`, it is safe to just split `c` into 16-bit words and write them into
+the array.
+
+\begin{code}
+writeChar :: MArray s -> Int -> Char -> ST s Int
+writeChar marr i c
+    | n < 0x10000 = do
+        unsafeWrite marr i (fromIntegral n)
+        return 1
+    | otherwise = do
+        unsafeWrite marr i lo
+        unsafeWrite marr (i+1) hi
+        return 2
+    where n = ord c
+          m = n - 0x10000
+          lo = fromIntegral $ (m `shiftR` 10) + 0xD800
+          hi = fromIntegral $ (m .&. 0x3FF) + 0xDC00
+\end{code}
+
+In typical design-by-contract style, we're putting the burden of proof to
+establish safety on `writeChar`s caller. Now, scroll back up to
+`unstream` and mouse over `j` to see its inferred type.
+\begin{code} You should see something like
+{v:Int | ((ord x >= 65536) => (v == i+1))
+      && ((ord x <  65536) => (v == i))}
+\end{code}
+which, combined with the case-split on `j >= top`, provides the proof that
+writing `x` will be safe!
+
+Stay tuned, next time we'll look at another example of building a `Text` where
+LiquidHaskell fails to infer this crucial refinement...
diff --git a/docs/blog/todo/basic_termination.lhs b/docs/blog/todo/basic_termination.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/basic_termination.lhs
@@ -0,0 +1,192 @@
+---
+layout: post
+title: "Termination Checking"
+date: 2013-11-18 16:12
+comments: true
+external-url:
+categories: termination
+author: Niki Vazou
+published: false 
+demo: TerminationBasic.hs
+---
+
+As explained in the [last](LINK) [two](LINK) posts, we need a termination
+checker to ensure that LiquidHaskell is not tricked by divergent, lazy
+computations into telling lies. Well, proving termination is not easy, but
+happily, it turns out that with very little retrofitting, we can use 
+refinements to prove termination.
+
+In this post, lets see how LiquidHaskell proves termination on simple 
+recursive functions, and then later, we'll see how to look at fancier 
+cases.
+
+
+
+\begin{code}
+module Termination where
+
+import Prelude hiding (sum, (!!))
+import Data.List      (lookup)
+\end{code}
+
+Termination Check with Refinement Types
+---------------------------------------
+
+Consider a `Vec`tor that maps `Int`egers to `Val`ues:
+
+\begin{code}
+type Val   = Int
+data Vec   = V [(Int, Val)]
+
+(!!)       :: Vec -> Int -> Val
+(V a) !! i = case i `lookup` a of {Just v -> v; _ -> 0}
+\end{code}
+
+Let `sum a i` add the `i` first elements of the vector `a`:
+
+\begin{code}
+sum     :: Vec -> Int -> Val
+sum a 0 = 0
+sum a i = (a !! (i-1)) + sum a (i-1)
+\end{code}
+
+Does `sum` terminate?
+We observe that if `i` is not `0` then `sum i` will call `sum (i-1)`, otherwise
+it will return.
+This reasoning suffices to convince ourselves that `sum i` terminates for every
+natural number `i`.
+Formally, we shown that `sum` terminates because a *well-founded metric* (i.e., the
+natural number `i`) is decreasing at each iteration.
+Thus, to ensure termination it suffices to restrict `i` on Natural numbers,
+which we can do with a liquid-type signature.
+\begin{code}
+{-@ sum :: Vec -> Nat -> Val @-}
+\end{code}
+
+LiquidHaskell will apply the same reasoning to prove `sum`
+terminates:
+Conventionally, to typecheck `sum` we would check the body assuming an
+environment
+
+`a:Vec`, `i:Nat`, `sum:Vec -> Nat -> Val`
+
+Instead, we *weaken* the environment to 
+
+`a:Vec`, `i:Nat`, `sum:Vec -> {v:Nat| v < i} -> Val`
+
+Now, the type of `sum` stipulates that it *only* be recursively called with
+`Nat` (so well-founded) values that are *strictly less than* the current parameter `i`. 
+Since its body typechecks in this environment, `sum` terminates for
+every `i` on `Nat`s.
+
+Choosing the correct argument
+-----------------------------
+
+We saw that liquidHaskell can happily check that a Natural number is decreasing
+at each iteration; but it uses a naïve heuristic to choose which one. 
+For this post we can assume that it always chooses *the first* Integer. 
+
+So, a tail-recursive implementation of `sum`:
+\begin{code}
+{-@ sum' :: Vec -> Val -> Nat -> Val @-}
+sum' :: Vec -> Val -> Int -> Val
+sum' a acc 0 = acc + a!!0 
+sum' a acc i = sum' a (acc + a!!i) (i-1)
+\end{code}
+
+will fail, as liquidHaskell wants to prove that the `acc`umulator is the `Nat`ural
+number that
+decreases at each iteration.
+
+\begin{code}The remedy is simple. We can direct liquidHaskell to the correct argument `i` using a `Decrease` annotation: 
+{-@ Decrease sum' 3 @-}
+\end{code}
+which directs liquidHaskell to check whether the *third*
+argument (i.e., `i`) is decreasing.
+With this hint, liquidHaskell will happily verify that `sum'` is indeed a
+terminating function.
+
+
+Lexicographic Termination
+-------------------------
+
+Lets complicate the things a little bit.
+To do so, lets compute the `sum` of a 2D `Vec`tor:
+
+\begin{code}
+data Vec2D    = V2D [((Int, Int), Val)]
+
+(!!!)         :: Vec2D -> (Int,Int) -> Val
+(V2D a) !!! i = case i `lookup` a of {Just v -> v; _ -> 0}
+\end{code}
+
+Now we write a `sum2D a n m` function that computes the sum of the first 
+`(n+1)(m+1)` elements of `a`
+
+\begin{code}
+{-@ sum2D :: Vec2D -> Nat -> Nat -> Val @-}
+sum2D :: Vec2D -> Int -> Int -> Val
+sum2D a n m = go n m
+  where 
+       {-@ Decrease go 1 2 @-}
+        go 0 0             = 0
+        go i j | j == 0    =  a!!!(i, 0) + go (i-1) m
+               | otherwise =  a!!!(i, j) + go i (j-1)
+\end{code}
+
+Here there is no decreasing argument, 
+if `j>0`, `j` decreases (line `139`), otherwise `i` decreases (line `138`).
+Though, liquidHaskell succeed in verifying that `sum2D` terminates and the reason
+is our `Decrease go 1 2` annotation.
+This annotation informs the tool that the decreasing measure is the
+*lexicographically ordered* pair `[i,j]`. 
+LiquidHaskell will verify that this pair is indeed decreasing: at each
+iteration either `i` decreases (line `138`) or `i` remains the same and `j`
+decreases (line `139`).
+
+\begin{code}An alternative annotation to express the above decreasing measure is:
+       {-@ go :: i:Nat -> j:Nat -> Val / [i, j] @-}
+\end{code}
+where after the type signature for `go` we write the list of lexicographic
+decreasing *expressions*.
+This mechanism, as we shall see, allows us to prove termination in functions
+where the decreasing measure in a *function* of the arguments.
+
+Decreasing expressions
+----------------------
+Back to our `1D` Vector, 
+we now define a function `sumFromTo a lo hi` that sums the elements form `a!!lo`
+to `a!!hi`:
+
+\begin{code}
+{-@ sumFromTo :: Vec -> lo:Nat -> hi:{v:Nat|v>=lo} -> Val @-}
+sumFromTo :: Vec -> Int -> Int ->  Val
+sumFromTo a lo hi = go lo hi
+  where 
+       {-@ go :: lo:Nat -> hi:{v:Nat|v>=lo} -> Val / [hi-lo] @-}
+        go lo hi | lo == hi  =  a!!lo
+                 | otherwise =  a!!lo + go (lo+1) hi
+\end{code}
+
+No argument is decreasing in this function, 
+but still it does terminate, as at each iteration `lo` is increased and
+execution will terminate when `lo` reaches `hi`.
+Here the decreasing measure is the expression `hi-lo`.
+LiquidHaskell has no way to generate such a measure, but,
+if the user generates it, i.e., by annotating `go`'s signature,
+liquidHaskell will happily check that `lo-hi` is indeed a well-founded measure (as it is
+a natural number) that decreases at each iteration.
+
+
+Powered with decreasing expressions and the `Decrease` hint,
+we can prove termination on a great number of functions 
+ranging from 
+ones defined on recursive data structures
+to mutual recursive ones. 
+We shall soon see how to prove termination on more complicated functions, why
+is termination analysis required by liquidHaskell and when is it safe to
+deactivate it.
+
+\begin{code}Until then, bear in mind that you can disable termination checking using the `no-termination` flag:
+{-@ LIQUID "--no-termination" @-}
+\end{code}
diff --git a/docs/blog/todo/binary-search-trees.lhs b/docs/blog/todo/binary-search-trees.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/binary-search-trees.lhs
@@ -0,0 +1,167 @@
+---
+layout: post
+title: "Binary Search Trees"
+date: 2013-02-15 16:12
+comments: true
+external-url:
+categories: abstract-refinements
+author: Niki Vazou
+published: false
+---
+
+In this example, we show how we can use multi-parameter abstract refinements 
+to encode ordering invarants on tree structures.
+
+\begin{code}
+module Map where
+\end{code}
+
+Take for example the following refined type used to encode functional maps (from Data.Map):
+
+\begin{code}
+{-@ 
+  data Map k a  k -> Prop, r :: root:k -> k -> Prop>
+      = Tip 
+      | Bin (sz    :: Size) 
+            (key   :: k) 
+            (value :: a) 
+            (left  :: Map  (k ) a) 
+            (right :: Map  (k ) a) 
+  @-}
+
+data Map k a = Tip
+             | Bin Size k a (Map k a) (Map k a)
+
+type Size    = Int
+\end{code}
+
+The abstract refinements `l` and `r` relate each `key` of the tree with `all` the keys in the `left` and `right` subtrees of `key`, as those keys are respectively of type `k ` and `k `.
+
+Thus, if we instantiate the refinements with the following predicates
+
+\begin{code}
+{-@ type BST k a     = Map <\r -> {v:k | v < r }, \r -> {v:k | v > r }> k a @-}
+{-@ type MinHeap k a = Map <\r -> {v:k | r <= v}, \r -> {v:k | r <= v}> k a @-}
+{-@ type MaxHeap k a = Map <\r -> {v:k | r >= v}, \r -> {v:k | r >= v}> k a @-}
+\end{code}
+
+then `BST k v`, `MinHeap k v` and `MaxHeap k v` denote exactly binary-search-ordered, min-heap-ordered, and max-heap-ordered trees (with keys and values of types `k` and `v`).  
+
+We can use the above types to automatically verify ordering properties of complex libraries.
+
+For example, we cab use `BST` to prove that `Data.Map`'s `insert` and `delete` functions return a binary search tree:
+
+\begin{code}
+{-@ insert :: Ord k => k:k -> a:a -> t:BST k a -> BST k a @-}
+insert :: Ord k => k -> a -> Map k a -> Map k a
+insert kx x t
+  = case t of 
+     Tip -> singleton kx x
+     Bin sz ky y l r
+         -> case compare kx ky of
+              LT -> balance ky y (insert kx x l) r
+              GT -> balance ky y l (insert kx x r)
+              EQ -> Bin sz kx x l r
+
+{-@ delete :: (Ord k) => k:k -> t:BST k a -> BST k a @-}
+delete :: Ord k => k -> Map k a -> Map k a
+delete k t 
+  = case t of 
+      Tip -> Tip
+      Bin _ kx x l r
+          -> case compare k kx of 
+               LT -> balance kx x (delete k l) r
+               GT -> balance kx x l (delete k r)
+               EQ -> glue kx l r
+\end{code}
+
+
+Below are the functions used by `insert` and `delete`:
+
+\begin{code}
+singleton :: k -> a -> Map k a
+singleton k x
+  = Bin 1 k x Tip Tip
+
+
+glue :: k -> Map k a -> Map k a -> Map k a
+glue k Tip r = r
+glue k l Tip = l
+glue k l r
+  | size l > size r = let (km1, vm, lm) = deleteFindMax l in balance km1 vm lm r
+  | otherwise       = let (km2, vm, rm) = deleteFindMin r in balance km2 vm l rm
+
+deleteFindMax t 
+  = case t of
+      Bin _ k x l Tip -> (k, x, l)
+      Bin _ k x l r -> let (km3, vm, rm) = deleteFindMax r in 
+                       (km3, vm, (balance k x l rm))
+      Tip           -> (error ms, error ms, Tip)
+  where ms = "Map.deleteFindMax : can not return the maximal element of an empty Map"   
+
+
+deleteFindMin t 
+  = case t of
+      Bin _ k x Tip r -> (k, x, r)
+      Bin _ k x l r -> let (km4, vm, lm) = deleteFindMin l in 
+                       (km4, vm, (balance k x lm r))
+      Tip             -> (error ms, error ms, Tip)
+  where ms = "Map.deleteFindMin : can not return the maximal element of an empty Map"   
+
+
+-------------------------------------------------------------------------------
+--------------------------------- BALANCE -------------------------------------
+-------------------------------------------------------------------------------
+
+delta, ratio :: Int
+delta = 5
+ratio = 2
+
+balance :: k -> a -> Map k a -> Map k a -> Map k a 
+balance k x l r 
+  | sizeL + sizeR <= 1   = Bin sizeX k x l r
+  | sizeR >= delta*sizeL = rotateL k x l r
+  | sizeL >= delta*sizeR = rotateR k x l r
+  | otherwise            = Bin sizeX k x l r
+  where sizeL = size l
+        sizeR = size r
+        sizeX = sizeL + sizeR + 1
+
+-- rotate
+rotateL :: a -> b -> Map a b -> Map a b -> Map a b
+rotateL k x l r@(Bin _ _ _ ly ry) 
+  | size ly < ratio*size ry  = singleL k x l r
+  | otherwise                = doubleL k x l r
+rotateL _ _ _ Tip = error "rotateL Tip"
+
+rotateR :: a -> b -> Map a b -> Map a b -> Map a b
+rotateR k x l@(Bin _ _ _ ly ry) r
+  | size ry < ratio*size ly  = singleR k x l r
+  | otherwise                = doubleR k x l r
+rotateR _ _ _ Tip = error "rotateR Tip"
+
+-- basic rotations
+singleL, singleR :: a -> b -> Map a b -> Map a b -> Map a b
+singleL k1 x1 t1 (Bin _ k2 x2 t2 t3) = bin k2 x2 (bin k1 x1 t1 t2) t3
+singleL _  _  _ Tip = error "sinlgeL Tip"
+singleR k1 x1 (Bin _ k2 x2 t1 t2) t3 = Bin 0 k2 x2 t1 (Bin 0 k1 x1 t2 t3)
+singleR _  _  _ Tip = error "sinlgeR Tip"
+
+doubleL, doubleR :: a -> b -> Map a b -> Map a b -> Map a b
+doubleL k1 x1 t1 (Bin _ k2 x2 (Bin _ k3 x3 t2 t3) t4)
+ =bin k3 x3 (bin k1 x1 t1 t2) (bin k2 x2 t3 t4)
+doubleL _ _ _ _ = error "doubleL" 
+doubleR k1 x1 (Bin _ k2 x2 t1 (Bin _ k3 x3 t2 t3)) t4 
+  = bin k3 x3 (bin k2 x2 t1 t2) (bin k1 x1 t3 t4)
+doubleR _ _ _ _ = error "doubleR" 
+
+bin :: k -> a -> Map k a -> Map k a -> Map k a
+bin k x l r 
+  = Bin (size l + size r + 1) k x l r
+
+size :: Map k a -> Int
+size t 
+  = case t of 
+      Tip            -> 0
+      Bin sz _ _ _ _ -> sz
+\end{code}
diff --git a/docs/blog/todo/encoding-induction.lhs b/docs/blog/todo/encoding-induction.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/encoding-induction.lhs
@@ -0,0 +1,122 @@
+
+---
+layout: post
+title: "Encoding Induction with Abstract Refinements"
+date: 2013-02-20 16:12
+comments: true
+external-url:
+categories: abstract-refinements 
+author: Niki Vazou
+published: false
+---
+
+In this example, we explain how abstract refinements allow us to formalize
+some kinds of structural induction within the type system. 
+
+\begin{code}
+module Inductive where
+\end{code}
+
+Measures
+--------
+First, lets define an inductive data type `Vec`
+
+\begin{code}
+data Vec a = Nil | Cons a (Vec a)
+\end{code}
+
+And let us formalize a notion of _length_ for lists within the refinement logic. 
+
+To do so, we define a special `llen` measure by structural induction
+
+\begin{code}
+{-@ measure llen     :: forall a. Vec a -> Int 
+    llen (Nil)       = 0 
+    llen (Cons x xs) = 1 + llen(xs)
+  @-}
+\end{code}
+
+
+Note that the symbol `llen` is encoded as an _uninterpreted_ function in the refinement logic, and is, except for the congruence axiom, opaque to the SMT solver. The measures are guaranteed, by construction, to terminate, and so we can soundly use them as uninterpreted functions in the refinement logic. Notice also, that we can define _multiple_ measures for a type; in this case we simply conjoin the refinements from each measure when refining each data constructor.
+
+As a warmup, lets check that a _real_ length function indeed computes the length of the list:
+
+\begin{code}
+{-@ sizeOf :: xs:Vec a -> {v: Int | v = llen(xs)} @-}
+sizeOf             :: Vec a -> Int
+sizeOf Nil         = 0
+sizeOf (Cons _ xs) = 1 + sizeOf xs
+\end{code}
+
+
+
+With these strengthened constructor types, we can verify, for example, that `myappend` produces a list whose length is the sum of the input lists'
+lengths:
+
+\begin{code}
+{-@ myappend :: l: (Vec a) -> m: (Vec a) -> {v: Vec a | llen(v)=llen(l)+llen(m)} @-}
+myappend Nil         zs = zs
+myappend (Cons y ys) zs = Cons y (myappend ys zs)
+\end{code}
+
+
+\begin{code}However, consider an alternate definition of `myappend` that uses `foldr`
+myappend' ys zs = foldr (:) zs ys 
+\end{code}
+
+where `foldr :: (a -> b -> b) -> b -> [a] -> b`.
+It is unclear how to give `foldr` a (first-order) refinement type that captures the rather complex fact that the fold-function is ''applied'' all over the list argument, or, that it is a catamorphism. Hence, hitherto, it has not been possible to verify the second definition of `append`.
+
+
+Typing Folds
+------------
+
+Abstract refinements allow us to solve this problem with a very expressive type for _foldr_ whilst remaining firmly within the boundaries of SMT-based decidability. We write a slightly modified fold:
+
+\begin{code}
+{-@ efoldr :: forall a b 
 x1:b -> Prop>. 
+                op:(xs:Vec a -> x:a -> b:b 
 -> 
+                  exists [xxs : {v: Vec a | v = (Inductive.Cons x xs)}].
+                     b 
) 
+              -> vs:(exists [zz: {v: Vec a | v = Inductive.Nil}]. b 
) 
+              -> ys: Vec a
+              -> b 

+  @-}
+efoldr :: (Vec a -> a -> b -> b) -> b -> Vec a -> b
+efoldr op b Nil         = b
+efoldr op b (Cons x xs) = op xs x (efoldr op b xs) 
+\end{code}
+
+The trick is simply to quantify over the relationship `p` that `efoldr` establishes between the input list `xs` and the output `b` value. This is formalized by the type signature, which encodes an induction principle for lists: 
+the base value `b` must (1) satisfy the relation with the empty list, and the function `op` must take (2) a value that satisfies the relationship with the tail `xs` (we have added the `xs` as an extra "ghost" parameter to `op`), (3) a head value `x`, and return (4) a new folded value that satisfies the relationship with `x:xs`.
+If all the above are met, then the value returned by `efoldr` satisfies the relation with the input list `ys`.
+
+This scheme is not novel in itself --- what is new is the encoding, via uninterpreted predicate symbols, in an SMT-decidable refinement type system.
+
+Using Folds
+-----------
+
+Finally, we can use the expressive type for the above `foldr` to verify various inductive properties of client functions:
+
+\begin{code}
+{-@ size :: xs:Vec a -> {v: Int | v = llen(xs)} @-}
+size :: Vec a -> Int
+size = efoldr (\_ _ n -> suc n) 0
+
+{-@ suc :: x:Int -> {v: Int | v = x + 1} @-}
+suc :: Int -> Int
+suc x = x + 1 
+
+{-@ 
+   myappend'  :: xs: Vec a -> ys: Vec a -> {v: Vec a | llen(v) = llen(xs) + llen(ys)} 
+  @-} 
+myappend' xs ys = efoldr (\_ z zs -> Cons z zs) ys xs 
+\end{code}
+
+
+\begin{code}The verification proceeds by just (automatically) instantiating the refinement parameter `p` of `efoldr` with the concrete refinements, via Liquid typing:
+
+{\xs v -> v = llen(xs)}                   -- for size
+{\xs v -> llen(v) = llen(xs) + llen(zs)}  -- for myappend'
+\end{code}
+
diff --git a/docs/blog/todo/index-dependent-maps.hs b/docs/blog/todo/index-dependent-maps.hs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/index-dependent-maps.hs
@@ -0,0 +1,217 @@
+-- ---
+-- layout: post
+-- title: "Index-Dependent Maps"
+-- date: 2013-01-20 16:12
+-- comments: true
+-- external-url:
+-- categories: abstract-refinement, basic
+-- author: Niki Vazou
+-- published: false
+-- ---
+
+-- In this example, we illustrate how abstract invariants allow us to specify
+-- and verify index-dependent invariants of key-value maps.  To this end, we
+-- develop a small library of _extensible vectors_ encoded, for purposes of
+-- illustration, as functions from `Int` to some generic range `a`.
+
+
+module LiquidArray where
+
+import Language.Haskell.Liquid.Prelude (liquidAssume)
+
+
+-- \begin{code}We specify vectors as
+-- type Vec a  Prop, rng :: Int -> a -> Prop>
+--   = (i:Int  -> a)
+-- \end{code}
+
+
+type Vec a = Int -> a
+
+
+-- Here, we are parametrizing the definition of the type `Vec` with _two_ abstract refinements, `dom` and `rng`, which respectively describe the _domain_ and _range_ of the vector.
+-- That is, `dom` describes the set of _valid_ indices, and `rng` specifies an invariant relating each `Int` index with the value stored at that index.
+
+-- Creating Vectors
+-- ----------------
+
+-- We can use the following basic functions to create vectors:
+
+
+{- empty :: forall  a -> Prop>.
+              i:{v: Int | 0 = 1} ->  a -}
+
+{-@ empty :: i: {v: Int | 0 = 1} -> a @-}
+empty :: Vec a
+empty = \_ -> (error "Empty Vec")
+
+{-@ create :: x:a -> (i:Int -> {v:a | v = x}) @-}
+create :: a -> Vec a
+create x = (\_ -> x)
+
+
+-- The signature for `empty` states that its domain is empty (ie is the set of indices satisfying the predicate `False`), and that the range satisfies _any_ invariant. The signature for `create`, instead, defines a _constant_ vector that maps every index to the constant `x`.
+
+-- Accessing Vectors
+-- -----------------
+
+-- We can write the following `get` function for reading the contents of a vector at a given index:
+
+
+{-@ get :: forall a  Prop, r :: x0: Int -> x1:a -> Prop>.
+             i: Int ->
+             a: (j: Int -> a) ->
+             a
+  @-}
+get :: Int -> Vec a -> a
+get i a = a i
+
+
+-- The signature states that for any domain `d` and range `r`, if the index `i` is a valid index, ie is of type, `Int` then the returned value is an `a` that additionally satisfies the range refinement at the index `i`.
+
+-- The type for `set`, which _updates_ the vector at a given index, is even more interesting, as it allows us to _extend_ the domain of the vector:
+
+
+{-@ set :: forall a  x1: a -> Prop, d :: x0: Int -> Prop>.
+      i: Int ->
+      x: a ->
+      a: (j: {v: Int | v != i} -> a) ->
+      (k : Int -> a)
+  @-}
+set :: Int -> a -> Vec a -> Vec a
+set i x a = \k -> if k == i then x else a k
+
+
+-- The signature for `set` requires that (a) the input vector is defined everywhere at `d` _except_ the index `i`, and (b) the value supplied must be of type `a`, ie satisfy the range relation at the index `i` at which the vector is being updated.
+-- The signature ensures that the output vector is defined at `d` and each value satisfies the index-dependent range refinement `r`.
+
+-- Note that it is legal to call `get` with a vector that is _also_ defined at the index `i` since, by contravariance, such a vector is a subtype of that required by (a).
+
+
+-- Initializing Vectors
+-- --------------------
+
+-- Next, we can write the following function, `init`, that ''loops'' over a vector, to `set` each index to a value given by some function.
+
+
+{-@ initialize :: forall a  x1: a -> Prop>.
+      f: (z: Int -> a) ->
+      i: {v: Int | v >= 0} ->
+      n: Int ->
+      a: (j: {v: Int | (0 <= v && v < i)} -> a) ->
+      (k: {v: Int | (0 <= v && v < n)} -> a) @-}
+initialize :: (Int -> a) -> Int -> Int -> Vec a -> Vec a
+initialize f i n a
+  | i >= n    = a
+  | otherwise = initialize f (i + 1) n (set i (f i) a)
+
+
+-- The signature requires that (a) the higher-order function `f` produces values that satisfy the range refinement `r`, and (b) the vector is initialized from `0` to `i`.
+-- The function ensures that the output vector is initialized from `0`
+-- through `n`.
+
+-- We can thus verify that
+
+
+{-@ idVec :: n:Int -> (k: {v: Int | (0 <= v && v < n)} -> {v: Int | v = k}) @-}
+idVec :: Int -> (Vec Int)
+idVec n = initialize (\i -> i) 0 n empty
+
+
+-- ie `idVec` returns an vector of size `n` where each key is mapped to itself. Thus, abstract refinement types allow us to verify low-level idioms such as the incremental initialization of vectors, which have previously required special analyses.
+
+-- Null-Terminated Strings
+-- -----------------------
+
+-- We can also use abstract refinements to verify code which manipulates C-style null-terminated strings, where each character is represented as an `Int` and the termination character `\0`, and only that, is represented as `0`.
+
+-- \begin{code}Formally, a null-terminated string, represented by `Int`s, of size `n` has the type
+-- type NullTerm n
+--      = Vec <{\v -> 0<=v i=n-1 => v=0}> Int
+-- \end{code}
+
+-- The above type describes a length-`n` vector of characters whose last element must be a null character, signalling the end of the string.
+
+-- We can use this type in the specification of a function, `upperCase`, which iterates through the characters of a string, uppercasing each one until it encounters the null terminator:
+
+
+ucs :: Int -> Int -> Vec Int -> Vec Int
+ucs n i s =
+  case get i s of
+  0 -> s
+  c -> ucs n (i + 1) (set i (c + 32) s)
+
+{-@ upperCaseString ::
+      n: {v: Int | v > 0} ->
+      s: (j: {v : Int | (0 <= v && v < n)} ->
+          {v: Int | (j = n - 1 => v = 0)}) ->
+      (j: {v : Int | (0 <= v && v < n)} ->
+       {v: Int | (j = n - 1 => v = 0)})
+@-}
+upperCaseString :: Int -> Vec Int -> Vec Int
+upperCaseString n s = ucs n 0 s
+
+
+
+-- Note that the length parameter `n` is provided solely as a ''witness'' for the length of the string `s`, which allows us to use the length of `s` in the type of `upperCaseString`; `n` is not used in the computation.
+
+-- In order to establish that each call to `get` accesses string `s` within its bounds, our type system must establish that, at each call to the inner function `ucs`, `i` satisfies the type `{v: Int | 0 <= v && v < n}`.
+
+-- This invariant is established as follows:
+
+-- First, the invariant trivially holds on the first call to `ucs`, as
+-- `n` is positive and `i` is `0`.
+-- Second, we assume that `i` satisfies the type `{v: Int | 0 <= v && v < n}`, and, further, we know from the types of `s` and `get` that `c` has the type `{v: Int | i = n - 1 => c = 0}`.
+-- Thus, if `c` is non-null, then `i` cannot be equal to `n - 1`.
+-- This allows us to strengthen our type for `i` in the else branch to `{v: Int | 0 <= v && v < n - 1}` and thus to conclude that the value `i + 1` recursively passed as the `i` parameter to `ucs` satisfies the type `{v: Int | 0 <= v && v < n}`, establishing the inductive invariant and thus the safety of the `upperCaseString` function.
+
+
+
+-- Memoization
+-- -----------
+
+-- Next, let us illustrate how the same expressive signatures allow us to verify memoizing functions. We can specify to the SMT solver the definition of the Fibonacci function via an uninterpreted function `fib` and an axiom:
+
+
+{-@ measure fib :: Int -> Int @-}
+
+{-@ axiom_fib :: i:Int -> {v: Bool | (Prop(v) <=>
+                            (fib(i) = ((i <= 1) ? 1 : ((fib(i-1)) + (fib(i-2))))))}
+  @-}
+axiom_fib :: Int -> Bool
+axiom_fib i = undefined
+
+
+-- Next, we define a type alias `FibV` for the vector whose values are either `0` (ie undefined), or equal to the Fibonacci number of the corresponding index.
+
+
+{-@ type FibV = j:Int -> {v:Int| ((v != 0) => (v = fib(j)))} @-}
+
+
+-- Finally, we can use the above alias to verify `fastFib`, an implementation of the Fibonacci function, which uses an vector memoize intermediate results
+
+
+{-@ fastFib :: x:Int -> {v:Int | v = fib(x)} @-}
+fastFib     :: Int -> Int
+fastFib n   = snd $ fibMemo (\_ -> 0) n
+
+{-@ fibMemo :: FibV -> i:Int -> (FibV, {v: Int | v = fib(i)}) @-}
+fibMemo t i
+  | i <= 1
+  = (t, liquidAssume (axiom_fib i) (1 :: Int))
+
+  | otherwise
+  = case get i t of
+      0 -> let (t1, n1) = fibMemo t  (i-1)
+               (t2, n2) = fibMemo t1 (i-2)
+               n        = liquidAssume (axiom_fib i) (n1 + n2)
+           in  (set i n t2,  n)
+      n -> (t, n)
+
+
+-- Thus, abstract refinements allow us to define key-value maps with index-dependent refinements for the domain and range.
+-- Quantification over the domain and range refinements allows us to define generic access operations (eg. `get`, `set`, `create`, `empty`) whose types enable us establish a variety of precise invariants.
+
+
+
+
diff --git a/docs/blog/todo/index-dependent-maps.lhs b/docs/blog/todo/index-dependent-maps.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/index-dependent-maps.lhs
@@ -0,0 +1,217 @@
+---
+layout: post
+title: "Index-Dependent Maps"
+date: 2013-01-20 16:12
+comments: true
+external-url:
+categories: abstract-refinement, basic
+author: Niki Vazou
+published: false
+---
+
+In this example, we illustrate how abstract invariants allow us to specify
+and verify index-dependent invariants of key-value maps.  To this end, we
+develop a small library of _extensible vectors_ encoded, for purposes of
+illustration, as functions from `Int` to some generic range `a`. 
+
+\begin{code}
+module LiquidArray where
+
+import Language.Haskell.Liquid.Prelude (liquidAssume)
+\end{code}
+
+\begin{code}We specify vectors as 
+type Vec a  Prop, rng :: Int -> a -> Prop>
+  = (i:Int  -> a)
+\end{code}
+
+\begin{code}
+type Vec a = Int -> a
+\end{code}
+
+Here, we are parametrizing the definition of the type `Vec` with _two_ abstract refinements, `dom` and `rng`, which respectively describe the _domain_ and _range_ of the vector.
+That is, `dom` describes the set of _valid_ indices, and `rng` specifies an invariant relating each `Int` index with the value stored at that index.
+
+Creating Vectors
+----------------
+
+We can use the following basic functions to create vectors:
+
+\begin{code}
+{- empty :: forall  a -> Prop>. 
+              i:{v: Int | 0 = 1} ->  a -}
+
+{-@ empty :: i: {v: Int | 0 = 1} -> a @-}
+empty :: Vec a
+empty = \_ -> (error "Empty Vec")
+
+{-@ create :: x:a -> (i:Int -> {v:a | v = x}) @-}
+create :: a -> Vec a
+create x = (\_ -> x)
+\end{code}
+
+The signature for `empty` states that its domain is empty (ie is the set of indices satisfying the predicate `False`), and that the range satisfies _any_ invariant. The signature for `create`, instead, defines a _constant_ vector that maps every index to the constant `x`.
+
+Accessing Vectors
+-----------------
+
+We can write the following `get` function for reading the contents of a vector at a given index:
+
+\begin{code}
+{-@ get :: forall a  Prop, r :: x0: Int -> x1:a -> Prop>.
+             i: Int ->
+             a: (j: Int -> a) ->
+             a 
+  @-}
+get :: Int -> Vec a -> a
+get i a = a i
+\end{code}
+
+The signature states that for any domain `d` and range `r`, if the index `i` is a valid index, ie is of type, `Int` then the returned value is an `a` that additionally satisfies the range refinement at the index `i`.
+
+The type for `set`, which _updates_ the vector at a given index, is even more interesting, as it allows us to _extend_ the domain of the vector:
+
+\begin{code}
+{-@ set :: forall a  x1: a -> Prop, d :: x0: Int -> Prop>.
+      i: Int ->
+      x: a ->
+      a: (j: {v: Int | v != i} -> a) ->
+      (k : Int -> a)
+  @-}
+set :: Int -> a -> Vec a -> Vec a
+set i x a = \k -> if k == i then x else a k
+\end{code}
+
+The signature for `set` requires that (a) the input vector is defined everywhere at `d` _except_ the index `i`, and (b) the value supplied must be of type `a`, ie satisfy the range relation at the index `i` at which the vector is being updated.
+The signature ensures that the output vector is defined at `d` and each value satisfies the index-dependent range refinement `r`.
+
+Note that it is legal to call `get` with a vector that is _also_ defined at the index `i` since, by contravariance, such a vector is a subtype of that required by (a).
+
+
+Initializing Vectors
+--------------------
+
+Next, we can write the following function, `init`, that ''loops'' over a vector, to `set` each index to a value given by some function.
+
+\begin{code}
+{-@ initialize :: forall a  x1: a -> Prop>.
+      f: (z: Int -> a) ->
+      i: {v: Int | v >= 0} ->
+      n: Int ->
+      a: (j: {v: Int | (0 <= v && v < i)} -> a) ->
+      (k: {v: Int | (0 <= v && v < n)} -> a) @-}
+initialize :: (Int -> a) -> Int -> Int -> Vec a -> Vec a
+initialize f i n a 
+  | i >= n    = a
+  | otherwise = initialize f (i + 1) n (set i (f i) a)
+\end{code}
+
+The signature requires that (a) the higher-order function `f` produces values that satisfy the range refinement `r`, and (b) the vector is initialized from `0` to `i`.
+The function ensures that the output vector is initialized from `0`
+through `n`.
+
+We can thus verify that
+
+\begin{code}
+{-@ idVec :: n:Int -> (k: {v: Int | (0 <= v && v < n)} -> {v: Int | v = k}) @-}
+idVec :: Int -> (Vec Int)
+idVec n = initialize (\i -> i) 0 n empty
+\end{code}
+
+ie `idVec` returns an vector of size `n` where each key is mapped to itself. Thus, abstract refinement types allow us to verify low-level idioms such as the incremental initialization of vectors, which have previously required special analyses.
+
+Null-Terminated Strings
+-----------------------
+
+We can also use abstract refinements to verify code which manipulates C-style null-terminated strings, where each character is represented as an `Int` and the termination character `\0`, and only that, is represented as `0`.
+
+\begin{code}Formally, a null-terminated string, represented by `Int`s, of size `n` has the type
+type NullTerm n 
+     = Vec <{\v -> 0<=v i=n-1 => v=0}> Int
+\end{code}
+
+The above type describes a length-`n` vector of characters whose last element must be a null character, signalling the end of the string.
+
+We can use this type in the specification of a function, `upperCase`, which iterates through the characters of a string, uppercasing each one until it encounters the null terminator:
+
+\begin{code}
+ucs :: Int -> Int -> Vec Int -> Vec Int
+ucs n i s =
+  case get i s of
+  0 -> s
+  c -> ucs n (i + 1) (set i (c + 32) s)
+
+{-@ upperCaseString ::
+      n: {v: Int | v > 0} ->
+      s: (j: {v : Int | (0 <= v && v < n)} ->
+          {v: Int | (j = n - 1 => v = 0)}) ->
+      (j: {v : Int | (0 <= v && v < n)} ->
+       {v: Int | (j = n - 1 => v = 0)})
+@-}
+upperCaseString :: Int -> Vec Int -> Vec Int
+upperCaseString n s = ucs n 0 s
+\end{code}
+
+
+Note that the length parameter `n` is provided solely as a ''witness'' for the length of the string `s`, which allows us to use the length of `s` in the type of `upperCaseString`; `n` is not used in the computation.
+
+In order to establish that each call to `get` accesses string `s` within its bounds, our type system must establish that, at each call to the inner function `ucs`, `i` satisfies the type `{v: Int | 0 <= v && v < n}`.
+
+This invariant is established as follows:
+
+First, the invariant trivially holds on the first call to `ucs`, as
+`n` is positive and `i` is `0`.
+Second, we assume that `i` satisfies the type `{v: Int | 0 <= v && v < n}`, and, further, we know from the types of `s` and `get` that `c` has the type `{v: Int | i = n - 1 => c = 0}`.
+Thus, if `c` is non-null, then `i` cannot be equal to `n - 1`.
+This allows us to strengthen our type for `i` in the else branch to `{v: Int | 0 <= v && v < n - 1}` and thus to conclude that the value `i + 1` recursively passed as the `i` parameter to `ucs` satisfies the type `{v: Int | 0 <= v && v < n}`, establishing the inductive invariant and thus the safety of the `upperCaseString` function.
+
+
+
+Memoization 
+-----------
+
+Next, let us illustrate how the same expressive signatures allow us to verify memoizing functions. We can specify to the SMT solver the definition of the Fibonacci function via an uninterpreted function `fib` and an axiom:
+
+\begin{code}
+{-@ measure fib :: Int -> Int @-}
+
+{-@ axiom_fib :: i:Int -> {v: Bool | (Prop(v) <=> 
+                            (fib(i) = ((i <= 1) ? 1 : ((fib(i-1)) + (fib(i-2))))))} 
+  @-}
+axiom_fib :: Int -> Bool
+axiom_fib i = undefined
+\end{code}
+
+Next, we define a type alias `FibV` for the vector whose values are either `0` (ie undefined), or equal to the Fibonacci number of the corresponding index. 
+
+\begin{code}
+{-@ type FibV = j:Int -> {v:Int| ((v != 0) => (v = fib(j)))} @-}
+\end{code}
+
+Finally, we can use the above alias to verify `fastFib`, an implementation of the Fibonacci function, which uses an vector memoize intermediate results 
+
+\begin{code}
+{-@ fastFib :: x:Int -> {v:Int | v = fib(x)} @-}
+fastFib     :: Int -> Int
+fastFib n   = snd $ fibMemo (\_ -> 0) n
+
+{-@ fibMemo :: FibV -> i:Int -> (FibV, {v: Int | v = fib(i)}) @-}
+fibMemo t i 
+  | i <= 1    
+  = (t, liquidAssume (axiom_fib i) (1 :: Int))
+  
+  | otherwise 
+  = case get i t of   
+      0 -> let (t1, n1) = fibMemo t  (i-1)
+               (t2, n2) = fibMemo t1 (i-2)
+               n        = liquidAssume (axiom_fib i) (n1 + n2)
+           in  (set i n t2,  n)
+      n -> (t, n)
+\end{code}
+
+Thus, abstract refinements allow us to define key-value maps with index-dependent refinements for the domain and range. 
+Quantification over the domain and range refinements allows us to define generic access operations (eg. `get`, `set`, `create`, `empty`) whose types enable us establish a variety of precise invariants.
+
+
+
+
diff --git a/docs/blog/todo/kmeans-full.lhs b/docs/blog/todo/kmeans-full.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/kmeans-full.lhs
@@ -0,0 +1,270 @@
+---
+layout: post
+title: "KMeans Clustering N-Dimensional Points"
+date: 2013-02-14 16:12
+author: Ranjit Jhala
+published: false 
+comments: true
+external-url:
+categories: basic measures 
+demo: kmeans.hs
+---
+
+[Last time][safeList] we introduced a new specification called a *measure*
+and demonstrated how to use it to encode the *length* of a list, and
+thereby verify that functions like `head` and `tail` were only called with
+non-empty lists (whose length was *strictly* greater than `0`.) As several
+folks pointed out, once LiquidHaskell can reason about lengths, it can do a
+lot more than just analyze non-emptiness. 
+
+Indeed! 
+
+So today, let me show you how one might implement a k-means algorithm that
+clusters `n`-dimensional points into at most k groups, and how
+LiquidHaskell can help us write and enforce these size requirements. 
+
+
+
+
+
+Rather than reinvent the wheel, lets start with an existing implementation
+of K-Means, available [on hackage](hackage-kmeans). This may not be the most 
+efficient implementation, but its a nice introduction to the algorithm, and we 
+speculate that the general invariants will hold for more sophisticated
+implementations.
+
+
+\begin{code}
+
+nearest centers x   = minimumKey distances
+  where distances   = M.map (distance x) centers
+
+minimumKey   :: (Ord v) => M.Map k v -> k
+minimumKey   = fst . minimumBy (\x y -> compare (snd x) (snd y)) . M.toList 
+
+distance     :: [Double] -> [Double] -> [Double]
+distance a b = sqrt . sum $ zipWith (\x y -> (x - y) ^ 2) a b
+
+normalize (n :: Int) = M.map (\(c, s) -> map (`safeDiv` s) c) 
+
+initialCenters :: [a] -> M.HashMap Int [a] -> 
+
+{-@ NNList a      = {v: [a] | ((len v) > 0) }           @-}
+{-@ BoundInt  K   = {v: Int | (0 <= v) && (v < K) }     @-}
+{-@ Point a   N   = {v: [a] | (len v) = N }             @-}
+{-@ Points a  N   = NNList (Point a n)                  @-}
+{-@ Cluster a K N = M.HashMap (BoundInt K) (Point a N)  @-}
+
+{-@ initialCenters  :: k:{k:Int | k > 0} -> [a] -> M.HashMap (BoundInt k) (NNList a) @-}
+initialCenters      :: Int -> [a] -> M.HashMap Int [a]  
+initialCenters k xs = M.fromList $ zip indices partitions 
+  where 
+    clusterSize     = max 1 ((length points + k - 1) `div` k)
+    parts           = partition clusterSize points
+    nParts          = length parts
+    indices         = liquidAssume (nParts <= k) [1..nParts]
+
+{-@ partition        :: {v:Int | v > 0} -> [a] -> [(NNList a)] @-}
+partition n []       = []
+partition n ys@(_:_) = zs : part n zs' 
+  where 
+    zs               = take n ys
+    zs'              = drop n ys
+
+kmeansStep :: n:Int -> [Point Double n] -> M.Map k (Point Double n) -> M.Map k (Point Double n) 
+kmeansStep (n :: Int) centers = M.fromList . mapReduce newCenter mergeCluster
+  where
+    recenter x              = [(nearest centers x, (x, 1))]
+    merge (c1, s1) (c2, s2) = (zipWith (+) c1 c2, s1 + s2)
+
+           
+kmeans n k xs  = initialCenters k xs
+
+-- kgroupBy :: k:Int -> (a -> BoundInt k) -> [a] -> {v: [(NNList a)] | (len v) <= k }
+\end{code}
+
+
+
+-- let rec ffor i j f = 
+--   if i < j then (
+--     f i; 
+--     ffor (i+1) j f
+--   )
+-- 
+-- let min_index a =
+--   let min = ref 0 in
+--   ffor 0 (Array.length a) (fun i ->
+--     if a.(i) < a.(!min) then            (* ARRAY BOUNDS *)
+--       min := i
+--   );
+--   !min
+-- 
+-- let nearest dist ctra x  =
+--   let da = Array.map (dist x) ctra in
+--   (min_index da, (x, 1))
+-- 
+-- let centroid plus p1 p2 = 
+--   let (x1, size1) = p1 in
+--   let (x2, size2) = p2 in 
+--   (plus x1 x2, size1 + size2)
+-- 
+-- let update_centers div a ixs =
+--   List.iter (fun (i, (x, size)) -> a.(i) <- div x size) ixs
+--             (* ARRAY BOUNDS, DIV BY ZERO *)
+-- 
+-- let kmeans n dist plus div (points : 'a list) (centera : 'a array) =
+--   assert (Array.length centera > 0); 
+--   ffor 0 n begin fun _ ->
+--     let point_centers   = map      (nearest dist centera) points      in
+--     let center_clusters = group    point_centers                      in 
+--     let new_centers     = reduce   (centroid plus) center_clusters    in
+--     update_centers div centera new_centers
+--   end  
+
+
+\begin{code}
+
+{-# LANGUAGE ScopedTypeVariables, TypeSynonymInstances, FlexibleInstances #-}
+
+module Data.KMeans (kmeans, kmeansGen) where
+
+import Data.List (sort, span, minimumBy)
+import Data.Function (on)
+import Data.Ord (comparing)
+import Language.Haskell.Liquid.Prelude (liquidAssert, liquidError)
+
+{-@ groupBy :: (a -> a -> Bool) 
+            -> [a] 
+            -> [{v:[a] | len(v) > 0}] 
+  @-}
+
+groupBy           :: (a -> a -> Bool) -> [a] -> [[a]]
+groupBy _  []     =  []
+groupBy eq (x:xs) =  (x:ys) : groupBy eq zs
+                     where (ys,zs) = span (eq x) xs
+
+{-@ type Vec a N      = { v : [a] | (len v) = N } @-}
+
+{-@ type Matrix a N M = Vec (Vec a N) M           @-}
+
+{-@ type PosInt       = {v:Int | v > 0}           @-}
+
+
+{-@ transpose :: n:Int -> m:PosInt -> Matrix a n m -> Matrix a m n @-}
+transpose     :: Int -> Int -> [[a]] -> [[a]]
+
+transpose 0 _ _              = []
+transpose n m ((x:xs) : xss) = (x : map head xss) : transpose (n - 1) m (xs : map tail xss)
+-- transpose n m ((x:xs) : xss) = (x : [h | (h:_) <- xss]) : transpose (xs : [ t | (_:t) <- xss])
+transpose n m ([] : _)       = liquidError "transpose1" 
+transpose n m []             = liquidError "transpose2"
+
+
+data WrapType b a = WrapType {getVect :: b, getVal :: a}
+
+instance Eq (WrapType [Double] a) where
+   (==) = (==) `on` getVect
+
+instance Ord (WrapType [Double] a) where
+    compare = comparing getVect
+
+-- dist ::  [Double] -> [Double] -> Double 
+dist a b = sqrt . sum $ zipWith (\x y -> (x - y) ^ 2) a b      -- zipWith dimensions
+
+safeDiv     :: (Fractional a) => a -> Int -> a
+safeDiv n 0 = liquidError "divide by zero"
+safeDiv n d = n / (fromIntegral d)
+
+
+centroid n points = map ((`safeDiv` m) . sum) points'              -- divide By Zero
+  where 
+    m             = length points 
+    points'       = transpose n m (map getVect points)
+
+
+recluster n clusters = recluster' n centroids points 
+  where 
+    points         = concat clusters 
+    centroids      = indexList $ map (centroid n) clusters
+    centeredPoints = [(closest n centroids (getVect p), p) | p <- points]
+    clusters'      = map (map snd)
+
+
+recluster' n centroids points = map (map snd) $ groupBy ((==) `on` fst) reclustered
+    where reclustered = sort [(closest n centroids (getVect p), p) | p <- points]
+
+
+closest :: Int -> [(Int, [Double])] -> [Double] -> Int
+closest (n :: Int) centroids point = minimumKey distances 
+  where 
+    distances = [(i, dist point ci) | (i, ci) <- icentroids ]
+
+minimumKey :: (Ord v) => [(k, v)] -> k
+minimumKey kvs = minimumBy (\x y -> compare (snd x) (snd y)) kvs
+
+indexList :: [a] -> [(Int, a)]
+indexList xs         = zip [1..(length xs)] xs
+
+
+
+
+
+{-@ part        :: n:{v:Int | v > 0} -> [a] -> [{v:[a] | len(v) > 0}] @-}
+part n []       = []
+part n ys@(_:_) = zs : part n zs' 
+                  where zs  = take n ys
+                        zs' = drop n ys
+
+-- | Recluster points
+kmeans'' n clusters
+  | clusters == clusters' = clusters
+  | otherwise             = kmeans'' n clusters'
+  where clusters'         = recluster n clusters
+
+kmeans' n k points = kmeans'' n $ part l points
+    where l = max 1 ((length points + k - 1) `div` k)
+
+-- | Cluster points in a Euclidian space, represented as lists of Doubles, into at most k clusters.
+-- The initial clusters are chosen arbitrarily.
+{-@ kmeans :: n:Int 
+           -> k:Int 
+           -> points:[(Vec Double n)] 
+           -> [[(Vec Double n)]] 
+  @-}
+kmeans :: Int -> Int -> [[Double]] -> [[[Double]]]
+kmeans n = kmeansGen n id
+
+-- | A generalized kmeans function. This function operates not on points, but an arbitrary type 
+--   which may be projected into a Euclidian space. Since the projection may be chosen freely, 
+-- this allows for weighting dimensions to different degrees, etc.
+
+{-@ kmeansGen :: n: Int -> f:(a -> (Vec Double n)) -> k:Int -> points:[a] -> [[a]] @-}
+kmeansGen :: Int -> (a -> [Double]) -> Int -> [a] -> [[a]]
+kmeansGen n f k points = map (map getVal) . kmeans' n k . map (\x -> WrapType (f x) x) $ points
+
+
+\end{code}
+
+
+
+Conclusions
+-----------
+
+1. How to do *K-Means Clustering* !
+
+2. Track precise length properties with **measures**
+
+3. Circumvent limitations of SMT with a touch of **dynamic** checking using **assumes**
+
+
+[vecbounds]:  /blog/2013/01/05/bounding-vectors.lhs/ 
+[ghclist]:    https://github.com/ucsd-progsys/liquidhaskell/blob/master/include/GHC/List.lhs#L125
+[foldl1]:     http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/Data-List.html#foldl1
+[safeList]:   /blog/2013/01/31/safely-catching-a-list-by-its-tail.lhs/ 
+
+
+
diff --git a/docs/blog/todo/lets-talk-about-sets.lhs.markdown b/docs/blog/todo/lets-talk-about-sets.lhs.markdown
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/lets-talk-about-sets.lhs.markdown
@@ -0,0 +1,671 @@
+---
+layout: post
+title: "Lets Talk About Sets"
+date: 2013-01-05 16:12
+comments: true
+external-url:
+categories: basic, measures, sets
+author: Ranjit Jhala
+published: false 
+---
+
+In the posts so far, we've seen how LiquidHaskell allows you to use SMT 
+solvers to specify and verify *numeric* invariants -- denominators 
+that are non-zero, integer indices that are within the range of an 
+array, vectors that have the right number of dimensions and so on.
+
+However, SMT solvers are not limited to numbers, and in fact, support
+rather expressive logics. In the next couple of posts, lets see how 
+LiquidHaskell uses SMT to talk about **sets of values**, for example, 
+the contents of a list, and to specify and verify properties about 
+those sets.
+
+
+
24: module ListSets where
+

+
+Talking about Sets (In Logic)
+=============================
+
+First, we need a way to talk about sets in the refinement logic. We could
+roll our own special Haskell type, but why not just use the `Set a` type
+from `Data.Set`.
+
+
+
35: import Data.Set hiding (filter, split)
+36: import Prelude  hiding (reverse, filter)
+

+
+The above, also instructs LiquidHaskell to import in the various 
+specifications defined for the `Data.Set` module that we have *predefined* 
+in [Data/Set.spec][setspec] 
+
+Lets look at the specifications.
+
+ The `embed` directive tells LiquidHaskell to model the **Haskell** 
+
46: type constructor `Set` with the **SMT** type constructor `Set_Set`.
+47: 
+48: module spec Data.Set where
+49: 
+50: embed Set as Set_Set
+

+
+ First, we define the logical operators (i.e. `measure`s) 
+
54: measure Set_sng  :: a -> (Set a)                    -- ^ singleton
+55: measure Set_cup  :: (Set a) -> (Set a) -> (Set a)   -- ^ union
+56: measure Set_cap  :: (Set a) -> (Set a) -> (Set a)   -- ^ intersection
+57: measure Set_dif  :: (Set a) -> (Set a) -> (Set a)   -- ^ difference 
+

+
+ Next, we define predicates on `Set`s 
+
61: measure Set_emp  :: (Set a) -> Prop                 -- ^ emptiness
+62: measure Set_mem  :: a -> (Set a) -> Prop            -- ^ membership
+63: measure Set_sub  :: (Set a) -> (Set a) -> Prop      -- ^ inclusion 
+

+
+
+Interpreted Operations
+----------------------
+
+The above operators are *interpreted* by the SMT solver. That is, just 
+like the SMT solver *"knows that"* 
+
+    2 + 2 == 4
+
+the SMT solver *"knows that"* 
+
+    (Set_sng 1) == (Set_cap (Set_sng 1) (Set_cup (Set_sng 2) (Set_sng 1)))
+
+This is because, the above formulas belong to a decidable Theory of Sets
+which can be reduced to McCarthy's more general [Theory of Arrays][mccarthy]. 
+See [this recent paper][z3cal] if you want to learn more about how modern SMT 
+solvers *"know"* the above equality holds...
+
+Talking about Sets (In Code)
+============================
+
+Of course, the above operators exist purely in the realm of the 
+refinement logic, beyond the grasp of the programmer.
+
+To bring them down (or up, or left or right) within reach of Haskell code, 
+we can simply *assume* that the various public functions in `Data.Set` do 
+the *Right Thing* i.e. produce values that reflect the logical set operations:
+
+ First, the functions that create `Set` values
+
95: empty     :: {v:(Set a) | (Set_emp v)}
+96: singleton :: x:a -> {v:(Set a) | v = (Set_sng x)}
+

+
+ Next, the functions that operate on elements and `Set` values
+
100: insert :: Ord a => x:a -> xs:(Set a) -> {v:(Set a) | v = (Set_cup xs (Set_sng x))}
+101: delete :: Ord a => x:a -> xs:(Set a) -> {v:(Set a) | v = (Set_dif xs (Set_sng x))}
+

+
+ Then, the binary `Set` operators
+
105: union        :: Ord a => xs:(Set a) -> ys:(Set a) -> {v:(Set a) | v = (Set_cup xs ys)}
+106: intersection :: Ord a => xs:(Set a) -> ys:(Set a) -> {v:(Set a) | v = (Set_cap xs ys)}
+107: difference   :: Ord a => xs:(Set a) -> ys:(Set a) -> {v:(Set a) | v = (Set_dif xs ys)}
+

+
+ And finally, the predicates on `Set` values:
+
111: isSubsetOf :: Ord a => xs:(Set a) -> ys:(Set a) -> {v:Bool | (Prop v) <=> (Set_sub xs ys)}
+112: member     :: Ord a => x:a -> xs:(Set a) -> {v:Bool | (Prop v) <=> (Set_mem x xs)}
+

+
+**Note:** Oh quite. We shouldn't and needn't really *assume*, but should and
+will *guarantee* that the functions from `Data.Set` implement the above types. 
+But thats a story for another day...
+
+Proving Theorems With LiquidHaskell
+===================================
+
+OK, lets take our refined operators from `Data.Set` out for a spin!
+One pleasant consequence of being able to precisely type the operators 
+from `Data.Set` is that we have a pleasant interface for using the SMT
+solver to *prove theorems* about sets, while remaining firmly rooted in
+Haskell. 
+
+First, lets write a simple function that asserts that its input is `True`
+
+
+
131: {-@ boolAssert :: {v: Bool | (Prop v)} -> {v:Bool | (Prop v)} @-}
+132: {VV : (GHC.Types.Bool) | (? Prop([VV]))}
+-> {VV : (GHC.Types.Bool) | (? Prop([VV]))}boolAssert True   = {VV : (GHC.Types.Bool) | (? Prop([VV])),(VV = True)}True
+133: boolAssert False  = [(GHC.Types.Char)] -> {VV : (GHC.Types.Bool) | false}error {VV : [(GHC.Types.Char)] | (len([VV]) >= 0)}"boolAssert: False? Never!"
+

+
+Now, we can use `boolAssert` to write some simple properties. (Yes, these do
+indeed look like QuickCheck properties -- but here, instead of generating
+tests and executing the code, the type system is proving to us that the
+properties will *always* evaluate to `True`) 
+
+Lets check that `intersection` is commutative ...
+
+
+
144: {-@ prop_cap_comm :: Set Int -> Set Int -> Bool @-}
+145: prop_cap_comm     :: Set Int -> Set Int -> Bool
+146: (Data.Set.Base.Set (GHC.Types.Int))
+-> (Data.Set.Base.Set (GHC.Types.Int)) -> (GHC.Types.Bool)prop_cap_comm (Data.Set.Base.Set (GHC.Types.Int))x (Data.Set.Base.Set (GHC.Types.Int))y 
+147:   = {VV : (GHC.Types.Bool) | (? Prop([VV]))}
+-> {VV : (GHC.Types.Bool) | (? Prop([VV]))}boolAssert 
+148:   ({VV : (GHC.Types.Bool) | (? Prop([VV])),(VV != False)}
+ -> {VV : (GHC.Types.Bool) | (? Prop([VV])),(VV != False)})
+-> {VV : (GHC.Types.Bool) | (? Prop([VV])),(VV != False)}
+-> {VV : (GHC.Types.Bool) | (? Prop([VV])),(VV != False)}$ (GHC.Types.Bool)({VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = x)}x xs:(Data.Set.Base.Set (GHC.Types.Int))
+-> ys:(Data.Set.Base.Set (GHC.Types.Int))
+-> {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = Set_cap([xs;
+                                                              ys]))}`intersection` {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = y)}y) GHC.Classes.Eq (Data.Set.Base.Set GHC.Types.Int)== ({VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = y)}y xs:(Data.Set.Base.Set (GHC.Types.Int))
+-> ys:(Data.Set.Base.Set (GHC.Types.Int))
+-> {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = Set_cap([xs;
+                                                              ys]))}`intersection` {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = x)}x)
+

+
+that `union` is associative ...
+
+
+
154: {-@ prop_cup_assoc :: Set Int -> Set Int -> Set Int -> Bool @-}
+155: prop_cup_assoc     :: Set Int -> Set Int -> Set Int -> Bool
+156: (Data.Set.Base.Set (GHC.Types.Int))
+-> (Data.Set.Base.Set (GHC.Types.Int))
+-> (Data.Set.Base.Set (GHC.Types.Int))
+-> (GHC.Types.Bool)prop_cup_assoc (Data.Set.Base.Set (GHC.Types.Int))x (Data.Set.Base.Set (GHC.Types.Int))y (Data.Set.Base.Set (GHC.Types.Int))z 
+157:   = {VV : (GHC.Types.Bool) | (? Prop([VV]))}
+-> {VV : (GHC.Types.Bool) | (? Prop([VV]))}boolAssert 
+158:   ({VV : (GHC.Types.Bool) | (? Prop([VV])),(VV != False)}
+ -> {VV : (GHC.Types.Bool) | (? Prop([VV])),(VV != False)})
+-> {VV : (GHC.Types.Bool) | (? Prop([VV])),(VV != False)}
+-> {VV : (GHC.Types.Bool) | (? Prop([VV])),(VV != False)}$ (GHC.Types.Bool)({VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = x)}x xs:(Data.Set.Base.Set (GHC.Types.Int))
+-> ys:(Data.Set.Base.Set (GHC.Types.Int))
+-> {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = Set_cup([xs;
+                                                              ys]))}`union` ({VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = y)}y xs:(Data.Set.Base.Set (GHC.Types.Int))
+-> ys:(Data.Set.Base.Set (GHC.Types.Int))
+-> {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = Set_cup([xs;
+                                                              ys]))}`union` {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = z)}z)) x:(Data.Set.Base.Set (GHC.Types.Int))
+-> y:(Data.Set.Base.Set (GHC.Types.Int))
+-> {VV : (GHC.Types.Bool) | ((? Prop([VV])) <=> (x = y))}== (Data.Set.Base.Set (GHC.Types.Int))({VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = x)}x xs:(Data.Set.Base.Set (GHC.Types.Int))
+-> ys:(Data.Set.Base.Set (GHC.Types.Int))
+-> {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = Set_cup([xs;
+                                                              ys]))}`union` {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = y)}y) xs:(Data.Set.Base.Set (GHC.Types.Int))
+-> ys:(Data.Set.Base.Set (GHC.Types.Int))
+-> {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = Set_cup([xs;
+                                                              ys]))}`union` {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = z)}z
+

+
+and that `union` distributes over `intersection`.
+
+
+
164: {-@ prop_cap_dist :: Set Int -> Set Int -> Set Int -> Bool @-}
+165: prop_cap_dist     :: Set Int -> Set Int -> Set Int -> Bool
+166: (Data.Set.Base.Set (GHC.Types.Int))
+-> (Data.Set.Base.Set (GHC.Types.Int))
+-> (Data.Set.Base.Set (GHC.Types.Int))
+-> (GHC.Types.Bool)prop_cap_dist (Data.Set.Base.Set (GHC.Types.Int))x (Data.Set.Base.Set (GHC.Types.Int))y (Data.Set.Base.Set (GHC.Types.Int))z 
+167:   = {VV : (GHC.Types.Bool) | (? Prop([VV]))}
+-> {VV : (GHC.Types.Bool) | (? Prop([VV]))}boolAssert 
+168:   ({VV : (GHC.Types.Bool) | (? Prop([VV])),(VV != False)}
+ -> {VV : (GHC.Types.Bool) | (? Prop([VV])),(VV != False)})
+-> {VV : (GHC.Types.Bool) | (? Prop([VV])),(VV != False)}
+-> {VV : (GHC.Types.Bool) | (? Prop([VV])),(VV != False)}$  ({VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = x)}x xs:(Data.Set.Base.Set (GHC.Types.Int))
+-> ys:(Data.Set.Base.Set (GHC.Types.Int))
+-> {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = Set_cap([xs;
+                                                              ys]))}`intersection` ({VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = y)}y xs:(Data.Set.Base.Set (GHC.Types.Int))
+-> ys:(Data.Set.Base.Set (GHC.Types.Int))
+-> {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = Set_cup([xs;
+                                                              ys]))}`union` {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = z)}z)) 
+169:   x:(Data.Set.Base.Set (GHC.Types.Int))
+-> y:(Data.Set.Base.Set (GHC.Types.Int))
+-> {VV : (GHC.Types.Bool) | ((? Prop([VV])) <=> (x = y))}== (Data.Set.Base.Set (GHC.Types.Int))({VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = x)}x xs:(Data.Set.Base.Set (GHC.Types.Int))
+-> ys:(Data.Set.Base.Set (GHC.Types.Int))
+-> {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = Set_cap([xs;
+                                                              ys]))}`intersection` {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = y)}y) xs:(Data.Set.Base.Set (GHC.Types.Int))
+-> ys:(Data.Set.Base.Set (GHC.Types.Int))
+-> {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = Set_cup([xs;
+                                                              ys]))}`union` ({VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = x)}x xs:(Data.Set.Base.Set (GHC.Types.Int))
+-> ys:(Data.Set.Base.Set (GHC.Types.Int))
+-> {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = Set_cap([xs;
+                                                              ys]))}`intersection` {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = z)}z) 
+

+  
+Of course, while we're at it, lets make sure LiquidHaskell 
+doesn't prove anything thats *not* true ...
+
+
+
176: {-@ prop_cup_dif_bad :: Set Int -> Set Int -> Bool @-}
+177: prop_cup_dif_bad     :: Set Int -> Set Int -> Bool
+178: (Data.Set.Base.Set (GHC.Types.Int))
+-> (Data.Set.Base.Set (GHC.Types.Int)) -> (GHC.Types.Bool)prop_cup_dif_bad (Data.Set.Base.Set (GHC.Types.Int))x (Data.Set.Base.Set (GHC.Types.Int))y
+179:    = {VV : (GHC.Types.Bool) | (? Prop([VV]))}
+-> {VV : (GHC.Types.Bool) | (? Prop([VV]))}boolAssert 
+180:    ((GHC.Types.Bool)
+ -> {VV : (GHC.Types.Bool) | (? Prop([VV])),(VV != False)})
+-> (GHC.Types.Bool)
+-> {VV : (GHC.Types.Bool) | (? Prop([VV])),(VV != False)}$ {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = x)}x x:(Data.Set.Base.Set (GHC.Types.Int))
+-> y:(Data.Set.Base.Set (GHC.Types.Int))
+-> {VV : (GHC.Types.Bool) | ((? Prop([VV])) <=> (x = y))}== (Data.Set.Base.Set (GHC.Types.Int))({VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = x)}x xs:(Data.Set.Base.Set (GHC.Types.Int))
+-> ys:(Data.Set.Base.Set (GHC.Types.Int))
+-> {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = Set_cup([xs;
+                                                              ys]))}`union` {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = y)}y) xs:(Data.Set.Base.Set (GHC.Types.Int))
+-> ys:(Data.Set.Base.Set (GHC.Types.Int))
+-> {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = Set_dif([xs;
+                                                              ys]))}`difference` {VV : (Data.Set.Base.Set (GHC.Types.Int)) | (VV = y)}y
+

+
+Hmm. You do know why the above doesn't hold, right? It would be nice to
+get a *counterexample* wouldn't it. Well, for the moment, there is
+QuickCheck!
+
+Thus, the refined types offer a nice interface for interacting with the SMT
+solver in order to prove theorems in LiquidHaskell. (BTW, The [SBV project][sbv]
+describes another approach for using SMT solvers from Haskell, without the 
+indirection of refinement types.)
+
+While the above is a nice warm up exercise to understanding how
+LiquidHaskell reasons about sets, our overall goal is not to prove 
+theorems about set operators, but instead to specify and verify 
+properties of programs. 
+
+
+The Set of Values in a List
+===========================
+
+Lets see how we might reason about sets of values in regular Haskell programs. 
+
+Lets begin with Lists, the jack-of-all-data-types. Now, instead of just
+talking about the **number of** elements in a list, we can write a measure
+that describes the **set of** elements in a list:
+
+ A measure for the elements of a list, from [Data/Set.spec][setspec]
+
208: 
+209: measure listElts :: [a] -> (Set a) 
+210: listElts ([])    = {v | (? Set_emp(v))}
+211: listElts (x:xs)  = {v | v = (Set_cup (Set_sng x) (listElts xs)) }
+

+
+That is, `(elts xs)` describes the set of elements contained in a list `xs`.
+
+Next, to make the specifications concise, lets define a few predicate aliases:
+
+
+
219: {-@ predicate SameElts  X Y   = ((listElts X) = (listElts Y))                        @-}
+220: {-@ predicate SubElts   X Y   = (Set_sub (listElts X) (listElts Y))                   @-}
+221: {-@ predicate UnionElts X Y Z = ((listElts X) = (Set_cup (listElts Y) (listElts Z))) @-}
+

+
+A Trivial Identity
+------------------
+
+OK, now lets write some code to check that the `elts` measure is sensible!
+
+
+
230: {-@ listId    :: xs:[a] -> {v:[a]| (SameElts v xs)} @-}
+231: forall a.
+x1:[a]
+-> {VV : [a] | (len([VV]) = len([x1])),
+               (listElts([VV]) = Set_cup([listElts([x1]); listElts([x1])])),
+               (listElts([VV]) = listElts([x1])),
+               (listElts([x1]) = Set_cup([listElts([x1]); listElts([VV])])),
+               (len([VV]) >= 0)}listId []     = forall <p :: a -> a -> Bool>.
+{VV : [{VV : a | false}]<p> | (? Set_emp([listElts([VV])])),
+                              (len([VV]) = 0)}[]
+232: listId (x:xs) = {VV : a | (VV = x)}x forall <p :: a -> a -> Bool>.
+y:a
+-> ys:[a<p y>]<p>
+-> {VV : [a]<p> | (len([VV]) = (1 + len([ys]))),
+                  (listElts([VV]) = Set_cup([Set_sng([y]); listElts([ys])]))}: forall a.
+x1:[a]
+-> {VV : [a] | (len([VV]) = len([x1])),
+               (listElts([VV]) = Set_cup([listElts([x1]); listElts([x1])])),
+               (listElts([VV]) = listElts([x1])),
+               (listElts([x1]) = Set_cup([listElts([x1]); listElts([VV])])),
+               (len([VV]) >= 0)}listId {VV : [a] | (VV = xs),(len([VV]) >= 0)}xs
+

+
+That is, LiquidHaskell checks that the set of elements of the output list
+is the same as those in the input.
+
+A Less Trivial Identity
+-----------------------
+
+Next, lets write a function to `reverse` a list. Of course, we'd like to
+verify that `reverse` doesn't leave any elements behind; that is that the 
+output has the same set of values as the input list. This is somewhat more 
+interesting because of the *tail recursive* helper `go`. Do you understand 
+the type that is inferred for it? (Put your mouse over `go` to see the 
+inferred type.)
+
+
+
249: {-@ reverse       :: xs:[a] -> {v:[a]| (SameElts v xs)} @-}
+250: forall a. xs:[a] -> {VV : [a] | (listElts([VV]) = listElts([xs]))}reverse           = x1:{VV : [{VV : a | false}]<\_ VV -> false> | (len([VV]) = 0)}
+-> x2:[a]
+-> {VV : [a] | (listElts([VV]) = Set_cup([listElts([x1]);
+                                          listElts([x2])])),
+               (listElts([VV]) = Set_cup([listElts([x2]); listElts([x1])])),
+               (len([VV]) >= 0)}go {VV : [{VV : a | false}]<\_ VV -> false> | (? Set_emp([listElts([VV])])),
+                                           (len([VV]) = 0),
+                                           (len([VV]) >= 0)}[] 
+251:   where 
+252:     acc:{VV : [a] | (len([VV]) >= 0)}
+-> x1:[a]
+-> {VV : [a] | (listElts([VV]) = Set_cup([listElts([acc]);
+                                          listElts([x1])])),
+               (listElts([VV]) = Set_cup([listElts([x1]); listElts([acc])])),
+               (len([VV]) >= 0)}go {VV : [a] | (len([VV]) >= 0)}acc []     = {VV : [a] | (VV = acc),(len([VV]) >= 0)}acc
+253:     go acc (y:ys) = acc:{VV : [a] | (len([VV]) >= 0)}
+-> x1:[a]
+-> {VV : [a] | (listElts([VV]) = Set_cup([listElts([acc]);
+                                          listElts([x1])])),
+               (listElts([VV]) = Set_cup([listElts([x1]); listElts([acc])])),
+               (len([VV]) >= 0)}go ({VV : a | (VV = y)}yforall <p :: a -> a -> Bool>.
+y:a
+-> ys:[a<p y>]<p>
+-> {VV : [a]<p> | (len([VV]) = (1 + len([ys]))),
+                  (listElts([VV]) = Set_cup([Set_sng([y]); listElts([ys])]))}:{VV : [a] | (VV = acc),(len([VV]) >= 0)}acc) {VV : [a] | (VV = ys),(len([VV]) >= 0)}ys
+

+
+Appending Lists
+---------------
+
+Next, here's good old `append`, but now with a specification that states
+that the output indeed includes the elements from both the input lists.
+
+
+
263: {-@ append       :: xs:[a] -> ys:[a] -> {v:[a] | (UnionElts v xs ys) } @-}
+264: forall a.
+x1:[a]
+-> ys:[a]
+-> {VV : [a] | (listElts([VV]) = Set_cup([listElts([x1]);
+                                          listElts([ys])])),
+               (listElts([VV]) = Set_cup([listElts([ys]); listElts([x1])])),
+               (len([VV]) >= 0)}append []     [a]ys = {VV : [a] | (VV = ys),(len([VV]) >= 0)}ys
+265: append (x:xs) ys = {VV : a | (VV = x)}x forall <p :: a -> a -> Bool>.
+y:a
+-> ys:[a<p y>]<p>
+-> {VV : [a]<p> | (len([VV]) = (1 + len([ys]))),
+                  (listElts([VV]) = Set_cup([Set_sng([y]); listElts([ys])]))}: forall a.
+x1:[a]
+-> ys:[a]
+-> {VV : [a] | (listElts([VV]) = Set_cup([listElts([x1]);
+                                          listElts([ys])])),
+               (listElts([VV]) = Set_cup([listElts([ys]); listElts([x1])])),
+               (len([VV]) >= 0)}append {VV : [a] | (VV = xs),(len([VV]) >= 0)}xs {VV : [a] | (VV = ys),(len([VV]) >= 0)}ys
+

+
+Filtering Lists
+---------------
+
+Lets round off the list trilogy, with `filter`. Here, we can verify
+that it returns a **subset of** the values of the input list.
+
+
+
275: {-@ filter      :: (a -> Bool) -> xs:[a] -> {v:[a]| (SubElts v xs)} @-}
+276: 
+277: forall a.
+(a -> (GHC.Types.Bool))
+-> x2:[a]
+-> {VV : [a] | (? Set_sub([listElts([VV]); listElts([x2])])),
+               (listElts([x2]) = Set_cup([listElts([x2]); listElts([VV])])),
+               (len([VV]) >= 0)}filter a -> (GHC.Types.Bool)f []     = forall <p :: a -> a -> Bool>.
+{VV : [{VV : a | false}]<p> | (? Set_emp([listElts([VV])])),
+                              (len([VV]) = 0)}[]
+278: filter f (x:xs) 
+279:   | a -> (GHC.Types.Bool)f {VV : a | (VV = x)}x         = {VV : a | (VV = x)}x forall <p :: a -> a -> Bool>.
+y:a
+-> ys:[a<p y>]<p>
+-> {VV : [a]<p> | (len([VV]) = (1 + len([ys]))),
+                  (listElts([VV]) = Set_cup([Set_sng([y]); listElts([ys])]))}: forall a.
+(a -> (GHC.Types.Bool))
+-> x2:[a]
+-> {VV : [a] | (? Set_sub([listElts([VV]); listElts([x2])])),
+               (listElts([x2]) = Set_cup([listElts([x2]); listElts([VV])])),
+               (len([VV]) >= 0)}filter a -> (GHC.Types.Bool)f {VV : [a] | (VV = xs),(len([VV]) >= 0)}xs 
+280:   | otherwise   = forall a.
+(a -> (GHC.Types.Bool))
+-> x2:[a]
+-> {VV : [a] | (? Set_sub([listElts([VV]); listElts([x2])])),
+               (listElts([x2]) = Set_cup([listElts([x2]); listElts([VV])])),
+               (len([VV]) >= 0)}filter a -> (GHC.Types.Bool)f {VV : [a] | (VV = xs),(len([VV]) >= 0)}xs
+

+
+Merge Sort
+==========
+
+Lets conclude this entry with one larger example: `mergeSort`. 
+We'd like to verify that, well, the list that is returned 
+contains the same set of elements as the input list. 
+
+And so we will!
+
+But first, lets remind ourselves of how `mergeSort` works
+
+1. `split` the input list into two halves, 
+2. `sort`  each half, recursively, 
+3. `merge` the sorted halves to obtain the sorted list.
+
+
+Split
+-----
+
+We can `split` a list into two, roughly equal parts like so:
+
+
+
305: forall a.
+x1:[a]
+-> ({VV : [a] | (? Set_sub([listElts([VV]); listElts([x1])])),
+                (listElts([x1]) = Set_cup([listElts([x1]); listElts([VV])])),
+                (len([VV]) >= 0)} , {VV : [a] | (? Set_sub([listElts([VV]);
+                                                            listElts([x1])])),
+                                                (listElts([x1]) = Set_cup([listElts([x1]);
+                                                                           listElts([VV])])),
+                                                (len([VV]) >= 0)})<\x1 VV -> (? Set_sub([listElts([VV]);
+                                                                                         listElts([x1])])),
+                                                                             (listElts([x1]) = Set_cup([listElts([x1]);
+                                                                                                        listElts([VV])])),
+                                                                             (listElts([x1]) = Set_cup([listElts([x1]);
+                                                                                                        listElts([VV])])),
+                                                                             (len([VV]) >= 0)>split []     = forall a b <p2 :: a -> b -> Bool>. x1:a -> b<p2 x1> -> (a , b)<p2>({VV : [{VV : a | false}]<\_ VV -> false> | (? Set_emp([listElts([VV])])),
+                                           (len([VV]) = 0),
+                                           (len([VV]) >= 0)}[], {VV : [{VV : a | false}]<\_ VV -> false> | (? Set_emp([listElts([VV])])),
+                                           (len([VV]) = 0),
+                                           (len([VV]) >= 0)}[])
+306: split (x:xs) = forall a b <p2 :: a -> b -> Bool>. x1:a -> b<p2 x1> -> (a , b)<p2>({VV : a | (VV = x)}xforall <p :: a -> a -> Bool>.
+y:a
+-> ys:[a<p y>]<p>
+-> {VV : [a]<p> | (len([VV]) = (1 + len([ys]))),
+                  (listElts([VV]) = Set_cup([Set_sng([y]); listElts([ys])]))}:{VV : [a] | (? Set_sub([listElts([VV]); listElts([xs])])),
+            (VV = zs),
+            (VV = zs),
+            (len([VV]) = len([zs])),
+            (listElts([VV]) = Set_cup([listElts([zs]); listElts([zs])])),
+            (listElts([VV]) = listElts([zs])),
+            (listElts([xs]) = Set_cup([listElts([xs]); listElts([VV])])),
+            (listElts([xs]) = Set_cup([listElts([ys]); listElts([VV])])),
+            (listElts([xs]) = Set_cup([listElts([ys]); listElts([VV])])),
+            (listElts([zs]) = Set_cup([listElts([zs]); listElts([VV])])),
+            (len([VV]) >= 0)}zs, {VV : [a] | (? Set_sub([listElts([VV]); listElts([xs])])),
+            (VV = ys),
+            (VV = ys),
+            (len([VV]) = len([ys])),
+            (listElts([VV]) = Set_cup([listElts([ys]); listElts([ys])])),
+            (listElts([VV]) = listElts([ys])),
+            (listElts([xs]) = Set_cup([listElts([xs]); listElts([VV])])),
+            (listElts([xs]) = Set_cup([listElts([zs]); listElts([VV])])),
+            (listElts([ys]) = Set_cup([listElts([ys]); listElts([VV])])),
+            (len([VV]) >= 0)}ys)
+307:   where 
+308:     ({VV : [a] | (? Set_sub([listElts([VV]); listElts([xs])])),
+            (VV = ys),
+            (len([VV]) = len([ys])),
+            (listElts([VV]) = Set_cup([listElts([ys]); listElts([ys])])),
+            (listElts([VV]) = listElts([ys])),
+            (listElts([xs]) = Set_cup([listElts([xs]); listElts([VV])])),
+            (listElts([xs]) = Set_cup([listElts([zs]); listElts([VV])])),
+            (listElts([ys]) = Set_cup([listElts([ys]); listElts([VV])])),
+            (len([VV]) >= 0)}ys, {VV : [a] | (? Set_sub([listElts([VV]); listElts([xs])])),
+            (VV = zs),
+            (len([VV]) = len([zs])),
+            (listElts([VV]) = Set_cup([listElts([zs]); listElts([zs])])),
+            (listElts([VV]) = listElts([zs])),
+            (listElts([xs]) = Set_cup([listElts([xs]); listElts([VV])])),
+            (listElts([xs]) = Set_cup([listElts([ys]); listElts([VV])])),
+            (listElts([xs]) = Set_cup([listElts([ys]); listElts([VV])])),
+            (listElts([zs]) = Set_cup([listElts([zs]); listElts([VV])])),
+            (len([VV]) >= 0)}zs) = forall a.
+x1:[a]
+-> ({VV : [a] | (? Set_sub([listElts([VV]); listElts([x1])])),
+                (listElts([x1]) = Set_cup([listElts([x1]); listElts([VV])])),
+                (len([VV]) >= 0)} , {VV : [a] | (? Set_sub([listElts([VV]);
+                                                            listElts([x1])])),
+                                                (listElts([x1]) = Set_cup([listElts([x1]);
+                                                                           listElts([VV])])),
+                                                (len([VV]) >= 0)})<\x1 VV -> (? Set_sub([listElts([VV]);
+                                                                                         listElts([x1])])),
+                                                                             (listElts([x1]) = Set_cup([listElts([x1]);
+                                                                                                        listElts([VV])])),
+                                                                             (listElts([x1]) = Set_cup([listElts([x1]);
+                                                                                                        listElts([VV])])),
+                                                                             (len([VV]) >= 0)>split {VV : [a] | (VV = xs),(len([VV]) >= 0)}xs
+

+
+LiquidHaskell verifies that the relevant property of `split` is
+
+
+
314: {-@{\ys zs -> (UnionElts xs ys zs)}> @-}
+

+
+The funny syntax with angle brackets simply says that the output is a 
+a *pair* `(ys, zs)` whose union is the list of elements of the input.
+
+(**Aside** yes, this is indeed a dependent tuple; we will revisit tuples
+later to understand whats going on with the odd syntax.)
+
+Merge
+-----
+
+Dually, we `merge` two (sorted) lists like so:
+
+
+
329: forall a.
+(GHC.Classes.Ord a) =>
+xs:[a]
+-> x1:[a]
+-> {VV : [a] | (listElts([VV]) = Set_cup([listElts([x1]);
+                                          listElts([xs])])),
+               (listElts([VV]) = Set_cup([listElts([xs]); listElts([x1])])),
+               (len([VV]) >= 0)}merge [a]xs []         = {VV : [a] | (VV = xs),(len([VV]) >= 0)}xs
+330: merge [] ys         = {VV : [a] | (len([VV]) >= 0)}ys
+331: merge (x:xs) (yozz:ys) 
+332:   | {VV : a | (VV = x)}x x:a
+-> y:a -> {VV : (GHC.Types.Bool) | ((? Prop([VV])) <=> (x <= y))}<= {VV : a | (VV = yozz)}yozz       = {VV : a | (VV = x)}x forall <p :: a -> a -> Bool>.
+y:a
+-> ys:[a<p y>]<p>
+-> {VV : [a]<p> | (len([VV]) = (1 + len([ys]))),
+                  (listElts([VV]) = Set_cup([Set_sng([y]); listElts([ys])]))}: forall a.
+(GHC.Classes.Ord a) =>
+xs:[a]
+-> x1:[a]
+-> {VV : [a] | (listElts([VV]) = Set_cup([listElts([x1]);
+                                          listElts([xs])])),
+               (listElts([VV]) = Set_cup([listElts([xs]); listElts([x1])])),
+               (len([VV]) >= 0)}merge {VV : [a] | (VV = xs),(len([VV]) >= 0)}xs ({VV : a | (VV = yozz)}yozzforall <p :: a -> a -> Bool>.
+y:a
+-> ys:[a<p y>]<p>
+-> {VV : [a]<p> | (len([VV]) = (1 + len([ys]))),
+                  (listElts([VV]) = Set_cup([Set_sng([y]); listElts([ys])]))}:{VV : [a] | (VV = ys),(len([VV]) >= 0)}ys)
+333:   | otherwise       = {VV : a | (VV = yozz)}yozz forall <p :: a -> a -> Bool>.
+y:a
+-> ys:[a<p y>]<p>
+-> {VV : [a]<p> | (len([VV]) = (1 + len([ys]))),
+                  (listElts([VV]) = Set_cup([Set_sng([y]); listElts([ys])]))}: forall a.
+(GHC.Classes.Ord a) =>
+xs:[a]
+-> x1:[a]
+-> {VV : [a] | (listElts([VV]) = Set_cup([listElts([x1]);
+                                          listElts([xs])])),
+               (listElts([VV]) = Set_cup([listElts([xs]); listElts([x1])])),
+               (len([VV]) >= 0)}merge ({VV : a | (VV = x)}xforall <p :: a -> a -> Bool>.
+y:a
+-> ys:[a<p y>]<p>
+-> {VV : [a]<p> | (len([VV]) = (1 + len([ys]))),
+                  (listElts([VV]) = Set_cup([Set_sng([y]); listElts([ys])]))}:{VV : [a] | (VV = xs),(len([VV]) >= 0)}xs) {VV : [a] | (VV = ys),(len([VV]) >= 0)}ys
+

+
+As you might expect, the elements of the returned list are the union of the
+elements of the input, or as LiquidHaskell might say,
+
+
+
340: {-@ merge :: (Ord a) => x:[a] -> y:[a] -> {v:[a] | (UnionElts v x y)} @-}
+

+
+Sort
+----
+
+Finally, we put all the pieces together by
+
+
+
349: {-@ mergeSort :: (Ord a) => xs:[a] -> {v:[a] | (SameElts v xs)} @-}
+350: forall a.
+(GHC.Classes.Ord a) =>
+x1:[a]
+-> {VV : [a] | (listElts([VV]) = Set_cup([listElts([x1]);
+                                          listElts([x1])])),
+               (listElts([VV]) = listElts([x1])),
+               (listElts([x1]) = Set_cup([listElts([x1]); listElts([VV])]))}mergeSort []  = forall <p :: a -> a -> Bool>.
+{VV : [{VV : a | false}]<p> | (? Set_emp([listElts([VV])])),
+                              (len([VV]) = 0)}[]
+351: mergeSort [x] = {VV : [{VV : a | false}]<\_ VV -> false> | (? Set_emp([listElts([VV])])),
+                                           (len([VV]) = 0),
+                                           (len([VV]) >= 0)}[{VV : a | (VV = x)}x]
+352: mergeSort xs  = x:[a]
+-> y:[a]
+-> {VV : [a] | (listElts([VV]) = Set_cup([listElts([x]);
+                                          listElts([y])]))}merge (forall a.
+(GHC.Classes.Ord a) =>
+x1:[a]
+-> {VV : [a] | (listElts([VV]) = Set_cup([listElts([x1]);
+                                          listElts([x1])])),
+               (listElts([VV]) = listElts([x1])),
+               (listElts([x1]) = Set_cup([listElts([x1]); listElts([VV])]))}mergeSort {VV : [a] | (VV = ys),
+            (VV = ys),
+            (len([VV]) = len([ys])),
+            (listElts([VV]) = Set_cup([listElts([ys]); listElts([ys])])),
+            (listElts([VV]) = listElts([ys])),
+            (listElts([ys]) = Set_cup([listElts([ys]); listElts([VV])])),
+            (len([VV]) >= 0)}ys) (forall a.
+(GHC.Classes.Ord a) =>
+x1:[a]
+-> {VV : [a] | (listElts([VV]) = Set_cup([listElts([x1]);
+                                          listElts([x1])])),
+               (listElts([VV]) = listElts([x1])),
+               (listElts([x1]) = Set_cup([listElts([x1]); listElts([VV])]))}mergeSort {VV : [a] | (VV = zs),
+            (VV = zs),
+            (len([VV]) = len([zs])),
+            (listElts([VV]) = Set_cup([listElts([zs]); listElts([zs])])),
+            (listElts([VV]) = listElts([zs])),
+            (listElts([zs]) = Set_cup([listElts([zs]); listElts([VV])])),
+            (len([VV]) >= 0)}zs) 
+353:   where 
+354:     ({VV : [a] | (VV = ys),
+            (len([VV]) = len([ys])),
+            (listElts([VV]) = Set_cup([listElts([ys]); listElts([ys])])),
+            (listElts([VV]) = listElts([ys])),
+            (listElts([ys]) = Set_cup([listElts([ys]); listElts([VV])])),
+            (len([VV]) >= 0)}ys, {VV : [a] | (VV = zs),
+            (len([VV]) = len([zs])),
+            (listElts([VV]) = Set_cup([listElts([zs]); listElts([zs])])),
+            (listElts([VV]) = listElts([zs])),
+            (listElts([zs]) = Set_cup([listElts([zs]); listElts([VV])])),
+            (len([VV]) >= 0)}zs)  = xs:[a]
+-> ([a] , [a])<\ys VV -> (listElts([xs]) = Set_cup([listElts([ys]);
+                                                    listElts([VV])]))>split {VV : [a] | (len([VV]) >= 0)}xs
+

+
+The type given to `mergeSort`guarantees that the set of elements in the 
+output list is indeed the same as in the input list. Of course, it says 
+nothing about whether the list is *actually sorted*. 
+
+Well, Rome wasn't built in a day...
+
+[sbv]:      https://github.com/LeventErkok/sbv
+[setspec]:  https://github.com/ucsd-progsys/liquidhaskell/blob/master/include/Data/Set.spec
+[mccarthy]: http://www-formal.stanford.edu/jmc/towards.ps
+[z3cal]:    http://research.microsoft.com/en-us/um/people/leonardo/fmcad09.pdf
diff --git a/docs/blog/todo/red-black-intro.lhs b/docs/blog/todo/red-black-intro.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/red-black-intro.lhs
@@ -0,0 +1,111 @@
+---
+layout: post
+title: "Composing Specifications: Red Black Trees" 
+date: 2014-04-05 16:12
+author: Ranjit Jhala
+published: false 
+comments: true
+external-url:
+categories: measures, abstract-refinements, red-black 
+---
+
+TODO: **Conjoining Specifications** lamport. 
+TODO: composing, and, for example, 
+TODO: red-black trees.
+
+[Red Black trees][RBTwiki] trees are a classic, cold-war era, 
+data structure used to efficiently represent sets, using trees
+whose nodes are labeled by the set's elements, and additionally, 
+are colored *red* or *black*. 
+
+The key to efficiency is that the the trees be *balanced*. 
+
+Of course, the easiest way to do this is to just add a *height* 
+label and check that the difference of heights at each node is 
+bounded (cf. [AVL trees][AVLTwiki]). But, back in the olden 
+days, every bit counted -- the super cunning thing about 
+Red-Black Trees is that they ensure balancedness, at the 
+throwaway price of a *single bit* per node.
+
+The catch is that the invariants are devilishly tricky.
+
+
+
+1. **Order:** Each node's value is between those in its left and right subtrees,
+2. **Color:** Each red node's children are colored black,
+3. **Height:** Each root-to-leaf path has the same number of black nodes.
+
+There are ways to encode various subsets of these using 
+GADTs and such, but, like [Appel][RBTappel], I find the 
+encodings rather too clever as they require a variety 
+of different types and constructors to capture each 
+invariant. 
+
+One advantage of refinements is we fix the data type, 
+and can then *pick and choose* which invariants we want
+to verify, and *compose* them, quite trivially, via
+conjunction.
+
+Red Black Trees
+---------------
+
+Lets start with the basic type describing trees.
+
+\begin{code}
+data RBTree a = Leaf 
+              | Node Color a !(RBTree a) !(RBTree a)
+              deriving (Show)
+\end{code}
+
+A tree is either a `Leaf` (an empty set) or a `Node c x l r` where:
+
+* `x` is the value at the node, 
+* `l` and `r` are the left and right subtrees, and
+* `c` is either `B` (black) or `R` (red). 
+
+\begin{code}
+data Color    = B -- ^ Black
+              | R -- ^ Red
+              deriving (Eq,Show)
+\end{code}
+
+Intuitively, the set denoted by a tree is the set of values at 
+the nodes of the tree.
+
+Over the next few posts, we will develop an implementation 
+([based off this][coqRBT]) of a set library using the `RBTree` 
+datatype. In particular, we will implement the API:
+
+\begin{code} 

+empty  :: RBTree a
+member :: a -> RBTree a -> Bool
+insert :: a -> RBTree a -> RBTree a
+delete :: a -> RBTree a -> RBTree a
+toList :: RBTree a -> [a] 
+\end{code}
+
+and will use LiquidHaskell to *directly* and *compositionally* 
+specify and enforce the various invariants.
+
+Continue to:
+
+* [Order][rbtOrder]
+
+Coming soon:
+
+* Color
+* Height
+* Compose
+
+[rbtOrder]   : /blog/2014/04/07/red-black-order.lhs/ 
+
+
diff --git a/docs/blog/todo/red-black-order.lhs b/docs/blog/todo/red-black-order.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/red-black-order.lhs
@@ -0,0 +1,254 @@
+---
+layout: post
+title: "Red-Black Trees: Order"
+date: 2014-04-05 16:12
+author: Ranjit Jhala
+published: false 
+comments: true
+external-url:
+categories: measures, abstract-refinements 
+demo: RBTree-ord.hs
+---
+
+A data structure that implements a *set* interface, must 
+provide an efficient way to determine *membership*, i.e. 
+a function 
+
+\begin{code}
+member :: a -> RBTree a -> Bool
+\end{code}
+
+where `elem x xs` returns `True` iff `x` is in the set denoted by `xs`.
+
+Red Black trees are use 
+
+To enable effici
+
+Abstract Refinements vs. Indices
+--------------------------------
+
+Most formal accounts of Red Black trees eschew the order 
+invariant as it is rather cumbersome to encode using GADTs
+and indexed-types -- one must index the structure with lower
+and upper bounds, and appropriately adjust these bounds at 
+rotations. 
+
+
+TODO: **Conjoining Specifications** lamport. 
+TODO: composing, and, for example, 
+TODO: red-black trees.
+
+[Red Black trees][RBTwiki] trees are a classic, cold-war era, 
+data structure used to efficiently represent sets, using trees
+whose nodes are labeled by the set's elements, and additionally, 
+are colored *red* or *black*. 
+
+The key to efficiency is that the the trees be *balanced*. 
+
+Of course, the easiest way to do this is to just add a *height* 
+label and check that the difference of heights at each node is 
+bounded (cf. [AVL trees][AVLTwiki]). But, back in the olden 
+days, every bit counted -- the super cunning thing about 
+Red-Black Trees is that they ensure balancedness, at the 
+throwaway price of a *single bit* per node.
+
+The catch is that the invariants are devilishly tricky.
+
+
+
+1. **Order:** Each node's value is between those in its left and right subtrees,
+2. **Color:** Each red node's children are colored black,
+3. **Height:** Each root-to-leaf path has the same number of black nodes.
+
+There are ways to encode various subsets of these using 
+GADTs and such, but, like [Appel][RBTappel], I find the 
+encodings rather too clever as they require a variety 
+of different types and constructors to capture each 
+invariant. 
+
+One advantage of refinements is we fix the data type, 
+and can then *pick and choose* which invariants we want
+to verify, and *compose* them, quite trivially, via
+conjunction.
+
+Continue to:
+
+* [Order][rbtOrder]
+* [Color][rbtColor]
+* [Height][rbtHeight]
+* [Composition][rbtAll]
+
+[rbtOrder]   : /blog/2014/04/07/red-black-order.lhs/ 
+[rbtColor]   : /blog/2014/04/14/red-black-color.lhs/ 
+[rbtHeight]  : /blog/2014/04/21/red-black-height.lhs/ 
+[rbtCompose] : /blog/2014/04/28/red-black-compose.lhs/
+
+
+Red-Black Trees
+---------------
+
+Abstract Refinements
+--------------------
+
+Ordered Trees
+-------------
+
+
+Over the next several posts, lets see how to develop an
+RBTree library, using LiquidHaskell to directly and 
+compositionally specify and enforce the above invariants.
+
+
+
+
+
+ADD
+
+\begin{code}
+data Color    = B -- ^ Black
+              | R -- ^ Red
+              deriving (Eq,Show)
+\end{code}
+
+\begin{code}
+data RBTree a = Leaf 
+              | Node Color a !(RBTree a) !(RBTree a)
+              deriving (Show)
+\end{code}
+
+---------------------------------------------------------------------------
+-- | Add an element -------------------------------------------------------
+---------------------------------------------------------------------------
+
+{-@ add :: (Ord a) => a -> ORBT a -> ORBT a @-}
+add x s = makeBlack (ins x s)
+
+{-@ ins :: (Ord a) => a -> ORBT a -> ORBT a @-}
+ins kx Leaf             = Node R kx Leaf Leaf
+ins kx s@(Node B x l r) = case compare kx x of
+                            LT -> let t = lbal x (ins kx l) r in t 
+                            GT -> let t = rbal x l (ins kx r) in t 
+                            EQ -> s
+ins kx s@(Node R x l r) = case compare kx x of
+                            LT -> Node R x (ins kx l) r
+                            GT -> Node R x l (ins kx r)
+                            EQ -> s
+
+---------------------------------------------------------------------------
+-- | Delete an element ----------------------------------------------------
+---------------------------------------------------------------------------
+
+{-@ remove :: (Ord a) => a -> ORBT a -> ORBT a @-}
+remove x t = makeBlack (del x t)
+
+{-@ del              :: (Ord a) => a -> ORBT a -> ORBT a @-}
+del x Leaf           = Leaf
+del x (Node _ y a b) = case compare x y of
+   EQ -> append y a b 
+   LT -> case a of
+           Leaf         -> Node R y Leaf b
+           Node B _ _ _ -> lbalS y (del x a) b
+           _            -> let t = Node R y (del x a) b in t 
+   GT -> case b of
+           Leaf         -> Node R y a Leaf 
+           Node B _ _ _ -> rbalS y a (del x b)
+           _            -> Node R y a (del x b)
+
+{-@ append  :: y:a -> ORBT {v:a | v < y} -> ORBT {v:a | y < v} -> ORBT a @-}
+append :: a -> RBTree a -> RBTree a -> RBTree a
+
+append _ Leaf r                               
+  = r
+
+append _ l Leaf                               
+  = l
+
+append piv (Node R lx ll lr) (Node R rx rl rr)  
+  = case append piv lr rl of 
+      Node R x lr' rl' -> Node R x (Node R lx ll lr') (Node R rx rl' rr)
+      lrl              -> Node R lx ll (Node R rx lrl rr)
+
+append piv (Node B lx ll lr) (Node B rx rl rr)  
+  = case append piv lr rl of 
+      Node R x lr' rl' -> Node R x (Node B lx ll lr') (Node B rx rl' rr)
+      lrl              -> lbalS lx ll (Node B rx lrl rr)
+
+append piv l@(Node B _ _ _) (Node R rx rl rr)   
+  = Node R rx (append piv l rl) rr
+
+append piv l@(Node R lx ll lr) r@(Node B _ _ _) 
+  = Node R lx ll (append piv lr r)
+
+---------------------------------------------------------------------------
+-- | Delete Minimum Element -----------------------------------------------
+---------------------------------------------------------------------------
+
+{-@ deleteMin  :: ORBT a -> ORBT a @-}
+deleteMin (Leaf)         = Leaf
+deleteMin (Node _ x l r) = makeBlack t
+  where 
+    (_, t)               = deleteMin' x l r
+
+
+{-@ deleteMin' :: k:a -> ORBT {v:a | v < k} -> ORBT {v:a | k < v} -> (a, ORBT a) @-}
+deleteMin' k Leaf r              = (k, r)
+deleteMin' x (Node R lx ll lr) r = (k, Node R x l' r)   where (k, l') = deleteMin' lx ll lr 
+deleteMin' x (Node B lx ll lr) r = (k, lbalS x l' r )   where (k, l') = deleteMin' lx ll lr 
+
+---------------------------------------------------------------------------
+-- | Rotations ------------------------------------------------------------
+---------------------------------------------------------------------------
+
+lbalS k (Node R x a b) r              = Node R k (Node B x a b) r
+lbalS k l (Node B y a b)              = let t = rbal k l (Node R y a b) in t 
+lbalS k l (Node R z (Node B y a b) c) = Node R y (Node B k l a) (rbal z b (makeRed c))
+lbalS k l r                           = error "nein" 
+
+rbalS k l (Node R y b c)              = Node R k l (Node B y b c)
+rbalS k (Node B x a b) r              = let t = lbal k (Node R x a b) r in t 
+rbalS k (Node R x a (Node B y b c)) r = Node R y (lbal x (makeRed a) b) (Node B k c r)
+rbalS k l r                           = error "nein"
+
+lbal k (Node R y (Node R x a b) c) r  = Node R y (Node B x a b) (Node B k c r)
+lbal k (Node R x a (Node R y b c)) r  = Node R y (Node B x a b) (Node B k c r)
+lbal k l r                            = Node B k l r
+
+rbal x a (Node R y b (Node R z c d))  = Node R y (Node B x a b) (Node B z c d)
+rbal x a (Node R z (Node R y b c) d)  = Node R y (Node B x a b) (Node B z c d)
+rbal x l r                            = Node B x l r
+
+---------------------------------------------------------------------------
+---------------------------------------------------------------------------
+---------------------------------------------------------------------------
+
+makeRed (Node _ x l r)   = Node R x l r
+makeRed Leaf             = error "nein" 
+
+makeBlack Leaf           = Leaf
+makeBlack (Node _ x l r) = Node B x l r
+
+---------------------------------------------------------------------------
+-- | Specifications -------------------------------------------------------
+---------------------------------------------------------------------------
+
+-- | Ordered Red-Black Trees
+
+{-@ type ORBT a = RBTree <{\root v -> v < root }, {\root v -> v > root}> a @-}
+
+-- | Binary Search Ordering
+
+{-@ data RBTree a  a -> Prop, r :: a -> a -> Prop>
+            = Leaf
+            | Node (c    :: Color)
+                   (key  :: a)
+                   (left :: RBTree  (a ))
+                   (left :: RBTree  (a ))
+  @-}
diff --git a/docs/blog/todo/telling-lies-old.lhs b/docs/blog/todo/telling-lies-old.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/telling-lies-old.lhs
@@ -0,0 +1,122 @@
+---
+layout: post
+title: "LiquidHaskell Caught Telling Lies!"
+date: 2013-11-19 16:12
+comments: true
+external-url:
+categories: termination
+author: Niki Vazou
+published: false
+demo: TellingLies.hs
+---
+
+If you used liquidHaskell lately, you may have noticed some type errors that
+just make no sense.
+Well, that is not a bug, but a ... **termination checker** failing to prove that
+your function terminates.
+
+LiquidHaskell, *by default*, performs a termination check while verifying your
+code.
+Of course the tool would be useless if it required all your functions
+to terminate.
+Instead, it just requires that non-terminating functions return unrefined
+results.
+We will shortly explain when and how one can turn off termination checking while preserve
+sound type checking.
+To do so, we should start by explaining why termination is requied. 
+
+
+
+\begin{code}
+module TellingLies where
+
+import Prelude  hiding (repeat)
+import Language.Haskell.Liquid.Prelude (liquidAssert)
+\end{code}
+
+Why is Termination Analysis Required
+-------------------------------------
+
+Consider a no-terminating function:
+
+\begin{code}
+{-@ foo :: Int -> {v:Int | false} @-}
+foo     :: Int -> Int
+foo n   = foo n
+\end{code}
+
+According to the *partial correctness property*
+the type signature for `foo` means that any
+value `foo` returns will satisfy the result refinement
+`false`. 
+Since `foo` never returns, 
+it can return *none* value, thus it trivially satisfies its
+type.
+
+Now, in an environment where `false` (i.e., `foo`'s result)
+exists, liquidHaskell can prove anything, 
+even the contradiction `0==1`:
+
+\begin{code}
+prop = liquidAssert ((\_ -> 0==1) (foo 0))
+\end{code}
+
+This is totally valid under *eager* evaluation, where
+to execute the assertion one should first compute the argument
+`foo 0` which never returns.
+But, it is not valid under haskell's *lazy* semantics
+where execution ignores the unused argument, and fails.
+
+From the above discussion we see that partial correctness is not enough to
+verify Haskell's lazy code.
+To restore soundness we require *total correctness*, or
+that each function terminates.
+This explains why termination checking is set as default to liquidHaskell (as is
+in many other verifiers, like Coq or Agda.)
+
+Turning off Termination Checking
+--------------------------------
+
+Of course, you cannot prove termination of functions like `repeat`
+
+\begin{code}
+{-@ repeat :: a -> [a] @-}
+repeat     :: a -> [a]
+repeat a   = a : repeat a
+\end{code}
+
+Instead, you can mark `repeat` as `Lazy` to disable termination for these
+functions:
+\begin{code}
+{-@ Lazy repeat @-}
+\end{code}
+
+But, be careful!
+By marking a function as `Lazy` *you* also guarantee that *the result type
+cannot contain inconsistencies*.
+In our previous example, liquidHaskell typechecked the unsafe `prop`, just
+because we marked `foo` (who's return type contains inconsistency) as `Lazy`
+\begin{code}
+{-@ Lazy foo @-}
+\end{code}
+
+Even though it is hard to decide if a type can contain inconsistencies,
+trivially *unrefined types* (or types refined to `true`) cannot ever be resolved
+to `false`.
+In other words, it is always safe to mark as `Lazy` functions with unrefined
+result.
+
+\begin{code}Finally, you have the option to totally disable termination checking, using the `no-termination` flag:
+{-@ LIQUID "--no-termination" @-}
+\end{code}
+
+
+Prevent liquidHaskell from Telling Lies
+---------------------------------------
+
+In this post, we saw why termination is required for sound type checking and when
+it is safe to deactivate it.
+But still, we didn't discuss how to prevent the tool from telling lies, i.e., how
+to actually prove termination.
+Turns out that liquidHaskell is powerful enough to prove
+termination on a great number of functions, but this is a topic of another post.
diff --git a/docs/blog/todo/termination.lhs b/docs/blog/todo/termination.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/termination.lhs
@@ -0,0 +1,288 @@
+---
+layout: post
+title: "Termination Checking"
+date: 2013-11-18 16:12
+comments: true
+external-url:
+categories: termination
+author: Niki Vazou
+published: false
+demo: Termination.hs
+---
+
+If you used liquidHaskell lately, you may have noticed some type errors that
+just make no sense.
+Well, that is not a bug, but a ... **termination checker** failing to prove that
+your function terminates.
+
+In this post, we present how you can use liquidHaskell to prove termination on
+simple recursive functions and explain why termination is required for sound
+type checking.
+Of course liquidHaskell would be useless if it required that all your functions
+do terminate.
+Instead, it just requires that non-terminating functions return unrefined
+results.
+We will shortly explain how one can turn off termination checking while preserve
+sound type checking.
+
+
+
+\begin{code}
+module Termination where
+
+import Prelude hiding (sum, (!!), repeat)
+import Data.List      (lookup)
+import Data.Maybe     (fromJust)
+
+import Language.Haskell.Liquid.Prelude (liquidAssert)
+\end{code}
+
+Termination Check with Refinement Types
+---------------------------------------
+
+Consider a `Vec`tor that maps `Int`egers to `Val`ues:
+
+\begin{code}
+type Val   = Int
+data Vec   = V [(Int, Val)]
+
+(!!)       :: Vec -> Int -> Val
+(V a) !! i = case i `lookup` a of {Just v -> v; _ -> 0}
+\end{code}
+
+Let `sum a i` add the `i` first elements of the vector `a`:
+
+\begin{code}
+sum     :: Vec -> Int -> Val
+sum a 0 = 0
+sum a i = (a !! (i-1)) + sum a (i-1)
+\end{code}
+
+Does `sum` terminate?
+We observe that if `i` is not `0` then `sum i` will call `sum (i-1)`, otherwise
+it will return.
+This reasoning suffices to convince ourselves that `sum i` terminates for every
+natural number `i`.
+Formally, we shown that `sum` terminates because a *well-founded metric* (i.e., the
+natural number `i`) is decreasing at each iteration.
+Thus, to ensure termination it suffices to restrict `i` on Natural numbers,
+which we can do with a liquid-type signature.
+\begin{code}
+{-@ sum :: Vec -> Nat -> Val @-}
+\end{code}
+
+LiquidHaskell will apply the same reasoning to prove `sum`
+terminates:
+Conventionally, to typecheck `sum` we would check the body assuming an
+environment
+
+`a:Vec`, `i:Nat`, `sum:Vec -> Nat -> Val`
+
+Instead, we *weaken* the environment to 
+
+`a:Vec`, `i:Nat`, `sum:Vec -> {v:Nat| v < i} -> Val`
+
+Now, the type of `sum` stipulates that it *only* be recursively called with
+`Nat` (so well-founded) values that are *strictly less than* the current parameter `i`. 
+Since its body typechecks in this environment, `sum` terminates for
+every `i` on `Nat`s.
+
+Choosing the correct argument
+-----------------------------
+
+We saw that liquidHaskell can happily check that a Natural number is decreasing
+at each iteration; but it uses a naïve heuristic to choose which one. 
+For this post we can assume that it always chooses *the first* Integer. 
+
+So, a tail-recursive implementation of `sum`:
+\begin{code}
+{-@ sum' :: Vec -> Val -> Nat -> Val @-}
+sum' :: Vec -> Val -> Int -> Val
+sum' a acc 0 = acc + a!!0 
+sum' a acc i = sum' a (acc + a!!i) (i-1)
+\end{code}
+
+will fail, as liquidHaskell wants to prove that the `acc`umulator is the `Nat`ural
+number that
+decreases at each iteration.
+
+\begin{code}The remedy is simple. We can direct liquidHaskell to the correct argument `i` using a `Decrease` annotation: 
+{-@ Decrease sum' 3 @-}
+\end{code}
+which directs liquidHaskell to check whether the *third*
+argument (i.e., `i`) is decreasing.
+With this hint, liquidHaskell will happily verify that `sum'` is indeed a
+terminating function.
+
+Lexicographic Termination
+-------------------------
+
+Lets complicate the things a little bit.
+To do so, lets compute the `sum` of a 2D `Vec`tor:
+
+\begin{code}
+data Vec2D    = V2D [((Int, Int), Val)]
+
+(!!!)         :: Vec2D -> (Int,Int) -> Val
+(V2D a) !!! i = case i `lookup` a of {Just v -> v; _ -> 0}
+\end{code}
+
+Now we write a `sum2D a n m` function that computes the sum of the first 
+`(n+1) (m+1)` elements of `a`
+
+\begin{code}
+{-@ sum2D :: Vec2D -> Nat -> Nat -> Val @-}
+sum2D :: Vec2D -> Int -> Int -> Val
+sum2D a n m = go n m
+  where 
+    {-@ Decrease go 1 2 @-}
+    go 0 0             = 0
+    go i j | j == 0    =  a!!!(i, 0) + go (i-1) m
+           | otherwise =  a!!!(i, j) + go i (j-1)
+\end{code}
+
+Here there is no decreasing argument, 
+if `j>0`, `j` decreases (line `139`), otherwise `i` decreases (line `138`).
+Though, liquidHaskell succeed in verifying that `sum2D` terminates and the reason
+is our `Decrease go 1 2` annotation.
+This annotation informs the tool that the decreasing measure is the
+*lexicographically ordered* pair `[i,j]`. 
+LiquidHaskell will verify that this pair is indeed decreasing: at each
+iteration either `i` decreases (line `138`) or `i` remains the same and `j`
+decreases (line `139`).
+
+\begin{code}An alternative annotation to express the above decreasing measure is:
+       {-@ go :: i:Nat -> j:Nat -> Val / [i, j] @-}
+\end{code}
+where after the type signature for `go` we write the list of lexicographic
+decreasing *expressions*.
+This mechanism, as we shall see, allows us to prove termination in functions
+where the decreasing measure in a *function* of the arguments.
+
+Decreasing expressions
+----------------------
+Back to our `1D` Vector, 
+we now define a function `sumFromTo a lo hi` that sums the elements form `a!!lo`
+to `a!!hi`:
+
+\begin{code}
+{-@ sumFromTo :: Vec -> lo:Nat -> hi:{v:Nat|v>=lo} -> Val @-}
+sumFromTo :: Vec -> Int -> Int ->  Val
+sumFromTo a lo hi = go lo hi
+  where 
+       {-@ go :: lo:Nat -> hi:{v:Nat|v>=lo} -> Val / [hi-lo] @-}
+        go lo hi | lo == hi  =  a!!lo
+                 | otherwise =  a!!lo + go (lo+1) hi
+\end{code}
+
+No argument is decreasing in this function, 
+but still it does terminate, as at each iteration `lo` is increased and
+execution will terminate when `lo` reaches `hi`.
+Here the decreasing measure is the expression `hi-lo`.
+LiquidHaskell has no way to generate such a measure, but,
+if the user generates it, i.e., by annotating `go`'s signature,
+liquidHaskell will happily check that `lo-hi` is indeed a well-founded measure (as it is
+a natural number) that decreases at each iteration.
+
+
+Powered with decreasing expressions and the `Decrease` hint,
+we can prove termination on a great number of functions 
+ranging from 
+ones defined on recursive data structures
+to mutual recursive ones. 
+Of course, we can never prove termination on non-terminating functions that
+naturally exist on haskell source code.
+So, we postpone 
+proving termination on more interesting functions
+and instead lets see how and when you can safely turn termination check off.
+
+Why is Termination Analysis Required
+-------------------------------------
+
+Consider a no-terminating function:
+
+\begin{code}
+{-@ foo :: Int -> {v:Int | false} @-}
+foo     :: Int -> Int
+foo n   = foo n
+\end{code}
+
+According to the *partial correctness property*
+the type signature for `foo` means that any
+value `foo` returns will satisfy the result refinement
+`false`. 
+Since `foo` never returns, 
+it can return *none* value, thus it trivially satisfies its
+type.
+
+Now, in an environment where `false` (i.e., `foo`'s result)
+exists, liquidHaskell can prove anything, 
+even the contradiction `0==1`:
+
+\begin{code}
+prop = liquidAssert ((\_ -> 0==1) (foo 0))
+\end{code}
+
+This is totally valid under *eager* evaluation, where
+to execute the assertion one should first compute the argument
+`foo 0` which never returns.
+But, it is not valid under haskell's *lazy* semantics
+where execution ignores the unused argument, and fails.
+
+From the above discussion we see that partial correctness is not enough to
+verify Haskell's lazy code.
+To restore soundness we require *total correctness*, or
+that each function terminates.
+This explains why termination checking is set as default to liquidHaskell (as is
+in many other verifiers, like Coq or Agda.)
+
+Turning off Termination Checking
+--------------------------------
+
+Of course, you cannot prove termination of functions like `repeat`
+
+\begin{code}
+{-@ repeat :: a -> [a] @-}
+repeat     :: a -> [a]
+repeat a   = a : repeat a
+\end{code}
+
+Instead, you can mark `repeat` as `Lazy` to disable termination for these
+functions:
+\begin{code}
+{-@ Lazy repeat @-}
+\end{code}
+
+But, be careful!
+By marking a function as `Lazy` *you* also guarantee that *the result type
+cannot contain inconsistencies*.
+In our previous example, liquidHaskell typechecked the unsafe `prop`, just
+because we marked `foo` (who's return type contains inconsistency) as `Lazy`
+\begin{code}
+{-@ Lazy foo @-}
+\end{code}
+
+Even though it is hard to decide if a type can contain inconsistencies,
+trivially *unrefined types* (or types refined to `true`) cannot ever be resolved
+to `false`.
+In other words, it is always safe to mark as `Lazy` functions with unrefined
+result.
+
+\begin{code} Finally, you have the option to totally disable termination checking, using the `no-termination` flag:
+{-@ LIQUID "--no-termination" @-}
+\end{code}
+
+Conclusion
+----------
+
+In this post, 
+
+- We saw how to use liquidHaskell to prove termination of simple recursive
+  functions, and
+
+- We learned why termination is required for sound type checking and when
+  it is safe to deactivate it.
+
+Termination checking may sound a big demand,
+but soon we will see that liquidHaskell is powerful enough to prove
+termination on a great number of functions
diff --git a/docs/blog/todo/text-layout.png b/docs/blog/todo/text-layout.png
new file mode 100644
Binary files /dev/null and b/docs/blog/todo/text-layout.png differ
diff --git a/docs/blog/todo/text-lifecycle.png b/docs/blog/todo/text-lifecycle.png
new file mode 100644
Binary files /dev/null and b/docs/blog/todo/text-lifecycle.png differ
diff --git a/docs/blog/todo/verifying-efficient-sorting-algorithms.lhs b/docs/blog/todo/verifying-efficient-sorting-algorithms.lhs
new file mode 100644
--- /dev/null
+++ b/docs/blog/todo/verifying-efficient-sorting-algorithms.lhs
@@ -0,0 +1,185 @@
+---
+layout: post
+title: "Verifing Efficient Sorting Algorithms"
+date: 2013-02-15 16:12
+comments: true
+external-url:
+categories: abstract-refinements
+author: Niki Vazou
+published: false
+---
+
+
+In this example, we will see how abstract refinements can be used to verify
+complex sorting algorithms, like the ones implemented in `Data.List`.
+
+\begin{code}
+module GhcSort (sort, sort1, sort2) where
+\end{code}
+
+Once again, we defined the type of sorted lists as:
+
+\begin{code}
+{-@ type SList a = [a]<{v: a | (v >= fld)}> @-}
+\end{code}
+
+and we aim to prove that all sorting functions return a list if this type.
+
+QuickSort
+---------
+
+Prelude used to implement the below variant of quicksort, as its sorting algorithm.
+
+First, we define `qsort`:
+\begin{code}
+qsort :: (Ord a) =>  a -> [a] -> [a] -> [a]
+qsort _ []     r = r
+qsort _ [x]    r = x:r
+qsort w (x:xs) r = qpart w x xs [] [] r
+\end{code}
+
+
+In `qsort w ys r`, `r` is a sorted list with values greater than `w` and `ys` is a non-sorted list with values lower or equal to `w`.
+If there is at most one element in `ys`, `qsort` returns the sorted list `ys++r`.
+Otherwise, `ys=(x:xs)`, and to short `ys`, `qsort` choses as _pivot element_ the `x` and calls `qpart`:
+
+\begin{code}
+qpart :: (Ord a) => a -> a -> [a] -> [a] -> [a] -> [a] -> [a]
+qpart w x [] rlt rge r =
+    -- rlt and rge are in reverse order and must be sorted with an
+    -- anti-stable sorting
+    rqsort x rlt (x:rqsort w rge r)
+qpart w x (y:ys) rlt rge r =
+    case compare x y of
+        GT -> qpart w x ys (y:rlt) rge r
+        _  -> qpart w x ys rlt (y:rge) r
+\end{code}
+
+In `qpart w x xs rlt rge r`, `r` is a sorted list with values greater than `w`, all other argument lists are not sorted and their values are less or equal to `w`. Moreover, `rge` (`rlt`) has values greater or equal (less) than the pivot element `x`.
+`qpart` splits `xs` values between `rlt` and `rge` and when there are no more values in `xs` it calls `qsort` on these two lists to recursively sort them.
+But, since `qpart` reverses the order of equal values, it actually calls `rqsort` that behaves similar to `qsort`, apart from reversing once more the order of equal values: 
+
+\begin{code}
+-- rqsort is as qsort but anti-stable, i.e. reverses equal elements
+rqsort :: (Ord a) => a -> [a] -> [a] -> [a]
+rqsort _ []     r = r
+rqsort _ [x]    r = x:r
+rqsort w (x:xs) r = rqpart w x xs [] [] r
+
+rqpart :: (Ord a) => a -> a -> [a] -> [a] -> [a] -> [a] -> [a]
+rqpart w x [] rle rgt r =
+    qsort x rle (x:qsort w rgt r)
+rqpart w x (y:ys) rle rgt r =
+    case compare y x of
+        GT -> rqpart w x ys rle (y:rgt) r
+        _  -> rqpart w x ys (y:rle) rgt r
+\end{code}
+
+Finally, to sort a list `ls` we have to call `qsort` with an empty initially sorted list. Also, we have to provide a `w` such that all elements in `ls` are less or equal to `w`. So, we have the sorting function:
+
+\begin{code}
+{-@ sort1 :: (Ord a) => w:a -> ls:[{v:a|v<=w}] -> SList a @-}
+sort1 :: (Ord a) => a -> [a] -> [a]
+sort1 w ls = qsort w ls []
+\end{code}
+
+We note that the `w` that appears in all functions is a ``ghost'' variable that we added so we can prove the correctness of the function. In other words, `w` is not actually used by the functions, but it is needed so that we can prove that always any value in the sorted list `r` is greater than any value in the other lists.
+
+
+
+Mergesort
+---------
+In 2002, Ian Lynagh proposed that GHC should use a sorting algorithm with nlogn worst case performance, so he proposed proposed the below mergesort function:
+
+
+\begin{code}
+mergesort :: (Ord a) => [a] -> [a]
+mergesort = mergesort' . map wrap
+
+mergesort' :: (Ord a) => [[a]] -> [a]
+mergesort' [] = []
+mergesort' [xs] = xs
+mergesort' xss = mergesort' (merge_pairs xss)
+
+merge_pairs :: (Ord a) => [[a]] -> [[a]]
+merge_pairs [] = []
+merge_pairs [xs] = [xs]
+merge_pairs (xs:ys:xss) = merge xs ys : merge_pairs xss
+
+merge :: (Ord a) => [a] -> [a] -> [a]
+merge [] ys = ys
+merge xs [] = xs
+merge (x:xs) (y:ys)
+ = case x `compare` y of
+        GT -> y : merge (x:xs)   ys
+        _  -> x : merge    xs (y:ys)
+
+wrap :: a -> [a]
+wrap x = [x]
+\end{code}
+
+This is a usual merge sort function: Initially each element of the list is wrapped in an one-element list. So, a list of sorted lists in constructed and applied to `mergesort'`. `mergesort'` is always called on list of sorted lists, so if its argument has zero or one elements it trivially returns a sorted list, otherwise it merges all consequtive pairs, with `merge_pairs`, and recursivelly calls itself. In the same way, `merge_pairs` either returns a trivially sorted list, or it merges two consequtive lists and recursivelly calls itself on the rest. Finally, two sorted lists are merged by `merge` in the expected way.
+
+
+Without any code modifications, our system can prove that all invariants are kept, and ultimately `mergesort` returns a sorted list:
+
+\begin{code}
+{-@ sort2 :: (Ord a) => [a] -> SList a @-}
+sort2 :: (Ord a) => [a] -> [a]
+sort2 = mergesort
+\end{code}
+
+
+Official GHC Sort
+-----------------
+In 2009 `mergesort` was replaced by the bellow function, which is similar to "A smooth applicative merge sort", as proposed in 1982 by Richard O'Keefe:
+
+First we define `descending a as bs`, that has the invariant tha all values in `as` are greater than `a` and returns a list whose first element is the greatest descending prefix list in `bs`, reversed. 
+
+\begin{code}
+descending a as (b:bs)
+  | a `compare` b == GT = descending b (a:as) bs
+descending a as bs      = (a:as): sequences bs
+\end{code}
+
+Then we define `ascending a as bs`, that has the invariant tha all arguments of `as` are greater than or equal to `a` and returns a list whose first element is the greatest ascending prefix list in `bs`. To avoid reversing this sublist, `as` is not a list, but a function that every time stores the beggining of the lists and expects its ending.
+
+\begin{code}  
+ascending a as (b:bs)
+  | a `compare` b /= GT = ascending b (\ys -> as (a:ys)) bs
+ascending a as bs       = as [a]: sequences bs
+\end{code}
+
+Since, an arbitrary list can be split in consecutive ascending or descending sublists we define the function `sequences ls` that recursively uses `ascending` and `descending` to split `ls` in these sublists.
+
+\begin{code}
+sequences (a:b:xs)
+  | a `compare` b == GT = descending b [a]  xs
+  | otherwise           = ascending  b (a:) xs
+sequences [x] = [[x]]
+sequences []  = [[]]
+\end{code}
+
+Then, we define a `mergeAll` function that merges sorted lists: 
+
+\begin{code}
+mergeAll [x] = x
+mergeAll xs  = mergeAll (mergePairs xs)
+
+mergePairs (a:b:xs) = merge a b: mergePairs xs
+mergePairs [x]      = [x]
+mergePairs []       = []
+\end{code}
+
+Finally, we define the sorting function that applies `mergeAll` to the result of `sequences` applied in the initial list.
+
+\begin{code}
+{-@ sort :: (Ord a) => [a] -> SList a @-}
+sort :: (Ord a) => [a] -> [a]
+sort = mergeAll . sequences
+\end{code}
+
+Our system can again prove that all the above invariants hold, and `sort` produces a sorted list.
+
+We have to note that the initial ghc functions take comparing function as an argument. But to prove sortedness, we have to transfer the information we get from comparison to the type system. So we actually modified all the above code, by inlining the `compare` function instead of passing it as an argument.
+
diff --git a/docs/language/Makefile b/docs/language/Makefile
new file mode 100644
--- /dev/null
+++ b/docs/language/Makefile
@@ -0,0 +1,55 @@
+TARGET= main
+
+TECH=main
+URL=nvazou@goto.ucsd.edu:~/public_html/lazytechreport.pdf
+
+STY = liquidHaskell.sty commands.sty
+TEX = main.tex language.tex typeInference.tex 
+BIB = sw.bib
+CLS = sigplanconf.cls
+SRCFILES = Makefile ${TEX} ${STY} ${CLS}
+
+
+all: ${TEX}
+	pdflatex main
+	bibtex main
+	pdflatex main
+	bibtex main
+	pdflatex main
+
+tech: ${SRCFILES}
+	cp $(SHOWPROOFS) $(PROOFCNF)
+	pdflatex ${TECH}
+	bibtex ${TECH}
+	pdflatex ${TECH}
+	bibtex ${TECH}
+	pdflatex ${TECH}
+	cp $(HIDEPROOFS) $(PROOFCNF)
+
+
+uploadtech: ${TECH}.pdf
+	scp ${TECH}.pdf ${URL}
+withproofs:
+	cp $(SHOWPROOFS) $(PROOFCNF)
+
+noproofs:
+	cp $(HIDEPROOFS) $(PROOFCNF)
+
+clean:
+	$(RM) *.log *.aux *.ps *.dvi *.bbl *.blg *.bak *.fdb_latexmk *.out *~ proofs/*.log
+
+reallyclean: clean
+	$(RM) *.ps *.pdf
+
+distclean: reallyclean
+
+pdfshow: $(TARGET).pdf
+	xpdf $(TARGET).pdf
+
+acroshow: $(TARGET).pdf
+	acroread $(TARGET).pdf
+
+pack: reallyclean
+	tar cvfz liquidHaskell_tex.tar.gz ${SRCFILES}
+
+PHONY : ps all clean reallyclean distclean
diff --git a/docs/language/commands.sty b/docs/language/commands.sty
new file mode 100644
--- /dev/null
+++ b/docs/language/commands.sty
@@ -0,0 +1,41 @@
+\usepackage[usenames,dvipsnames]{xcolor}
+
+%% \def\mynote#1{{\sf $\clubsuit$ #1$\clubsuit$}}
+%% \def\RJ#1{\textcolor{Red}{\sf RJ:$\clubsuit$ #1$\clubsuit$}}
+%% \def\NV#1{\textcolor{Plum}{\sf NV:$\clubsuit$ #1$\clubsuit$}}
+\def\NV#1{\textcolor{Green}{\sf NV:$\clubsuit$ #1$\clubsuit$}}
+%% \def\ES#1{\textcolor{Blue}{\sf ES:$\clubsuit$ #1$\clubsuit$}}
+
+
+\def\myex#1{\smallskip\noindent{\emphbf{Example: {#1}.}}}
+\newcommand\spara[1]{\smallskip\noindent\textbf{\emph{#1}}\xspace}
+\newcommand\mypara[1]{\spara{#1}}
+%\def\mypara#1{\smallskip\noindent\textbf{#1.}\ }
+
+
+
+\newcommand\etc{\textit{etc.}\xspace}
+\newcommand\eg{\textit{e.g.}\xspace}
+\newcommand\ie{\textit{i.e.}\xspace}
+\newcommand\ala{\textit{a la}\xspace}
+\newcommand\etal{\textit{et al.}\xspace}
+
+\def\emphbf#1{\textbf{\emph{#1}}}
+\def\spmid{\ \mid \ }
+
+\def\colon{\ensuremath{\text{:}}}
+
+\newcommand{\relDescription}[1]{\ensuremath{\textrm{\textbf{#1}}}}
+\newcommand{\judgementHead}[2]{\ensuremath{\relDescription{#1}\hfill\fbox{#2}}}
+\newcommand{\judgementHeadNameOnly}[1]{\ensuremath{\relDescription{#1}\hfill}}
+
+\newenvironment{sitemize}{\begin{list}
+   {$\bullet$}
+   {\setlength{\topsep}{0pt}
+    \setlength{\itemsep}{0pt}
+    \setlength{\leftmargin}{15pt}
+    }
+  }
+  {\end{list}}
+
+
diff --git a/docs/language/haskellListings.tex b/docs/language/haskellListings.tex
new file mode 100644
--- /dev/null
+++ b/docs/language/haskellListings.tex
@@ -0,0 +1,113 @@
+\usepackage{listings}
+
+% uncomment next line to restore colors
+% \def\withcolor{}
+
+\ifdefined\withcolor
+	\definecolor{haskellblue}{rgb}{0.0, 0.0, 1.0}
+	\definecolor{haskellblue}{rgb}{1.0, 0.0, 0.0}
+	\definecolor{gray_ulisses}{gray}{0.55}
+	\definecolor{castanho_ulisses}{rgb}{0.71,0.33,0.14}
+	\definecolor{preto_ulisses}{rgb}{0.41,0.20,0.04}
+	\definecolor{green_ulisses}{rgb}{0.0,0.4,0.0}
+\else
+	\definecolor{haskellblue}{gray}{0.1}
+	\definecolor{haskellred}{gray}{0.1}
+	\definecolor{gray_ulisses}{gray}{0.1}
+	\definecolor{castanho_ulisses}{gray}{0.1}
+	\definecolor{preto_ulisses}{gray}{0.1}
+	\definecolor{green_ulisses}{gray}{0.1}
+\fi
+
+
+\def\codesize{\normalsize}
+
+\lstdefinelanguage{HaskellUlisses} {
+	basicstyle=\ttfamily\codesize,
+	sensitive=true,
+	morecomment=[l][\color{gray_ulisses}\ttfamily\codesize]{--},
+	%% morecomment=[s][\color{gray_ulisses}\ttfamily\codesize]{\{-}{-\}},
+	morestring=[b]",
+	stringstyle=\color{haskellred},
+	showstringspaces=false,
+	numberstyle=\codesize,
+	numberblanklines=true,
+	showspaces=false,
+	breaklines=true,
+	showtabs=false,
+	emph=
+	{[1]
+		FilePath,IOError,abs,acos,acosh,all,and,any,appendFile,approxRational,asTypeOf,asin,
+		asinh,atan,atan2,atanh,basicIORun,break,catch,ceiling,chr,compare,concat,concatMap,
+		const,cos,cosh,curry,cycle,decodeFloat,denominator,digitToInt,div,divMod,drop,
+		dropWhile,either,elem,encodeFloat,enumFrom,enumFromThen,enumFromThenTo,enumFromTo,
+		error,even,exp,exponent,fail,filter,flip,floatDigits,floatRadix,floatRange,floor,
+		fmap,foldl,foldl1,foldr,foldr1,fromDouble,fromEnum,fromInt,fromInteger,
+		fromRational,fst,gcd,getChar,getContents,getLine,head,id,inRange,index,init,intToDigit,
+		interact,ioError,isAlpha,isAlphaNum,isAscii,isControl,isDenormalized,isDigit,isHexDigit,
+		isIEEE,isInfinite,isLower,isNaN,isNegativeZero,isOctDigit,isPrint,isSpace,isUpper,iterate,
+		last,lcm,length,lex,lexDigits,lexLitChar,lines,log,logBase,lookup,map,mapM,mapM_,max,
+		maxBound,maximum,maybe,min,minBound,minimum,mod,negate,not,notElem,numerator,odd,
+		or,pi,pred,primExitWith,print,product,properFraction,putChar,putStr,putStrLn,quot,
+		quotRem,range,rangeSize,read,readDec,readFile,readFloat,readHex,readIO,readInt,readList,readLitChar,
+		readLn,readOct,readParen,readSigned,reads,readsPrec,realToFrac,recip,rem,repeat,replicate,
+		reverse,round,scaleFloat,scanl,scanl1,scanr,scanr1,seq,sequence,sequence_,show,showChar,showInt,
+		showList,showLitChar,showParen,showSigned,showString,shows,showsPrec,significand,signum,sin,
+		sinh,snd,span,splitAt,sqrt,subtract,succ,sum,tail,take,takeWhile,tan,tanh,threadToIOResult,toEnum,
+		toInt,toInteger,toLower,toRational,toUpper,truncate,uncurry,undefined,unlines,until,unwords,unzip,
+		unzip3,userError,words,writeFile,zip,zip3,zipWith,zipWith3,listArray,doParse,for,initTo,
+        maxEvens,create,get,set,initialize,idVec,fastFib,fibMemo,
+        insert,union,split,size,fromList,initUpto,trim,quickSort,insertSort,append,upperCase,
+        copy, group, doDownLoop, mapAccumR, peekByteOff,
+        pokeByteOff,spanByte, 
+        good, bad, foo, explode, 
+        fib, ack, 
+        tLen,
+        memcpy,writeChar,unsafeWrite,unsafeFreeze,
+        singleton
+	},
+	emphstyle={[1]\color{haskellblue}},
+	emph=
+	{[2]
+		Bool,Char,Double,Either,Float,IO,Integer,Int,Maybe,Ordering,Rational,Ratio,ReadS,ShowS,String,
+		Word8,Nat,NonZero,Nat64,Text,ByteString,ByteStringSZ,ByteStringN,
+        Ptr,ForeignPtr,CSize
+        InPacket,Tree,Prop,TreeEq,TreeLt,Vec,
+        NullTerm,IncrList,DecrList,UniqList,BST,MinHeap,MaxHeap,
+        PtrN,ByteStringN,ByteStringEq,VO,ByteStringsEq,ByteStringNE
+	},
+	emphstyle={[2]\color{castanho_ulisses}},
+	emph=
+	{[3]
+		case,class,data,deriving,do,else,if,import,in,infixl,infixr,instance,let,
+		module,measure,predicate,of,primitive,then,refinement,type,where
+	},
+	emphstyle={[3]\color{preto_ulisses}\textbf},
+	emph=
+	{[4]
+		quot,rem,div,mod,elem,notElem,seq
+	},
+	emphstyle={[4]\color{castanho_ulisses}\textbf},
+	emph=
+	{[5]
+		PS,Tip,Node,EQ,False,GT,Just,LT,Left,Nothing,Right,True,Show,Eq,Ord,Num
+	},
+	emphstyle={[5]\color{green_ulisses}}
+}
+
+%%%ORIG
+%%%\lstnewenvironment{code}
+%%%{\textbf{Haskell Code} \hspace{1cm} \hrulefill \lstset{language=HaskellUlisses}}
+%%%{\hrule\smallskip}
+
+%V1
+%\lstnewenvironment{code}
+%{\smallskip \lstset{language=HaskellUlisses}}
+%{\smallskip}
+
+\lstnewenvironment{code}
+{\lstset{language=HaskellUlisses}}
+{}
+
+\lstMakeShortInline[language=HaskellUlisses]@
+
diff --git a/docs/language/language.tex b/docs/language/language.tex
new file mode 100644
--- /dev/null
+++ b/docs/language/language.tex
@@ -0,0 +1,82 @@
+
+
+
+\begin{figure}[t!]
+\centering
+$$
+\begin{array}{rrcl}
+\emphbf{Basic Types} \quad
+  & b 
+  & ::=
+  & \alpha
+  \spmid \tfun{x}{\tau}{\tau}
+  \spmid \tcon{C}{\bar{\tau}}{\bar{\ref}}
+  \spmid \tapp{\tau}{\tau}
+  \\[0.05in]
+
+\emphbf{Types} \quad
+  & \tau 
+  & ::=
+  & \tref{v}{b}{\ref}
+  \spmid \tcl{Cl}{\bar{\tau}}
+  \\[0.05in]
+
+\emphbf{Abstract Refinements} \quad
+  & \pi
+  & ::=
+  & \forall \left\langle p \colon \tau \right\rangle . \pi 
+  \spmid \tau
+  \\[0.05in]
+
+\emphbf{Type Schemata} \quad
+  & \sigma
+  & ::=
+  & \tall{\alpha}{\sigma} 
+  \spmid \pi
+  \\[0.05in]
+
+\emphbf{Refinements} \quad
+  & \ref
+  & ::=
+  & (\aref,\cref)
+  \\[0.05in]
+
+\emphbf{Abstract Refinements} \quad
+  & \aref
+  & ::= 
+  &  [] \spmid p\ \bar{e}, \aref
+  \\[0.05in]
+
+\emphbf{Concrete Refinements} \quad
+  & \cref
+  & ::=
+  &  k \sub{x}{e}
+  \spmid \pr
+  \spmid \cref \land \cref
+  \\[0.05in]
+
+\emphbf{Predicates} \quad
+  & \pr
+  & ::=
+  &  \ptrue \spmid \pfalse 
+  \spmid \pand{\bar{\pr}}
+  \spmid \por{\bar{\pr}}
+  \spmid \pnot{\pr}
+  \spmid \pimp{\pr}{\pr}
+  \spmid \piff{\pr}{\pr}
+  \\ && \spmid &  e 
+  \spmid e \left[= \mid \neq \mid > \mid < \mid \geq \mid \leq \right] e
+  \\[0.05in]
+
+\emphbf{Expressions} \quad
+  & e
+  & ::=
+  &  c \spmid n \spmid x \spmid \eapp{c}{\bar{e}} \spmid \eif{\pr}{e}{e} 
+  \spmid e \left[+ \mid - \mid * \mid / \mid \% \right] e 
+
+
+  \end{array}
+$$
+\caption{Syntax of \corelan}
+\label{fig:syntax}
+\end{figure}
diff --git a/docs/language/liquidHaskell.sty b/docs/language/liquidHaskell.sty
new file mode 100644
--- /dev/null
+++ b/docs/language/liquidHaskell.sty
@@ -0,0 +1,199 @@
+\newcommand{\C}{\textsc{C}\xspace}
+\newcommand{\toolname}{\textsc{LiquidHaskell}\xspace}
+%\newcommand{\bytestring}{\textsc{bytestring}\xspace}
+%\newcommand{\libtext}{\textsc{text}\xspace}
+\newcommand{\bytestring}{\texttt{Bytestring}\xspace}
+\newcommand{\libtext}{\texttt{Text}\xspace}
+
+%% 
+
+\newcommand{\CRASH}{\ensuremath{\mathtt{crash}}\xspace}
+\newcommand{\defeq}{\ \doteq\ }
+\providecommand{\dbrkts}[1]{[\![#1]\!]}
+%\newcommand\embed[1]{\dbrkts{#1}}
+\newcommand\embed[1]{\dbrkts{#1}}
+\newcommand\R{\ensuremath{\mathsf{Fin}\xspace}}
+\newcommand\FORCE[1]{#1 \in \R}
+\newcommand\NOFORCE[1]{#1 \not \in \R}
+
+\newcommand\corelan{$\lambda_\downarrow$\xspace}
+\newcommand\ttbind[2]{\ensuremath{\mathtt{#1}:\mathtt{#2}}}
+\newcommand\tbind[2]{{#1} \colon {#2}}
+\newcommand\ttref[1]{\ensuremath{\mathtt{\{#1\}}}}
+\newcommand\ttreft[3]{\ttref{\tbind{#1}{#2}\mid {#3}}}
+
+\newcommand\subt[2]{\ensuremath{#1 \preceq #2}}
+\newcommand\subtref[2]{\subt{\ttref{#1}}{\ttref{#2}}}
+
+\newcommand\hastypet[3]{\ensuremath{#1 \vdash \tbind{#2}{#3}}}
+\newcommand\hastype[3]{\ensuremath{#1 \vdash #2 : #3}}
+
+\newcommand\issubtype[3]{\ensuremath{#1 \vdash #2 \preceq #3}}
+\newcommand\iswellformed[2]{\ensuremath{#1 \vdash #2}}
+\newcommand\wellformedsub[2]{\ensuremath{#1 \models #2}}
+\newcommand\ismodeled[2]{\ensuremath{#1 \models #2}}
+\newcommand\wfmodels[2]{\ismodeled{#1}{#2}}
+
+\newcommand\stepsym{\hookrightarrow}
+\newcommand\stepv{\stepsym_v}
+\newcommand\stepn{\stepsym_n}
+\newcommand\stepo{\stepsym_o}
+
+\newcommand\eval[2]{\evalR{\stepsym}{#1}{#2}}
+\newcommand\evalR[3]{\ensuremath{#2 #1 #3}}
+\newcommand\evalGen[4]{\evalR{\stepsym_{#3}^{#4}}{#1}{#2}}
+
+\newcommand\evalv[2]{\evalGen{#1}{#2}{v}{}}
+\newcommand\evaln[2]{\evalGen{#1}{#2}{n}{}}
+\newcommand\evalo[2]{\evalGen{#1}{#2}{o}{}}
+\newcommand\evalvs[2]{\evalGen{#1}{#2}{v}{*}}
+\newcommand\evalns[2]{\evalGen{#1}{#2}{n}{*}}
+\newcommand\evalos[2]{\evalGen{#1}{#2}{o}{*}}
+
+% termination eval
+\newcommand\evalt[3]{\evalGen{#1}{#2}{o}{#3}}
+\newcommand\evalts[2]{\evalGen{#1}{#2}{o}{*}}
+
+
+
+
+
+
+\newcommand\sub[2]{\ensuremath{\left[#2/#1\right]}}
+%\newcommand\sub[2]{\ensuremath{\left[#1 \mapsto #2\right]}}
+\newcommand{\SUBST}[3]{{#1}\sub{#2}{#3}}
+
+\newcommand\shape{\ensuremath{\text{shape}}\xspace}
+\newcommand\termincon[1]{\ensuremath\textcolor{Red}{#1}}
+
+%TT
+\newcommand\Env{\Gamma}
+
+\newcommand\ttack{\mathtt{ack}}
+
+\newcommand\tttLen{\mathtt{tLen}}
+\newcommand\ttsz{\mathtt{sz}}
+\newcommand\ttt{\mathtt{t}}
+\newcommand\tttp{\mathtt{t'}}
+\newcommand\ttb{\mathtt{b}}
+\newcommand\tta{\mathtt{a}}
+\newcommand\ttm{\mathtt{m}}
+\newcommand\ttmp{\mathtt{m'}}
+\newcommand\ttnp{\mathtt{n'}}
+\newcommand\ttn{\mathtt{n}}
+\newcommand\ttp{\mathtt{p}}
+\newcommand\ttv{\mathtt{v}}
+\newcommand\ttx{\mathtt{x}}
+\newcommand\tty{\mathtt{y}}
+\newcommand\ttz{\mathtt{z}}
+\newcommand\tte{\mathtt{e}}
+\newcommand\ttf{\mathtt{e}}
+\newcommand\ttg{\mathtt{e}}
+\newcommand\ttInt{\mathtt{Int}}
+\newcommand\ttNonzero{\mathtt{NonZero}}
+\newcommand\ttNat{\mathtt{Nat}}
+\newcommand\ttfib{\mathtt{fib}}
+
+% MISC 
+
+\newcommand\smtvalid[1]{\ensuremath{\mathsf{SmtValid}(#1)}}
+\newcommand\strict{\ensuremath{\mathsf{Trivial}}}
+\newcommand\constty[1]{\ensuremath{\mathsf{Ty}(#1)}}
+\newcommand\serious{serious\xspace}
+\newcommand\trivial{trivial\xspace}
+
+
+% Expressions
+\newcommand\efun[3]{\ensuremath{\lambda #1. #3}}
+\newcommand\eapp[2]{\ensuremath{#1 \ #2}}
+\newcommand\eif[3]{\ensuremath{\mathtt{if}\ #1\ \mathtt{then}\ #2\ \mathtt{else}\ #3}}
+\newcommand\elet[3]{\ensuremath{\mathtt{let}\ #1 = #2\ \mathtt{in}\ #3}}
+\newcommand\erec[3]{\ensuremath{\mu #1.\lambda #2. #3}}
+\newcommand\etabs[2]{\ensuremath{\left[\Lambda #1\right] #2}}
+\newcommand\etapp[2]{\ensuremath{#1 \left[ #2 \right]}}
+\newcommand\etrue{\ensuremath{\mathtt{true}}\xspace}
+\newcommand\efalse{\ensuremath{\mathtt{false}}\xspace}
+\newcommand\eletsub[2]{\ensuremath{#1 #2}}
+
+%Labels
+\newcommand\ltop{\ensuremath{\downarrow}\xspace}
+\newcommand\lbot{\ensuremath{\uparrow}\xspace}
+
+% Types
+\newcommand\tbool{\ensuremath{\mathtt{bool}}\xspace}
+\newcommand\tint{\ensuremath{\mathtt{nat}}\xspace}
+\newcommand\tref[4]{\ensuremath{\{ \tbind{#1}{#2^{#3}} \mid #4 \}}}
+\newcommand\tfun[3]{\ensuremath{\tbind{#1}{#2} \rightarrow #3}}
+\newcommand\tabs[2]{\ensuremath{\forall #1 . #2}}
+
+%Rule Names
+\newcommand\rulename[1]{\textsc{#1}\xspace}
+\newcommand{\rtsub}{\rulename{T-Sub}}
+\newcommand{\rtvara}{\rulename{T-Var-Base}}
+\newcommand{\rtvarb}{\rulename{T-Var}}
+\newcommand{\rtconst}{\rulename{T-Con}}
+\newcommand{\rtfun}{\rulename{T-Fun}}
+\newcommand{\rtapp}{\rulename{T-App}}
+\newcommand{\rtappa}{\rulename{T-App-$\lbot$}}
+\newcommand{\rtappb}{\rulename{T-App-$\ltop$}}
+\newcommand{\rtif}{\rulename{T-If}}
+\newcommand{\rtlet}{\rulename{T-Let}}
+\newcommand{\rtgen}{\rulename{T-Gen}}
+\newcommand{\rtinst}{\rulename{T-Inst}}
+\newcommand{\rtrec}{\rulename{T-Rec}}
+\newcommand{\rtrecs}{\rulename{T-Rec-$\lbot$}}
+\newcommand{\rtrect}{\rulename{T-Rec-$\ltop$}}
+%% \newcommand{\rtrecs}{\rulename{TR-Ser}}
+%% \newcommand{\rtrect}{\rulename{TR-Tr}}
+
+\newcommand{\rsbasetop}{\rulename{$\preceq$-Base-$\ltop$}}
+\newcommand{\rsbasebot}{\rulename{$\preceq$-Base-$\lbot$}}
+\newcommand{\rsvar}{\rulename{$\preceq$-Var}}
+\newcommand{\rsfun}{\rulename{$\preceq$-Fun}}
+\newcommand{\rspoly}{\rulename{$\preceq$-Poly}}
+
+\newcommand{\rwbasetop}{\rulename{WF-Base-$\ltop$}}
+\newcommand{\rwbasebot}{\rulename{WF-Base-$\lbot$}}
+\newcommand{\rwbase}{\NV{TODO}}
+\newcommand{\rwvar}{\rulename{WF-Var}}
+\newcommand{\rwfun}{\rulename{WF-Fun}}
+\newcommand{\rwpoly}{\rulename{WF-Poly}}
+
+\newcommand{\rwsempty}{\rulename{WS-Empty}}
+\newcommand{\rwsext}{\rulename{WS-Ext}}
+\newcommand{\rwsgxt}{\rulename{WS-Gxt}}
+
+
+\newcommand{\reapp}{\rulename{E-AppL}}
+\newcommand{\reappb}{\rulename{E-App}}
+\newcommand{\reappc}{\rulename{E-AppT}}
+\newcommand{\reappd}{\rulename{E-AppTB}}
+\newcommand{\reconsta}{\rulename{E-ConstA}}
+\newcommand{\reconstb}{\rulename{E-Con}}
+\newcommand{\reif}{\rulename{E-If}}
+\newcommand{\reiftrue}{\rulename{E-If-True}}
+\newcommand{\reiffalse}{\rulename{E-If-False}}
+\newcommand{\rereca}{\rulename{E-Rec}}
+\newcommand{\rerecb}{\NV{UNIFIED}}
+\newcommand{\rerecc}{\rulename{E-RecC}}
+\newcommand{\reinst}{\NV{TODO}}
+\newcommand{\reinsta}{\rulename{E-InstA}}
+\newcommand{\reinstb}{\rulename{E-InstB}}
+\newcommand{\reinstc}{\rulename{E-InstC}}
+\newcommand{\releta}{\rulename{E-Let}}
+\newcommand{\reletb}{\rulename{E-LetX}}
+\newcommand{\recntx}{\rulename{E-Com}}
+\newcommand{\reletc}{\rulename{E-LetTB}}
+
+%%%%%%%% TABLE
+
+\newcommand\bfModule{\textbf{Module}\xspace}
+\newcommand\bfAnnot{\textbf{Annot}\xspace}
+\newcommand\bfQualif{\textbf{Qualif}\xspace}
+\newcommand\bfLOC{\textbf{LOC}\xspace}
+\newcommand\bfSpecs{\textbf{Specs}\xspace}
+\newcommand\bfLetRec{\textbf{Rec}\xspace}
+\newcommand\bfMutRec{\textbf{Mut}\xspace}
+\newcommand\bfHint{\textbf{Hint}\xspace}
+\newcommand\bfWitness{\textbf{Wit}\xspace}
+
diff --git a/docs/language/main.pdf b/docs/language/main.pdf
new file mode 100644
Binary files /dev/null and b/docs/language/main.pdf differ
diff --git a/docs/language/main.tex b/docs/language/main.tex
new file mode 100644
--- /dev/null
+++ b/docs/language/main.tex
@@ -0,0 +1,110 @@
+\documentclass[10pt,a4paper]{article}
+
+%\documentclass{llncs}
+%\documentclass[nocopyrightspace]{sigplanconf}
+%%% \usepackage[top=1.5cm,bottom=1.5cm,left=2.3cm,right=2cm]{geometry}
+
+\pagestyle{plain}
+\usepackage{times}
+%\usepackage[nocompress]{cite} % AR: comment this out if you wish hyperrefs 
+\usepackage{hyperref}
+
+\usepackage{amsmath,amssymb, latexsym}
+
+\usepackage{amsmath}
+\usepackage{amsthm}
+
+\newtheorem{lemma}{Lemma}
+\newtheorem{theorem}{Theorem}
+\newtheorem*{theorem*}{Theorem}
+\newtheorem{definition}{Definition}
+\newtheorem*{lemma*}{Lemma}
+
+\usepackage{amsfonts}
+\usepackage{amssymb}
+
+\usepackage{commands}
+\usepackage{liquidHaskell}
+\usepackage[inference]{semantic}
+
+\usepackage{enumerate}
+\def\url{}
+\usepackage{xspace}
+\usepackage{epsfig}
+\usepackage{booktabs}
+\usepackage{listings}
+\usepackage{comment}
+\usepackage{ifthen}
+
+\newcommand{\isTechReport}{false} % true or false
+\newcommand{\includeProof}[1]{
+  \ifthenelse{\equal{\isTechReport}{true}}{
+    #1
+  }{
+  }
+}
+
+%%%%%\usepackage{fancyvrb}
+%%%%%\DefineVerbatimEnvironment{code}{Verbatim}{fontsize=\small}
+%%%%%\DefineVerbatimEnvironment{example}{Verbatim}{fontsize=\small}
+%%%%%\newcommand{\ignore}[1]{}
+
+% command to end a proof or definition:
+%\def\qed{\rule{0.4em}{1.4ex}}
+\def\qed{\hfill$\Box$}
+
+% space at the beginning of an environment:
+\def\@envspa{\hspace{0.3em}}
+\def\@sa{\hspace{-0.2em}}
+\def\@sb{\hspace{0.5em}}
+\def\@sc{\hspace{-0.1em}}
+
+\def\sk{\smallskip}		% space before and after theorems
+
+\newtheorem{notation}{Notation}{\itshape}{}
+\newtheorem{invariant}{Invariant}
+\newtheorem*{hypothesis}{Hypothesis}
+
+\input{haskellListings}
+
+
+\begin{document}
+%% BEGIN MOVE 
+% these are mostly redefined commands, move them to commands
+
+\renewcommand\tref[3]{\ensuremath{\{#1 : #2 \mid #3 \}}}
+\renewcommand\tfun[3]{\ensuremath{#1 : #2 \rightarrow #3}}
+\newcommand\tcon[3]{\ensuremath{#1 \ #2 \ #3}}
+\newcommand\tapp[2]{\ensuremath{#1 \ #2}}
+\newcommand\tall[2]{\ensuremath{ \forall #1 .  #2}}
+\newcommand\tcl[2]{\ensuremath{#1 \ #2}}
+\renewcommand\ref{r}
+\newcommand\pr{pr}
+\newcommand\aref{ar}
+\newcommand\cref{cr}
+
+\newcommand\ptrue{\ensuremath{true}}
+\newcommand\pfalse{\ensuremath{false}}
+\newcommand\pand[1]{\ensuremath{\bigwedge \ #1}}
+\newcommand\por[1]{\ensuremath{\bigvee \ #1}}
+\newcommand\pnot[1]{\ensuremath{\lnot #1}}
+\newcommand\pimp[2]{\ensuremath{#1 \Rightarrow #2}}
+\newcommand\piff[2]{\ensuremath{#1 \Leftrightarrow #2}}
+
+\renewcommand\eapp[2]{\ensuremath{#1 \ #2}}
+\renewcommand\eif[3]{\ensuremath{if \ #1 \ then \ #2 \ else \ #3}}
+\renewcommand\corelan{\texttt{liquidHaskell}}
+
+%% END MOVE
+
+% \maketitle
+
+\input{language}
+\input{typeInference}
+
+% {
+% \bibliographystyle{plain}
+% \bibliography{sw}
+% }
+
+\end{document}
diff --git a/docs/language/typeInference.tex b/docs/language/typeInference.tex
new file mode 100644
--- /dev/null
+++ b/docs/language/typeInference.tex
@@ -0,0 +1,325 @@
+\renewcommand\hastype[4]{\ensuremath{#1 \vdash #2 \uparrow #3 ; #4}}
+\newcommand\checktype[4]{\ensuremath{#1 \vdash #2 \downarrow #3 ; #4}}
+\newcommand\hastypealt[5]{\ensuremath{#1 ; #2 \downarrow #3 \colon #4 ; #5}}
+\newcommand\ty[1]{\ensuremath{ty(#1)}}
+
+\NV{TODO : \\
+1. Add termination checker.}
+
+\section*{Constraint Generation (without the termination checker)}
+
+\hfill\textbf{Type synthesis}\qquad\mbox{\hastype{\Gamma}{e}{\sigma}{C}}
+
+
+$$
+\inference{
+	(x, \tref{v}{b}{e}) \in \Gamma
+}{
+	\hastype{\Gamma}{x}{\tref{v}{b}{e \land x = v}}{\emptyset}
+}
+\qquad
+\inference{
+	(x, \sigma \in \Gamma) &&
+	\sigma \neq \tref{v}{b}{e}
+}{
+	\hastype{\Gamma}{x}{\sigma}{\emptyset}
+}
+$$
+
+$$
+\inference{
+}{
+	\hastype{\Gamma}{c}{\tref{v}{\ty{c}}{v = c}}{\emptyset}
+}
+$$
+
+\newcommand\wfc[2]{\ensuremath{\texttt{WfC}\ #1 \ #2}}
+\newcommand\subc[3]{\ensuremath{\texttt{SubC}\ #1 \ #2\ #3}}
+\newcommand\freshty[1]{\ensuremath{freshTy(#1)}}
+\newcommand\truety[1]{\ensuremath{trueTy(#1)}}
+\newcommand\truetyExpr[1]{\ensuremath{trueTyExpr(#1)}}
+\newcommand\isGenericty[2]{\ensuremath{isGeneric(#1, #2)}}
+\newcommand\freshPredsty[1]{\ensuremath{freshPreds(\Gamma, #1)}}
+\newcommand\varTemplate[1]{\ensuremath{varTemplate(#1)}}
+\newcommand\dataconty[2]{\ensuremath{dataConTy(#1, #2)}}
+
+$$
+\inference{
+	\hastype{\Gamma}{e}{\tall{\alpha}{\sigma}}{C} \\
+	\tau' = if\ \isGenericty{\alpha}{\sigma}\ then\ \freshty{\tau}\ else\ \truety{\tau}
+}{
+	\hastype{\Gamma}{\etapp{e}{\tau}}{\sigma\sub{\alpha}{\tau'}}{(\wfc{\Gamma}{\tau'}, C)}
+}
+$$
+
+$$
+\inference{
+	\hastype{\Gamma}{e_1}{\tau_1}{C_1} &&
+	\checktype{\Gamma}{e_2}{\tau_x}{C_2} &&\\
+	(\tau_1', C_p) = \freshPredsty{\tau_1} &&
+	\tfun{x}{\tau_x}{\tau} = \tau_1'
+}{
+	\hastype{\Gamma}{\eapp{e_1}{e_2}}{\tau\sub{x}{e_2}}
+			{(C_1, C_2, C_p)}
+}
+$$
+
+
+$$
+\inference{
+	\hastype{\Gamma}{e}{\sigma}{C}
+}{
+	\hastype{\Gamma}{\etabs{\alpha}{e}}{\tall{\alpha}{\sigma}}{C}
+}
+$$
+
+$$
+\inference{
+	\hastype{\Gamma, x : \tau_x}{e}{\tau}{C} &&
+	t_x = freshty(varType\ x)
+}{
+	\hastype{\Gamma}{(\efun{x}{}{e})}{(\tfun{x}{\tau_x}{\tau})}{(\wfc{\Gamma}{\tau_x}, C)}
+}
+$$
+
+$$
+\inference{
+	\hastype{\Gamma}{e}{\sigma}{C}
+}{
+	\hastype{\Gamma}{Tick\ t\ e}{\sigma}{C}
+}
+$$
+
+$$
+\inference{
+}{
+	\hastype{\Gamma}{Cast\ e\ c}{\truetyExpr{Cast\ e\ c}}{\emptyset}
+}
+$$
+
+$$
+\inference{
+}{
+	\hastype{\Gamma}{Coercion\ c}{\truetyExpr{Coercion\ c}}{\emptyset}
+}
+$$
+
+$$
+\inference{
+	\sigma = \freshty{e} &&
+	\checktype{\Gamma}{\elet{{x_i}}{e_{x_i}}{e}}{\sigma}{C}
+}{
+	\hastype{\Gamma}{\elet{{x_i}}{e_{x_i}}{e}}{\sigma}{(\wfc \Gamma \sigma, C)}
+}
+$$
+
+$$
+\inference{
+	\sigma = \freshty{e} &&
+	\checktype{\Gamma}{Case\ e\ x\ alt_i}{\sigma}{C}
+}{
+	\hastype{\Gamma}{Case\ e\ x\ alt_i}{\sigma}{(\wfc \Gamma \sigma, C)}
+}
+$$
+
+
+
+\hfill\textbf{Type checking}\qquad\mbox{\checktype{\Gamma}{e}{\sigma}{C}}
+
+
+
+
+%% This rule allows more general types for let binds.
+%% Eg. (tests/pos/meas1.hs)
+%% goo x = [x] :: a -> {v:[a] | ((null v) <=> false)} -- by default
+%% this rule also allows 
+%% goo :: a -> {v:[a] | ((len v) > 0)}
+
+\newcommand\userType[1]{\ensuremath{userType(#1)}}
+
+$$
+\inference{
+	\tau_x  = userTypes(x) &&
+	\checktype{\Gamma}{e_x}{\tau_x}{C_x} \\&&
+	\checktype{\Gamma, x\colon\tau_x}{e}{\sigma}{C}
+}{
+	\checktype{\Gamma}{\elet{x}{e_x}{e}}{\sigma}{(C_x,C)}
+}
+$$
+
+$$
+\inference{
+	x \notin userTypes &&
+	\hastype{\Gamma}{e_x}{\tau_x}{C_x} \\&&
+	\checktype{\Gamma, x\colon\tau_x}{e}{\sigma}{C}
+}{
+	\checktype{\Gamma}{\elet{x}{e_x}{e}}{\sigma}{(C_x,C)}
+}
+$$
+
+$$
+\inference{
+	\checktype{\Gamma, \overline{{x_i} : \tau_{x_i}}}{e}{\sigma}{C} &&\\
+	(C_{x_i}, \tau_{x_i}) = \varTemplate{x_i} &&
+	\checktype{\Gamma, \overline{{x_i} : \tau_{x_i}}}{e_{x_i}}{\tau_{x_i}}{C_{x_i}'}
+}{
+	\hastype{\Gamma}{\elet{{x_i}}{e_{x_i}}{e}}{\sigma}{(C_{x_i}, C_{x_i}', C)}
+}
+$$
+
+$$
+\inference{
+	\hastype{\Gamma}{e}{\tau_x}{C_x} &&
+	\hastypealt{(\Gamma, x:\tau_x)}{x}{alt_i}{\sigma}{C_i}
+}{
+	\checktype{\Gamma}{Case\ e\ x\ alt_i}{\sigma}{(C_x, C_i)}
+}
+$$
+
+$$
+\inference{
+	\checktype{\Gamma}{e}{\sigma\sub{\alpha'}{\alpha}}{C}
+}{
+	\checktype{\Gamma}{\etabs{\alpha}{e}}{\tall{\alpha'}{\sigma}}{C}
+}
+$$
+
+$$
+\inference{
+	\checktype{\Gamma, x : \tau_y}{e}{\tau\sub{y}{x}}{C}
+}{
+	\checktype{\Gamma}{\efun{x}{\tau}{e}}{(\tfun{y}{\tau_y}{\tau})}{C}
+}
+$$
+
+$$
+\inference{
+	\checktype{\Gamma}{e}{\sigma}{C}
+}{
+	\checktype{\Gamma}{Tick\ t\ e}{\sigma}{C}
+}
+$$
+
+$$
+\inference{
+	\sigma' = \truety{Cast\ c\ e}
+}{
+	\checktype{\Gamma}{Cast\ c\ e}{\sigma}{(C, \subc{\Gamma}{\sigma'}{\sigma})}
+}
+$$
+
+$$
+\inference{
+	\checktype{\Gamma, p \colon \tau}
+	{e}{\sigma}{C} %% here replacePredsWithRefs is used
+}{
+	\checktype{\Gamma}{e}
+	{\forall \left\langle p \colon \tau \right\rangle . \sigma}{C}
+}
+$$
+
+$$
+\inference{
+	\hastype{\Gamma}{e}{\sigma'}{C} &&
+	(\sigma'', C_p) = \freshPredsty{\sigma'}
+}{
+	\checktype{\Gamma}{e}{\sigma}
+	{(C, C_p, \subc{\Gamma}{\sigma''}{\sigma})}
+}
+$$
+
+
+\hfill\mbox{\hastypealt{\Gamma}{x}{alt}{\sigma}{C}}
+$$
+\inference{
+	(x,\tau_x^0) \in \Gamma  && \tau_x^0 = \tref{v}{C\ {t_C}_l\ {r_C}_j }{r}  &&
+	\ty{C} = \forall \alpha_l p_j . y_1\colon t_1 \rightarrow \dots y_n \colon t_n \rightarrow t &&\\
+	\theta = \sub{\alpha_l}{{t_C}_l}\sub{p_j}{{r_C}_j}\sub{y_i}{x_i} &&\\
+	\tau_{x_i} = \theta t_i && \tau_x = \theta t \land \tau_x^0 \land \dataconty{C}{x_i} &&\\
+	\checktype{\Gamma, x\colon \tau_x, x_i \colon \tau_{x_i}}{e}{\sigma}{C}
+}{
+	\hastypealt{\Gamma}{x}{(C, x_i, e)}{\sigma}{C}
+}
+$$
+
+
+% FUNCTIONS
+\section*{Helper Functions}
+\hfill\isGenericty{\alpha}{\sigma} -- not constrained by class predicates
+$$\isGenericty{\alpha}{\sigma} \Leftrightarrow \alpha \notin ClassConstraints(\sigma)$$ 
+
+\begin{align*}
+classConstraints(\tall{\alpha}{\sigma}) &= classConstraints(\sigma)\\ 
+classConstraints(\tall{p}{\sigma}) &= classConstraints(\sigma)\\ 
+classConstraints(C \alpha_i \rightarrow \tau) &= \alpha_i \cup classConstraints(\tau) 
+\end{align*}
+
+\hfill\freshty{\sigma} { -- type with liquid variables for all refinements}\\
+
+\newcommand\freshref{\ensuremath{fref}} %([], k_i)}}
+\newcommand\trueref{\ensuremath{tref}}  %([], true)}}
+$$
+\begin{array}{lcl}
+\freshty{\tref{v}{\alpha}{r}} &=& \tref{v}{\alpha}{\freshref}\\
+\freshty{\tref{v}{\tfun{x}{\tau_x}{\tau}}{r}} &=& \tref{v}{\tfun{x}{\freshty{\tau_x}}{\freshty{\tau}}}{\trueref}\\
+\freshty{\tref{v}{\tcon{C}{\overline{\tau}}{\overline{\ref}}}{r}} 
+	&=& \tref{v}{\tcon{C}{\overline{\freshty{\tau}}}{\overline{\freshref}}}{\freshref}\\
+\freshty{\tref{v}{\tapp{\tau_1}{\tau_2}}{r}} &=& \tref{v}{\tapp{\freshty{\tau_1}}{\freshty{\tau_2}}}{\trueref}\\
+\freshty{\tcl{Cl}{\bar{\tau}}} &=& \tcl{Cl}{\bar{\tau}}\\
+\freshty{\tall{\alpha}{\sigma}} &=& \tall{\alpha}{\freshty{\sigma}}\\
+\freshty{\forall \left\langle p \colon \tau \right\rangle . \sigma} 
+	&=& {\forall \left\langle p \colon \tau \right\rangle . \freshty{\sigma}}
+\end{array}
+$$
+where $fref = {([], k_i)}$, $tref = {([], true)}$
+
+\hfill\truety{\sigma} { -- type with true for all refinements}\\
+$$
+\begin{array}{lcl}
+\truety{\tref{v}{\alpha}{r}} 
+	&=& \tref{v}{\alpha}{\trueref}\\
+\truety{\tref{v}{\tfun{x}{\tau_x}{\tau}}{r}} 
+	&=& \tref{v}{\tfun{x}{\truety{\tau_x}}{\truety{\tau}}}{\trueref}\\
+\truety{\tref{v}{\tcon{C}{\overline{\tau}}{\overline{\ref}}}{r}} 
+	&=& \tref{v}{\tcon{C}{\overline{\truety{\tau}}}{\overline{\trueref}}}{\trueref}\\
+\truety{\tref{v}{\tapp{\tau_1}{\tau_2}}{r}} 
+	&=& \tref{v}{\tapp{\truety{\tau_1}}{\truety{\tau_2}}}{\trueref}\\
+\truety{\tcl{Cl}{\bar{\tau}}} &=& \tcl{Cl}{\bar{\tau}}\\
+\truety{\tall{\alpha}{\sigma}} &=& \tall{\alpha}{\truety{\sigma}}\\
+\truety{\forall \left\langle p \colon \tau \right\rangle . \sigma} 
+	&=& {\forall \left\langle p \colon \tau \right\rangle . \truety{\sigma}}
+\end{array}
+$$
+
+
+\hfill \freshPredsty{\sigma}  -- replace predicate occurrences with liquid variables
+$$
+\begin{array}{lclll}
+\freshPredsty{\tall{\alpha}{\sigma}}  
+	&=& (\tall{\alpha}{\sigma'}, C) & where& (\sigma', C) = \freshPredsty{\sigma}\\
+\freshPredsty{\forall \left\langle p \colon \tau \right\rangle .\sigma}  
+	&=& (\sigma'\sub{p}{k_i}, (C,\wfc{\Gamma'}{k_i})) & where& (\sigma', C) = \freshPredsty{\sigma}\\ 
+	&&&&  x_1\colon\tau_1 \rightarrow \dots x_n \colon\tau_n \rightarrow Prop= \tau\\
+	&&&&  \Gamma' = \Gamma, x_1\colon\tau_1 \rightarrow \dots x_{n-1} \colon\tau_{n-1}\\
+\freshPredsty{\tau}  
+	&=& (\tau, \emptyset) && \\
+\end{array}
+$$
+
+\begin{align*}
+%\isGenericty{\alpha}{\sigma} & \text{ -- not constrained by class predicates}\\
+%\freshty{\sigma} & \text{ -- type with liquid variables for all refinements}\\
+%\truety{\sigma} & \text{ -- type with true for all refinements}\\
+\truetyExpr{e} & \text{ -- type of expression with true for all refinements}\\
+\varTemplate{x} & \text{ -- type for variable x, user specified type or a fresh type}\\
+\end{align*}
+
+\begin{align*}
+\dataconty{C}{x_i} = 
+\left\lbrace \begin{array}{l l}
+Prop\ v & C = True\\
+\lnot (Prop\ v) & C = False\\
+v = x_1 & C = I\# \\
+v= C x_i & \text{otherwise}
+\end{array}\right.
+\end{align*}
diff --git a/docs/slides/BOS14/Makefile b/docs/slides/BOS14/Makefile
new file mode 100644
--- /dev/null
+++ b/docs/slides/BOS14/Makefile
@@ -0,0 +1,95 @@
+####################################################################
+SERVERHOME=nvazou@goto.ucsd.edu:~/public_html/liquidtutorial/
+RJSERVER=rjhala@goto.ucsd.edu:~/public_html/liquid/haskell/plpv/lhs/
+## LOCAL
+## MATHJAX=file:///Users/rjhala/research/MathJax
+## REMOTE 
+## MATHJAX=https://c328740.ssl.cf1.rackcdn.com/mathjax/latest
+## MATHJAX=https://c328740.ssl.cf1.rackcdn.com/mathjax/latest
+MATHJAX=http://cdn.mathjax.org/mathjax/latest
+
+####################################################################
+
+STRIPCODE=./MkCode.hs
+
+REVEAL=pandoc \
+	   --from=markdown\
+	   --to=html5                           \
+	   --standalone                         \
+	   --mathjax \
+	   --section-divs                       \
+	   --template=_support/template.reveal  \
+	   --variable reveal=../_support/reveal.js \
+	   --variable mathjax=$(MATHJAX)
+
+FREVEAL=pandoc \
+ 	   --from=markdown+lhs\
+	   --to=html5                           \
+	   --standalone                         \
+	   --mathjax \
+	   --section-divs                       \
+	   --template=_support/template.reveal  \
+	   --variable reveal=../_support/reveal.js
+
+PANDOC=pandoc --columns=80  -s --mathjax --slide-level=2
+SLIDY=$(PANDOC) -t slidy
+DZSLIDES=$(PANDOC) --highlight-style tango --css=slides.css -w dzslides
+HANDOUT=$(PANDOC) --highlight-style tango --css=text.css -w html5
+WEBTEX=$(PANDOC) -s --webtex -i -t slidy
+BEAMER=pandoc -t beamer
+LIQUID=liquid --short-names 
+
+mdObjects   := $(patsubst %.lhs,%.lhs.markdown,$(wildcard lhs/*.lhs))
+htmlObjects := $(patsubst %.lhs,%.lhs.slides.html,$(wildcard lhs/*.lhs))
+pdfObjects  := $(patsubst %.lhs,%.lhs.slides.pdf,$(wildcard lhs/*.lhs))
+fhtmlObjects := $(patsubst %.lhs,%.fast.html,$(wildcard lhs/*.lhs))
+
+####################################################################
+
+
+all: slides 
+
+fast: $(fhtmlObjects)
+
+one: $(mdObjects)
+	$(REVEAL) lhs/.liquid/00_Index.lhs.markdown > lhs/index.html
+
+tut: $(mdObjects)
+	$(REVEAL) lhs/.liquid/*.markdown > lhs/tutorial.html 
+
+slides: $(htmlObjects)
+
+pdfslides: $(pdfObjects)
+
+lhs/.liquid/%.lhs.markdown: lhs/%.lhs
+	-$(LIQUID) $?
+
+
+lhs/%.fast: lhs/%.lhs
+	$(STRIPCODE) $? > $@ 
+
+lhs/%.fast.html: lhs/%.fast
+	$(FREVEAL) $? -o $@ 
+
+lhs/%.lhs.slides.html: lhs/.liquid/%.lhs.markdown
+	$(REVEAL) $? -o $@ 
+
+lhs/%.lhs.slides.pdf: lhs/.liquid/%.lhs.markdown
+	$(BEAMER) $? -o $@
+
+
+copy:
+	cp lhs/*lhs.html html/
+	cp lhs/*lhs.slides.html html/
+	cp css/*.css html/
+	cp -r fonts html/
+	cp index.html html/
+	cp Benchmarks.html html/
+
+clean:
+	cd lhs/ && ../cleanup && cd ../
+#	cd html/ && rm -rf * && cd ../
+#	cp index.html html/
+
+upload: 
+	scp -r html/* $(SERVERHOME)
diff --git a/docs/slides/BOS14/README.md b/docs/slides/BOS14/README.md
new file mode 100644
--- /dev/null
+++ b/docs/slides/BOS14/README.md
@@ -0,0 +1,262 @@
+Todo
+----
+
++ CREATE 00_Motivation_Bugs.lhs **TUFTS**
+  + sequence, BUGs, 1984, etc.
+
++ UPDATE 11_Evaluation.lhs **TUFTS,BOS** 
+  + Add bits about "comments" ---> "types"
+  + Nicer GRAPHS
+  
++ CREATE HARDWIRED-RED-BLACK-BST.lhs **TUFTS**
+  + INV 1: COLOR
+  + INV 2: HEIGHT
+  + INV 3: ORDER
+
++ CREATE 03_Memory.lhs **TUFTS, BOS**
+  + and associated demo file, from eseidel's BS demo.
+
++ UPDATE 09_Laziness.lhs **BOS**
+  + Use math fonts
+  
++ CHECK 10_Termination.lhs **BOS**
+  + link to Termination.hs demo
+  
+Comparison with DT
+------------------
+
+-- Grisly HS+DT proof
+https://github.com/jstolarek/dep-typed-wbl-heaps-hs/blob/master/src/TwoPassMerge/CombinedProofs.hs#L68
+
+-- HS (no proof)
+https://github.com/jstolarek/dep-typed-wbl-heaps-hs/blob/master/src/TwoPassMerge/NoProofs.hs#L96
+
+-- HS+LH proof
+https://github.com/ucsd-progsys/liquidhaskell/blob/master/tests/pos/WBL.hs#L129
+
+
+BOS-Haskell Plan
+----------------
+
+[35] PART I "refinement types"
+
+* [5]  00_Motivation: "Go Wrong"
+
+* [15] 01_SimpleRefinements (upto VC, Abs) but no Kvar
+    + Demo : hs/000_Refinements.hs
+	+ Demo : hs/001_Refinements.hs
+	
+* [15] 02_Measures
+    + Demo : hs/01_Elements.hs
+
+[20] PART II "case studies"
+
+* [5]  lhs/02_RedBlack.lhs	
+* [15] lhs/13_Memory.lhs
+
+
+[25] PART III "haskell"
+
+* [10] lhs/09_Laziness.lhs
+* [10] lhs/10_Termination.lhs
+* [3]  lhs/11_Evaluation.lhs 
+* [2]  lhs/12_Conclusion.lhs
+
+[20] PART IV "abstract refinements"
+
+* [5]  04_Abstract Refinements.lhs
+    + Demo : 02_AbstractRefinements.hs (listMax)
+
+* [7] Demo Inductive
+    + Demo:  02_AbstractRefinements.hs (ifoldr, append, filter)
+	  
+* [8] Demo Recursive
+	+ Demo:  02_AbstractRefinements.hs (insertSort, ifoldr-insertSort)
+	+ Demo:  04_Streams.hs (repeat, take)
+
+? [10] Demo Indexed
+	+ Demo: KMP.hs
+
+Tufts Plan
+----------
+
+* [7]  00_Motivation_Long
+        + Bugs
+		+ Well typed Program Go Wrong
+		
+* [10]  01_SimpleRefinements
+        + upto VC, Abs
+
+* [10] 02_Measures 
+        + Demo    : 00_Refinements.hs
+        + Demo    : 01_Elements.hs
+
+* [5]  02_RedBlack 
+		+ Complex : RED-BLACK Trees
+
+* [5] 03_Memory_short?
+		+ Upto just the low-level API?
+		
+* [5]  11_Evaluation.lhs 
+		+ Add bits about "comments" ---> "types"
+		
+* [2]  12_Conclusion.lhs
+
+
+
+Brown Plan
+----------
+
+* [5]  00_Motivation: "Go Wrong"
+
+* [5]  01_SimpleRefinements (upto VC, Abs, but no Kvar)
+
+* [10] 02_Measures [TODO: cut RED-BLACK]
+    + Demo : 00_Refinements.hs
+    + Demo : 01_Elements.hs
+
+* [5]  04_Abstract Refinements
+    + Demo : 02_AbstractRefinements.hs (listMax)
+	
+* [5]  06_Inductive
+	+ Describe: [TODO: CUT ?foldn] foldr
+    + Demo:  02_AbstractRefinements.hs (foldr, append, filter)
+
+* [5]  08_Recursive
+	+ Describe: list-ord
+	+ Demo:  02_AbstractRefinements.hs (insertSort, ifoldr-insertSort)
+	+ Show:  GhcListSort.hs 
+	+ Describe: tree-ord
+	+ Demo:     Stream
+ 
+* [3]  11_Evaluation.lhs 
+
+* [2]  12_Conclusion.lhs
+
+
+
+Harvard Plan
+------------
+
+* [5] 00_Motivation: "Go Wrong"
+
+* [5] 01_SimpleRefinements (upto VC, Abs, but no Kvar)
+
+* [10] 02_Measures [TODO: cut RED-BLACK]
+    + Demo : 00_Refinements.hs (upto "wtAverage")
+    + Demo : 01_Elements.hs
+
+* [5] 04_Abstract Refinements
+    + Demo : 02_AbstractRefinements.hs (listMax)
+	
+* [5] 06_Inductive
+	+ Describe: [TODO: CUT ?foldn] foldr
+    + Demo:  02_AbstractRefinements.hs (foldr, append, filter)
+
+* [5] 08_Recursive
+	+ Describe: list-ord
+	+ Demo:  02_AbstractRefinements.hs (insertSort, ifoldr-insertSort)
+
+	+ Show:  GhcListSort.hs 
+	+ Describe: tree-ord
+	+ [TODO: CUT] Demo:     RBTree-Ord
+	+ Demo:     Stream
+
+* [TODO: CUT] [5] 07_Array
+  [TODO: CUT] 	+ Describe: Array
+  [TODO: CUT] 	+ Demo:     KMP
+  
+* [3] 11_Evaluation.lhs 
+
+* [2] 12_Conclusion.lhs
+
+Bytestring Details
+------------------
+
+-- | A variety of 'head' for non-empty ByteStrings. 'unsafeHead' omits
+-- the check for the empty case, which is good for performance, but
+-- there is an obligation on the programmer to provide a proof that the
+-- ByteString is non-empty.
+{-@ unsafeHead :: ByteStringNE -> Char @-}
+unsafeHead :: ByteString -> Char
+unsafeHead  = w2c . B.unsafeHead
+{-# INLINE unsafeHead #-}
+
+
+type ByteStringNE = {v:ByteString | 0 < bLength v}
+
+
+-- | Unsafe 'ByteString' index (subscript) operator, starting from 0, returning a 'Word8'
+-- This omits the bounds check, which means there is an accompanying
+-- obligation on the programmer to ensure the bounds are checked in some
+-- other way.
+
+{-@ type OkIdx B = {v:Nat | v < bLength B} @-}
+
+{-@ unsafeIndex :: b:ByteString -> OkIdx b -> Word8 @-}
+unsafeIndex :: ByteString -> Int -> Word8
+unsafeIndex (PS x s l) i = assert (i >= 0 && i < l) $
+    inlinePerformIO $ withForeignPtr x $ \p -> peekByteOff p (s+i)
+
+
+Low-Level Memory
+----------------
+
+1. "Haskell HeartBleed" (using BS)
+
+2. Memory API (calls out to C)
+	+ mallocForeignPtrBytes
+	+ withForeignPtr 
+	+ peek
+	+ poke
+	+ plusPtr
+
+   First with types, then with Refined Types.
+
+3. Examples
+    + okPtr
+	+ badPtr (replace 3 with 6)
+
+4. `ByteString`
+   + invariant 
+   + goodBS1, goodBS2
+   + badBS1, badBS2
+
+5. `create`
+   + good call
+   + bad call
+   
+6. `pack`
+7. `unpack`
+8. `unsafeTake`
+9. `heartBleed` redux.
+
+`peekByteOff p i == peek (p `plusPtr` i)`
+
+\begin{code}
+module BSCrash where
+
+import Data.ByteString.Char8  as C
+import Data.ByteString        as B
+import Data.ByteString.Unsafe as U
+
+heartBleed s n = s'
+  where 
+    b          = C.pack s         -- "Ranjit"
+    b'         = U.unsafeTake n b -- 20
+    s'         = C.unpack b'
+
+-- > let ex = "Ranjit Loves Burritos"
+    
+-- > heartBleed ex 1
+--   "R"
+    
+-- > heartBleed ex 6
+-- > "Ranjit"
+
+-- > heartBleed ex 10
+-- > "Ranjit Lov"
+    
+-- > heartBleed ex 30
+-- > "Ranjit Loves Burritos\NUL\NUL\NUL\201\&1j\DC3\SOH\NUL"
+\end{code}
diff --git a/docs/slides/BOS14/_support/liquid.css b/docs/slides/BOS14/_support/liquid.css
new file mode 100644
--- /dev/null
+++ b/docs/slides/BOS14/_support/liquid.css
@@ -0,0 +1,105 @@
+
+/******************************************************************/
+/* LIQUID: Hacking the Background *********************************/
+/******************************************************************/
+
+.hidden {
+  display: none;
+}
+
+.reveal .hs-linenum {
+  color: #B2B2B2; 
+  font-style: italic;
+  font-size:70%
+}
+
+.hs-error {
+  background-color: #FF8585 ;
+}
+
+.hs-keyglyph {
+  color: #007020
+}
+
+.hs-keyword {
+  color: #007020;
+}
+
+.hs-comment, .hs-comment a {color: green;}
+
+.hs-str, .hs-chr {color: teal;}
+
+.hs-conid { 
+  color: #902000;   
+}
+
+.hs-definition { 
+  color: #06287E 
+}
+
+.hs-varid, .hs-varop, .hs-layout {
+  color: black; 
+}
+
+.hs-num {
+  color: #40A070;
+}
+
+.hs-conop {
+  color: #902000; 
+}
+
+.hs-cpp {
+  color: orange;
+}
+
+.hs-sel  {}
+
+a.annot {
+  position:relative; 
+  color:#000;
+  text-decoration:none; 
+  white-space: pre; 
+}
+
+a.annot:hover { 
+  z-index:25; 
+  background-color: #D8D8D8;
+}
+
+a.annot span.annottext {display: none}
+
+a.annot:hover span.annottext { 
+  
+  border-radius: 5px 5px;
+  
+  -moz-border-radius: 5px; 
+  -webkit-border-radius: 5px; 
+  
+  box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.1); 
+  -webkit-box-shadow: 5px 5px rgba(0, 0, 0, 0.1);
+  -moz-box-shadow: 5px 5px rgba(0, 0, 0, 0.1); 
+
+  font-size: 75%;
+  white-space:pre;
+  display:block;
+  position: absolute; 
+  left: 1em; top: 2em; 
+  z-index: 99;
+  margin-left: 5; 
+  background: #FFFFAA; 
+  border: 3px solid #FFAD33;
+  padding: 0.8em 1em;
+  color:black;
+}
+
+pre {
+  background-color: #f0f0f0;
+  border-top: 1px solid #ccc;
+  border-bottom: 1px solid #ccc;
+  padding: 5px;
+  font-size: 100%;
+  display: block;
+  overflow: visible;
+}
+
diff --git a/docs/slides/BOS14/_support/liquidhaskell.css b/docs/slides/BOS14/_support/liquidhaskell.css
new file mode 100644
--- /dev/null
+++ b/docs/slides/BOS14/_support/liquidhaskell.css
@@ -0,0 +1,105 @@
+
+/******************************************************************/
+/* LIQUID: Hacking the Background *********************************/
+/******************************************************************/
+
+.hidden {
+  display: none;
+}
+
+.reveal .hs-linenum {
+  color: #B2B2B2; 
+  font-style: italic;
+  font-size:70%
+}
+
+.hs-error {
+  background-color: #FF8585 ;
+}
+
+.hs-keyglyph {
+  color: #007020
+}
+
+.hs-keyword {
+  color: #007020;
+}
+
+.hs-comment, .hs-comment a {color: green;}
+
+.hs-str, .hs-chr {color: teal;}
+
+.hs-conid { 
+  color: #902000;   
+}
+
+.hs-definition { 
+  color: #06287E 
+}
+
+.hs-varid, .hs-varop, .hs-layout {
+  color: black; 
+}
+
+.hs-num {
+  color: #40A070;
+}
+
+.hs-conop {
+  color: #902000; 
+}
+
+.hs-cpp {
+  color: orange;
+}
+
+.hs-sel  {}
+
+a.annot {
+  position:relative; 
+  color:#000;
+  text-decoration:none; 
+  white-space: pre; 
+}
+
+a.annot:hover { 
+  z-index:25; 
+  background-color: #D8D8D8;
+}
+
+a.annot span.annottext {display: none}
+
+a.annot:hover span.annottext { 
+  
+  border-radius: 5px 5px;
+  
+  -moz-border-radius: 5px; 
+  -webkit-border-radius: 5px; 
+  
+  box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.1); 
+  -webkit-box-shadow: 5px 5px rgba(0, 0, 0, 0.1);
+  -moz-box-shadow: 5px 5px rgba(0, 0, 0, 0.1); 
+
+  font-size: 75%;
+  white-space:pre;
+  display:block;
+  position: absolute; 
+  left: 1em; top: 2em; 
+  z-index: 99;
+  margin-left: 5; 
+  background: #FFFFAA; 
+  border: 3px solid #FFAD33;
+  padding: 0.8em 1em;
+  color:black;
+}
+
+pre {
+  background-color: #f0f0f0;
+  border-top: 1px solid #ccc;
+  border-bottom: 1px solid #ccc;
+  padding: 5px;
+  font-size: 100%;
+  display: block;
+  overflow: visible;
+}
+
diff --git a/docs/slides/BOS14/_support/reveal.js/.travis.yml b/docs/slides/BOS14/_support/reveal.js/.travis.yml
new file mode 100644
--- /dev/null
+++ b/docs/slides/BOS14/_support/reveal.js/.travis.yml
@@ -0,0 +1,5 @@
+language: node_js
+node_js:
+  - 0.8
+before_script:
+  - npm install -g grunt-cli
diff --git a/docs/slides/BOS14/_support/reveal.js/Gruntfile.js b/docs/slides/BOS14/_support/reveal.js/Gruntfile.js
new file mode 100644
--- /dev/null
+++ b/docs/slides/BOS14/_support/reveal.js/Gruntfile.js
@@ -0,0 +1,137 @@
+/* global module:false */
+module.exports = function(grunt) {
+	var port = grunt.option('port') || 8000;
+	// Project configuration
+	grunt.initConfig({
+		pkg: grunt.file.readJSON('package.json'),
+		meta: {
+			banner:
+				'/*!\n' +
+				' * reveal.js <%= pkg.version %> (<%= grunt.template.today("yyyy-mm-dd, HH:MM") %>)\n' +
+				' * http://lab.hakim.se/reveal-js\n' +
+				' * MIT licensed\n' +
+				' *\n' +
+				' * Copyright (C) 2014 Hakim El Hattab, http://hakim.se\n' +
+				' */'
+		},
+
+		qunit: {
+			files: [ 'test/*.html' ]
+		},
+
+		uglify: {
+			options: {
+				banner: '<%= meta.banner %>\n'
+			},
+			build: {
+				src: 'js/reveal.js',
+				dest: 'js/reveal.min.js'
+			}
+		},
+
+		cssmin: {
+			compress: {
+				files: {
+					'css/reveal.min.css': [ 'css/reveal.css' ]
+				}
+			}
+		},
+
+		sass: {
+			main: {
+				files: {
+					'css/theme/default.css': 'css/theme/source/default.scss',
+					'css/theme/beige.css': 'css/theme/source/beige.scss',
+					'css/theme/night.css': 'css/theme/source/night.scss',
+					'css/theme/serif.css': 'css/theme/source/serif.scss',
+					'css/theme/simple.css': 'css/theme/source/simple.scss',
+					'css/theme/sky.css': 'css/theme/source/sky.scss',
+					'css/theme/moon.css': 'css/theme/source/moon.scss',
+					'css/theme/solarized.css': 'css/theme/source/solarized.scss',
+					'css/theme/blood.css': 'css/theme/source/blood.scss'
+				}
+			}
+		},
+
+		jshint: {
+			options: {
+				curly: false,
+				eqeqeq: true,
+				immed: true,
+				latedef: true,
+				newcap: true,
+				noarg: true,
+				sub: true,
+				undef: true,
+				eqnull: true,
+				browser: true,
+				expr: true,
+				globals: {
+					head: false,
+					module: false,
+					console: false,
+					unescape: false
+				}
+			},
+			files: [ 'Gruntfile.js', 'js/reveal.js' ]
+		},
+
+		connect: {
+			server: {
+				options: {
+					port: port,
+					base: '.'
+				}
+			}
+		},
+
+		zip: {
+			'reveal-js-presentation.zip': [
+				'index.html',
+				'css/**',
+				'js/**',
+				'lib/**',
+				'images/**',
+				'plugin/**'
+			]
+		},
+
+		watch: {
+			main: {
+				files: [ 'Gruntfile.js', 'js/reveal.js', 'css/reveal.css' ],
+				tasks: 'default'
+			},
+			theme: {
+				files: [ 'css/theme/source/*.scss', 'css/theme/template/*.scss' ],
+				tasks: 'themes'
+			}
+		}
+
+	});
+
+	// Dependencies
+	grunt.loadNpmTasks( 'grunt-contrib-qunit' );
+	grunt.loadNpmTasks( 'grunt-contrib-jshint' );
+	grunt.loadNpmTasks( 'grunt-contrib-cssmin' );
+	grunt.loadNpmTasks( 'grunt-contrib-uglify' );
+	grunt.loadNpmTasks( 'grunt-contrib-watch' );
+	grunt.loadNpmTasks( 'grunt-contrib-sass' );
+	grunt.loadNpmTasks( 'grunt-contrib-connect' );
+	grunt.loadNpmTasks( 'grunt-zip' );
+
+	// Default task
+	grunt.registerTask( 'default', [ 'jshint', 'cssmin', 'uglify', 'qunit' ] );
+
+	// Theme task
+	grunt.registerTask( 'themes', [ 'sass' ] );
+
+	// Package presentation to archive
+	grunt.registerTask( 'package', [ 'default', 'zip' ] );
+
+	// Serve presentation locally
+	grunt.registerTask( 'serve', [ 'connect', 'watch' ] );
+
+	// Run tests
+	grunt.registerTask( 'test', [ 'jshint', 'qunit' ] );
+
+};
diff --git a/docs/slides/BOS14/_support/reveal.js/LICENSE b/docs/slides/BOS14/_support/reveal.js/LICENSE
new file mode 100644
--- /dev/null
+++ b/docs/slides/BOS14/_support/reveal.js/LICENSE
@@ -0,0 +1,19 @@
+Copyright (C) 2014 Hakim El Hattab, http://hakim.se
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.
diff --git a/docs/slides/BOS14/_support/reveal.js/README.md b/docs/slides/BOS14/_support/reveal.js/README.md
new file mode 100644
--- /dev/null
+++ b/docs/slides/BOS14/_support/reveal.js/README.md
@@ -0,0 +1,933 @@
+# reveal.js [![Build Status](https://travis-ci.org/hakimel/reveal.js.png?branch=master)](https://travis-ci.org/hakimel/reveal.js)
+
+A framework for easily creating beautiful presentations using HTML. [Check out the live demo](http://lab.hakim.se/reveal-js/).
+
+reveal.js comes with a broad range of features including [nested slides](https://github.com/hakimel/reveal.js#markup), [markdown contents](https://github.com/hakimel/reveal.js#markdown), [PDF export](https://github.com/hakimel/reveal.js#pdf-export), [speaker notes](https://github.com/hakimel/reveal.js#speaker-notes) and a [JavaScript API](https://github.com/hakimel/reveal.js#api). It's best viewed in a browser with support for CSS 3D transforms but [fallbacks](https://github.com/hakimel/reveal.js/wiki/Browser-Support) are available to make sure your presentation can still be viewed elsewhere.
+
+
+#### More reading:
+- [Installation](#installation): Step-by-step instructions for getting reveal.js running on your computer.
+- [Changelog](https://github.com/hakimel/reveal.js/releases): Up-to-date version history.
+- [Examples](https://github.com/hakimel/reveal.js/wiki/Example-Presentations): Presentations created with reveal.js, add your own!
+- [Browser Support](https://github.com/hakimel/reveal.js/wiki/Browser-Support): Explanation of browser support and fallbacks.
+
+## Online Editor
+
+Presentations are written using HTML or markdown but there's also an online editor for those of you who prefer a graphical interface. Give it a try at [http://slid.es](http://slid.es).
+
+
+## Instructions
+
+### Markup
+
+Markup hierarchy needs to be ``
 
 
`` where the ``
`` represents one slide and can be repeated indefinitely. If you place multiple ``
``'s inside of another ``
`` they will be shown as vertical slides. The first of the vertical slides is the "root" of the others (at the top), and it will be included in the horizontal sequence. For example:
+
+```html
+

+	

+		
Single Horizontal Slide

+		

+			
Vertical Slide 1

+			
Vertical Slide 2

+		

+	

+

+```
+
+### Markdown
+
+It's possible to write your slides using Markdown. To enable Markdown, add the ```data-markdown``` attribute to your ```
``` elements and wrap the contents in a ```
+

+```
+
+#### External Markdown
+
+You can write your content as a separate file and have reveal.js load it at runtime. Note the separator arguments which determine how slides are delimited in the external file. The ```data-charset``` attribute is optional and specifies which charset to use when loading the external file.
+
+When used locally, this feature requires that reveal.js [runs from a local web server](#full-setup).
+
+```html
+

+

+```
+
+#### Element Attributes
+
+Special syntax (in html comment) is available for adding attributes to Markdown elements. This is useful for fragments, amongst other things.
+
+```html
+

+	
+

+```
+
+#### Slide Attributes
+
+Special syntax (in html comment) is available for adding attributes to the slide `
` elements generated by your Markdown.
+
+```html
+

+	
+

+```
+
+
+### Configuration
+
+At the end of your page you need to initialize reveal by running the following code. Note that all config values are optional and will default as specified below.
+
+```javascript
+Reveal.initialize({
+
+	// Display controls in the bottom right corner
+	controls: true,
+
+	// Display a presentation progress bar
+	progress: true,
+
+	// Display the page number of the current slide
+	slideNumber: false,
+
+	// Push each slide change to the browser history
+	history: false,
+
+	// Enable keyboard shortcuts for navigation
+	keyboard: true,
+
+	// Enable the slide overview mode
+	overview: true,
+
+	// Vertical centering of slides
+	center: true,
+
+	// Enables touch navigation on devices with touch input
+	touch: true,
+
+	// Loop the presentation
+	loop: false,
+
+	// Change the presentation direction to be RTL
+	rtl: false,
+
+	// Turns fragments on and off globally
+	fragments: true,
+
+	// Flags if the presentation is running in an embedded mode,
+	// i.e. contained within a limited portion of the screen
+	embedded: false,
+
+	// Number of milliseconds between automatically proceeding to the
+	// next slide, disabled when set to 0, this value can be overwritten
+	// by using a data-autoslide attribute on your slides
+	autoSlide: 0,
+
+	// Stop auto-sliding after user input
+	autoSlideStoppable: true,
+
+	// Enable slide navigation via mouse wheel
+	mouseWheel: false,
+
+	// Hides the address bar on mobile devices
+	hideAddressBar: true,
+
+	// Opens links in an iframe preview overlay
+	previewLinks: false,
+
+	// Transition style
+	transition: 'default', // default/cube/page/concave/zoom/linear/fade/none
+
+	// Transition speed
+	transitionSpeed: 'default', // default/fast/slow
+
+	// Transition style for full page slide backgrounds
+	backgroundTransition: 'default', // default/none/slide/concave/convex/zoom
+
+	// Number of slides away from the current that are visible
+	viewDistance: 3,
+
+	// Parallax background image
+	parallaxBackgroundImage: '', // e.g. "'https://s3.amazonaws.com/hakim-static/reveal-js/reveal-parallax-1.jpg'"
+
+	// Parallax background size
+	parallaxBackgroundSize: '' // CSS syntax, e.g. "2100px 900px"
+
+
+});
+```
+
+Note that the new default vertical centering option will break compatibility with slides that were using transitions with backgrounds (`cube` and `page`). To restore the previous behavior, set `center` to `false`.
+
+
+The configuration can be updated after initialization using the ```configure``` method:
+
+```javascript
+// Turn autoSlide off
+Reveal.configure({ autoSlide: 0 });
+
+// Start auto-sliding every 5s
+Reveal.configure({ autoSlide: 5000 });
+```
+
+
+### Dependencies
+
+Reveal.js doesn't _rely_ on any third party scripts to work but a few optional libraries are included by default. These libraries are loaded as dependencies in the order they appear, for example:
+
+```javascript
+Reveal.initialize({
+	dependencies: [
+		// Cross-browser shim that fully implements classList - https://github.com/eligrey/classList.js/
+		{ src: 'lib/js/classList.js', condition: function() { return !document.body.classList; } },
+
+		// Interpret Markdown in 
 elements
+		{ src: 'plugin/markdown/marked.js', condition: function() { return !!document.querySelector( '[data-markdown]' ); } },
+		{ src: 'plugin/markdown/markdown.js', condition: function() { return !!document.querySelector( '[data-markdown]' ); } },
+
+		// Syntax highlight for  elements
+		{ src: 'plugin/highlight/highlight.js', async: true, callback: function() { hljs.initHighlightingOnLoad(); } },
+
+		// Zoom in and out with Alt+click
+		{ src: 'plugin/zoom-js/zoom.js', async: true, condition: function() { return !!document.body.classList; } },
+
+		// Speaker notes
+		{ src: 'plugin/notes/notes.js', async: true, condition: function() { return !!document.body.classList; } },
+
+		// Remote control your reveal.js presentation using a touch device
+		{ src: 'plugin/remotes/remotes.js', async: true, condition: function() { return !!document.body.classList; } },
+
+		// MathJax
+		{ src: 'plugin/math/math.js', async: true }
+	]
+});
+```
+
+You can add your own extensions using the same syntax. The following properties are available for each dependency object:
+- **src**: Path to the script to load
+- **async**: [optional] Flags if the script should load after reveal.js has started, defaults to false
+- **callback**: [optional] Function to execute when the script has loaded
+- **condition**: [optional] Function which must return true for the script to be loaded
+
+
+### Presentation Size
+
+All presentations have a normal size, that is the resolution at which they are authored. The framework will automatically scale presentations uniformly based on this size to ensure that everything fits on any given display or viewport.
+
+See below for a list of configuration options related to sizing, including default values:
+
+```javascript
+Reveal.initialize({
+
+	...
+
+	// The "normal" size of the presentation, aspect ratio will be preserved
+	// when the presentation is scaled to fit different resolutions. Can be
+	// specified using percentage units.
+	width: 960,
+	height: 700,
+
+	// Factor of the display size that should remain empty around the content
+	margin: 0.1,
+
+	// Bounds for smallest/largest possible scale to apply to content
+	minScale: 0.2,
+	maxScale: 1.0
+
+});
+```
+
+
+### Auto-sliding
+
+Presentations can be configure to progress through slides automatically, without any user input. To enable this you will need to tell the framework how many milliseconds it should wait between slides:
+
+```javascript
+// Slide every five seconds
+Reveal.configure({
+  autoSlide: 5000
+});
+```
+
+When this is turned on a control element will appear that enables users to pause and resume auto-sliding. Sliding is also paused automatically as soon as the user starts navigating. You can disable these controls by specifying ```autoSlideStoppable: false``` in your reveal.js config.
+
+You can also override the slide duration for individual slides by using the ```data-autoslide``` attribute on individual sections:
+
+```html
+
This will remain on screen for 10 seconds

+```
+
+
+### Keyboard Bindings
+
+If you're unhappy with any of the default keyboard bindings you can override them using the ```keyboard``` config option:
+
+```javascript
+Reveal.configure({
+  keyboard: {
+    13: 'next', // go to the next slide when the ENTER key is pressed
+    27: function() {}, // do something custom when ESC is pressed
+    32: null // don't do anything when SPACE is pressed (i.e. disable a reveal.js default binding)
+  }
+});
+```
+
+
+### API
+
+The ``Reveal`` class provides a JavaScript API for controlling navigation and reading state:
+
+```javascript
+// Navigation
+Reveal.slide( indexh, indexv, indexf );
+Reveal.left();
+Reveal.right();
+Reveal.up();
+Reveal.down();
+Reveal.prev();
+Reveal.next();
+Reveal.prevFragment();
+Reveal.nextFragment();
+Reveal.toggleOverview();
+Reveal.togglePause();
+
+// Retrieves the previous and current slide elements
+Reveal.getPreviousSlide();
+Reveal.getCurrentSlide();
+
+Reveal.getIndices(); // { h: 0, v: 0 } }
+
+// State checks
+Reveal.isFirstSlide();
+Reveal.isLastSlide();
+Reveal.isOverview();
+Reveal.isPaused();
+```
+
+### Ready Event
+
+The 'ready' event is fired when reveal.js has loaded all (synchronous) dependencies and is ready to start navigating.
+
+```javascript
+Reveal.addEventListener( 'ready', function( event ) {
+	// event.currentSlide, event.indexh, event.indexv
+} );
+```
+
+### Slide Changed Event
+
+An 'slidechanged' event is fired each time the slide is changed (regardless of state). The event object holds the index values of the current slide as well as a reference to the previous and current slide HTML nodes.
+
+Some libraries, like MathJax (see [#226](https://github.com/hakimel/reveal.js/issues/226#issuecomment-10261609)), get confused by the transforms and display states of slides. Often times, this can be fixed by calling their update or render function from this callback.
+
+```javascript
+Reveal.addEventListener( 'slidechanged', function( event ) {
+	// event.previousSlide, event.currentSlide, event.indexh, event.indexv
+} );
+```
+
+
+### States
+
+If you set ``data-state="somestate"`` on a slide ``
``, "somestate" will be applied as a class on the document element when that slide is opened. This allows you to apply broad style changes to the page based on the active slide.
+
+Furthermore you can also listen to these changes in state via JavaScript:
+
+```javascript
+Reveal.addEventListener( 'somestate', function() {
+	// TODO: Sprinkle magic
+}, false );
+```
+
+### Slide Backgrounds
+
+Slides are contained within a limited portion of the screen by default to allow them to fit any display and scale uniformly. You can apply full page background colors or images by applying a ```data-background``` attribute to your ```
``` elements. Below are a few examples.
+
+```html
+

+	
All CSS color formats are supported, like rgba() or hsl().

+

+

+	
This slide will have a full-size background image.

+

+

+	
This background image will be sized to 100px and repeated.

+

+```
+
+Backgrounds transition using a fade animation by default. This can be changed to a linear sliding transition by passing ```backgroundTransition: 'slide'``` to the ```Reveal.initialize()``` call. Alternatively you can set ```data-background-transition``` on any section with a background to override that specific transition.
+
+
+### Parallax Background
+
+If you want to use a parallax scrolling background, set the two following config properties when initializing reveal.js (the third one is optional).
+
+```javascript
+Reveal.initialize({
+
+	// Parallax background image
+	parallaxBackgroundImage: '', // e.g. "https://s3.amazonaws.com/hakim-static/reveal-js/reveal-parallax-1.jpg"
+
+	// Parallax background size
+	parallaxBackgroundSize: '', // CSS syntax, e.g. "2100px 900px" - currently only pixels are supported (don't use % or auto)
+
+	// This slide transition gives best results:
+	transition: linear
+
+});
+```
+
+Make sure that the background size is much bigger than screen size to allow for some scrolling. [View example](http://lab.hakim.se/reveal-js/?parallaxBackgroundImage=https%3A%2F%2Fs3.amazonaws.com%2Fhakim-static%2Freveal-js%2Freveal-parallax-1.jpg¶llaxBackgroundSize=2100px%20900px).
+
+
+
+### Slide Transitions
+The global presentation transition is set using the ```transition``` config value. You can override the global transition for a specific slide by using the ```data-transition``` attribute:
+
+```html
+

+	
This slide will override the presentation transition and zoom!

+

+
+

+	
Choose from three transition speeds: default, fast or slow!

+

+```
+
+Note that this does not work with the page and cube transitions.
+
+
+### Internal links
+
+It's easy to link between slides. The first example below targets the index of another slide whereas the second targets a slide with an ID attribute (```
```):
+
+```html
+Link
+Link
+```
+
+You can also add relative navigation links, similar to the built in reveal.js controls, by appending one of the following classes on any element. Note that each element is automatically given an ```enabled``` class when it's a valid navigation route based on the current slide.
+
+```html
+
+
+
+
+ 
+ 
+```
+
+
+### Fragments
+Fragments are used to highlight individual elements on a slide. Every element with the class ```fragment``` will be stepped through before moving on to the next slide. Here's an example: http://lab.hakim.se/reveal-js/#/fragments
+
+The default fragment style is to start out invisible and fade in. This style can be changed by appending a different class to the fragment:
+
+```html
+

+	
grow

+	
shrink

+	
roll-in

+	
fade-out

+	
visible only once

+	
blue only once

+	
highlight-red

+	
highlight-green

+	
highlight-blue

+

+```
+
+Multiple fragments can be applied to the same element sequentially by wrapping it, this will fade in the text on the first step and fade it back out on the second.
+
+```html
+

+	
+		I'll fade in, then out
+	
+

+```
+
+The display order of fragments can be controlled using the ```data-fragment-index``` attribute.
+
+```html
+

+	
Appears last

+	
Appears first

+	
Appears second

+

+```
+
+### Fragment events
+
+When a slide fragment is either shown or hidden reveal.js will dispatch an event.
+
+Some libraries, like MathJax (see #505), get confused by the initially hidden fragment elements. Often times this can be fixed by calling their update or render function from this callback.
+
+```javascript
+Reveal.addEventListener( 'fragmentshown', function( event ) {
+	// event.fragment = the fragment DOM element
+} );
+Reveal.addEventListener( 'fragmenthidden', function( event ) {
+	// event.fragment = the fragment DOM element
+} );
+```
+
+### Code syntax highlighting
+
+By default, Reveal is configured with [highlight.js](http://softwaremaniacs.org/soft/highlight/en/) for code syntax highlighting. Below is an example with clojure code that will be syntax highlighted. When the `data-trim` attribute is present surrounding whitespace is automatically removed.
+
+```html
+

+	

+(def lazy-fib
+  (concat
+   [0 1]
+   ((fn rfib [a b]
+        (lazy-cons (+ a b) (rfib b (+ a b)))) 0 1)))
+	

+

+```
+
+### Slide number
+If you would like to display the page number of the current slide you can do so using the ```slideNumber``` configuration value.
+
+```javascript
+Reveal.configure({ slideNumber: true });
+```
+
+
+### Overview mode
+
+Press "Esc" or "o" keys to toggle the overview mode on and off. While you're in this mode, you can still navigate between slides,
+as if you were at 1,000 feet above your presentation. The overview mode comes with a few API hooks:
+
+```javascript
+Reveal.addEventListener( 'overviewshown', function( event ) { /* ... */ } );
+Reveal.addEventListener( 'overviewhidden', function( event ) { /* ... */ } );
+
+// Toggle the overview mode programmatically
+Reveal.toggleOverview();
+```
+
+### Fullscreen mode
+Just press »F« on your keyboard to show your presentation in fullscreen mode. Press the »ESC« key to exit fullscreen mode.
+
+
+### Embedded media
+Embedded HTML5 `