Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Dependently Typed State Machines

Dependently Typed State Machines

State machines naturally occur in software systems we write, with many components reling on state as a core principle. We use state machines to describe things like TCP/IP networking, distributed algorithms and everyones favourite regular expressions.
Think about things as simple as network sockets or database connections, these are implicitly stateful. It only makes sense to perform a read on a socket that is open and has data available. Likewise you can't send an SQL statement to a closed database connection.

State machines also occur naturally in various protocols like distributed consenseus algorithms like PAXOS or RAFT.

Despite the ubiquity of state machines they aren't typically checked by compilers even in strongly typed languages like Haskell or OCaml.

In this talk we will look at approaches to using dependent typing to provide extra safety in encoding state machines, using both Haskell and Idris. And look at how we can introduce dependent types into our code without making the types incomprehensible and difficult to work with.

The talk is aimed at intermediate level programmers with a familarity with a typed programming langauge like Haskell, Idris or OCaml, and aims to provide a motivation for using dependent types in a practical setting. When new techniques and ideas occur in academia it is important that they are investigated and evaluated in a pragmatic way. Only introducing new things if they provide real and measurable benefits. I would like people to get an appreciation of what dependent types could do and how to critially think about new features in a language.

Tim McGilchrist

August 27, 2018
Tweet

More Decks by Tim McGilchrist

Other Decks in Programming

Transcript

  1. WHO AM I? ▸ Tim McGilchrist @lambda_foo ▸ Haskell /

    OCaml programmer at Ansarada ▸ Curious about Distributed Systems ▸ Convinced about Types
  2. IDRIS ▸ general purpose language ▸ full dependent types with

    dependent pattern matching ▸ eager evaluation ▸ interfaces (ala Haskell's type classes) ▸ What if Haskell had full dependent types?
  3. PAPER STATES ALL THE WAY DOWN ▸ "A useful pattern

    in dependently typed programming is to define a state transition system” ▸ “an architecture for dependently typed applications” ▸ “How to implement a state transition system as a dependent type “ ▸ "How to combine state transition systems into a larger system"
  4. GENERALISING STATEFUL PROGRAMS ▸ Types should capture the states of

    resources ▸ Stateful APIs should compose ▸ Types should be readable ▸ Error messages should be readable
  5. THE RECIPE IMPLEMENTING DEPENDENT STATE MACHINES 1. Draw State Diagram

    for the problem 2. Define State Machine as a Type 3. Implement State functions 4. Running State functions
  6. INTERFACE DATASTORE (M : TYPE -> TYPE) WHERE ACCOUNT LOGIN

    AND ACCESS Login (success) Logout Logged In Logged Out Login (failure) Read Secret
  7. (.) : (B -> C) -> (A -> B) ->

    A -> C TYPES OF COMPOSITION ▸ Horizontally - multiple state machines within a function ▸ Vertically - implement state machine in terms of another Examples: Application on top of a Communication Protocol Multiple resources, File IO plus State
  8. VERTICALLY - STATE PLUS DATASTORE ▸ A composite resource is

    built up from a list of other resources. ▸ Use functions split and combine.
  9. LIFT : MONAD M => M T -> STRANS M

    T RES (CONST RES) CLEANING UP THE TYPES ▸ Type level function ST ▸ List of actions on resources
  10. ST : (TYPE -> TYPE) -> (TY : TYPE) ->

    LIST (ACTION TY) -> TYPE RELATED WORK ▸ Algebraic Effects in Idris, Haskell, and Purescript ▸ Encoding State Machines ▸ Session Types ▸ Linear Types
  11. MKRES : LABEL -> TYPE -> RESOURCE RESOURCES ▸ States

    All the Way Down, E Brady ▸ Programming and Reasoning with Algebraic Effects and Dependent Types, E Brady ▸ Idris website http://docs.idris-lang.org/ ▸ Type Driven Design with Idris (book)
  12. ST : (TYPE -> TYPE) -> (TY : TYPE) ->

    LIST (ACTION TY) -> TYPE THANK YOU ▸ What questions do you have? ▸ Do you want to see more code?