Idris States: Dependent types, not just for vectors?

Idris States: Dependent types, not just for vectors?

Building state machines in our software is a common practice. They are used to model
all kinds of interesting and not so interesting problems like communication protocols,
user accounts and general business processes.

When we build these in a functional language like Haskell we get certain guarantees from
using ADTs, functions and the type system. What is harder is encoding checks and guarantees
around when state transitions are valid. In this talk we will look at how a depdendently typed
language (Idris) can build state machines with further guarantees and correctness.

This talk was inspired by reading Edwin Brady's paper \"State Machines all the way down\"
and much of the code is available at http://docs.idris-lang.org/en/latest/st/index.html

67afd2b4c98c9befd18c19f0ee9d94dc?s=128

Tim McGilchrist

May 24, 2017
Tweet

Transcript

  1. 2.

    WHO AM I? ▸ Tim McGilchrist @lambda_foo ▸ Haskell programmer

    at Ambiata ▸ Curious about Distributed Systems ▸ Curious about Types
  2. 5.

    SESSION TYPES ▸ Describe communication protocols ▸ Session types codify

    the structure of communication ▸ Data types codify the structures communicated
  3. 7.

    (X : TYPE) -> TYPE -> (X -> TYPE) ->

    TYPE EFFECT SYSTEMS ▸ Available in Idris and Purescript ▸ Use effects to model state machines.
  4. 8.

    EFFECT PROBLEMS ▸ "it was not possible to implement one

    effectful API in terms of others" E Brady ▸ "difficult to describe the relationship between separate resources" E Brady ▸ Composing problems?
  5. 10.

    VECTOR LENGTH PROGRAMMING λΠ>:doc Vect Data type Data.Vect.Vect : (len

    : Nat) -> (elem : Type) -> Type Vectors: Generic lists with explicit length in the type Arguments: len : Nat -- the length of the list elem : Type -- the type of elements Constructors: Nil : Vect 0 elem Empty vector (::) : (x : elem) -> (xs : Vect len elem) -> Vect (S len) elem A non-empty vector of length S len, consisting of a head element and the rest of the list, of length len.
  6. 11.

    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"
  7. 12.

    GENERALISING STATEFUL PROGRAMS ▸ Types should capture the states of

    resources ▸ Stateful APIs should compose ▸ Types should be readable ▸ Error messages should be readable
  8. 13.

    ENTER STRANS ▸ m - underlying monad ▸ ty -

    result type of the program ▸ in_ctxt - input context ▸ out_ctxt
  9. 14.
  10. 16.
  11. 17.

    (.) : (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 a Communication Protocol Multiple resources, File IO plus State
  12. 19.
  13. 22.

    TEXT CONCLUSION ▸ Need to tie this back to Actors.

    ▸ Encoding State Machines. ▸ Session Types ▸ Effect Systems
  14. 23.

    TEXT RESOURCES ▸ States All the Way Down, Edwin Brady

    ▸ Programming and Reasoning with Algebraic Effects and Dependent Types, Edwin Brady ▸ Session Types http://simonjf.com/2016/05/28/session- type-implementations.html ▸ Idris website http://docs.idris-lang.org/