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

Transcript

1. DEPENDENT TYPES, NOT JUST FOR VECTORS? FP-SYD 2017
2. WHO AM I? ▸ Tim McGilchrist @lambda_foo ▸ Haskell programmer at Ambiata ▸ Curious about Distributed Systems ▸ Curious about Types
3. BACKGROUND HOW DID I GET HERE?
4. ACTORS AND ERLANG Mailbox Process
5. SESSION TYPES ▸ Describe communication protocols ▸ Session types codify the structure of communication ▸ Data types codify the structures communicated
6. PROBLEMS
7. (X : TYPE) -> TYPE -> (X -> TYPE) -> TYPE EFFECT SYSTEMS ▸ Available in Idris and Purescript ▸ Use effects to model state machines.
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?
9. IDRIS IS A PACMAN COMPLETE LANGUAGE Edwin Brady
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.
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"
12. GENERALISING STATEFUL PROGRAMS ▸ Types should capture the states of resources ▸ Stateful APIs should compose ▸ Types should be readable ▸ Error messages should be readable
13. ENTER STRANS ▸ m - underlying monad ▸ ty - result type of the program ▸ in_ctxt - input context ▸ out_ctxt
14. DATASTORE
15. USING DATASTORE
16. TEXT
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
18. STATE PLUS DATASTORE
19. TEXT CLEANING UP THE TYPES ▸ Type level function ST ▸ List of actions on resources
20. DATASTORE - CLEAN
21. TEXT PRETTY ERRORS
22. TEXT CONCLUSION ▸ Need to tie this back to Actors. ▸ Encoding State Machines. ▸ Session Types ▸ Effect Systems
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/