Ghost Hunting the Perfect API

( with departed proofs )

 

Unsafe API
Patterns

>:t head
head :: [a] -> a
> head [1,2,3]
1
> head []
*** Exception: Prelude.head: empty list

> head []
-1

Safe API
Patterns

head :: [a] -> a
headMaybe :: [a] -> Maybe a
headMaybe (x:xs) = Just x
headMaybe []     = Nothing
data NonEmpty a = a :| [a]

safeHead :: NonEmpty a -> a
safeHead (x :| xs) = x

Responsibility

Our choice:

  • Handle it
  • Pass it on

 

People will pass responsibility in the same direction the code they call does.

Responsibility

When we restrict what we can do, it’s easier to understand what we can do.

 

 

identity :: a -> a

take :: Int -> [a] -> [a]
length :: [a] -> Int

Case study

-- merge 2 already sorted lists
unsafeMergeBy
  :: (a -> a -> Ordering) -- the comparator
  -> [a] -- first list
  -> [a] -- second list
  -> [a] -- merged list

> x = sortBy compare [4,3,1]
> y = sortBy compare [16,5,6]
> x
[1,3,4]
> y
[5,6,16]


> unsafeMergeBy compare x y
[1,3,4,5,6,16]

> unsafeMergeBy (comparing Down) x y
[5,6,16,1,3,4]

Case study

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi nec metus justo. Aliquam erat volutpat.

-- merge 2 already sorted lists
mergeByMaybe
  :: (a -> a -> Ordering) -- the comparator
  -> [a]
  -> [a]
  -- a merged list
  -- or none if the list passed 
  -- was not sorted
  -> Maybe [a] 

> x = sortBy compare [4,3,1]
> y = sortBy compare [16,5,6]
> fromJust $ mergeByMaybe compare x y
 [1,3,4,5,6,16]

In the Wild

  • Hackage finds 2000 cases of lookup, followed by fromJust
  • Lookup tries to be good, but user has reason to believe key is in map.

How can we reflect constraints on function input values in the function type?

newtype Named name a = Named a
type a ~~ name = Named name a

name :: a -> (forall name. a ~~ name -> t) -> t
name x k = k (coerce x)

class The d a | d -> a where
  the :: d -> a
  default the :: Coercible d a => d -> a
  the = coerce

newtype Named name a = Named a
type a ~~ name = Named name a

phantom type-level names for values

class The d a | d -> a where
  the :: d -> a
  default the :: Coercible d a => d -> a
  the = coerce

A way to introduce names

 
 
name :: a -> (forall name. a ~~ name -> t) -> t
name x k = k (coerce x)

unwrap named values

 
 
newtype SortedBy name a = SortedBy a
instance The (SortedBy name a) a
import qualified Lists as L

sortBy :: ((a -> a -> Ordering) ~~ comp)
       -> [a]
       -> SortedBy comp [a]
sortBy comp xs = coerce (L.sortBy (the comp) xs)

mergeBy :: ((a -> a -> Ordering) ~~ comp)
        -> SortedBy comp [a]
        -> SortedBy comp [a]
        -> SortedBy comp [a]
mergeBy comp xs ys =
  coerce (L.mergeBy (the comp) (the xs) (the ys))

How can we reflect constraints on function input values in the function type?

> name compare $ \gt -> do
    let xs' = sortBy gt xs
        ys' = sortBy gt ys
    print (the (mergeBy gt xs' ys'))

> x = sortBy compare [4,3,1]
> y = sortBy compare [16,5,6]

> unsafeMergeBy (comparing Down) x y
[5,6,16,1,3,4]
> x = sortBy compare [4,3,1]
> y = sortBy compare [16,5,6]

> fromJust $ mergeByMaybe (comparing Down) x y
*** Exception: Maybe.fromJust: Nothing

Benefits

  • mergeBy cannot be called with a different comparator then the sorted lists were created with
  • allow the library user to decide when and how to validate api preconditions are met
  • achieved many of the benefits of dependent and refinement types, whilst only requiring some minor and well understood extensions to haskell2010
> name compare $ \gt -> do
    let xs' = sortBy gt xs
        ys' = sortBy gt ys
    print (the (mergeBy gt xs' ys'))

An additional example

minimum_O1 :: SortedBy comp [a] -> Maybe a
minimum_O1 xs = case the xs of
  []    -> Nothing
  (x:_) -> Just x

Ghostly Proofs

data Proof p = QED
axiom :: String -> Proof p
axiom reason = QED



newtype Rev xs = Rev ()
rev_rev 
  :: Proof (Rev (Rev xs) == xs)
rev_rev = 
  axiom "reverse reverse is identity"

reverse 
  :: ([a] ~~ xs) 
  -> ([a] ~~ Rev xs)
reverse xs = 
  coerce (P.reverse (the xs))
data p == q

Takeaways

  • Use existential names to discuss values at the type level

  • No runtime overhead

  • Give user combinators and proofs to construct their own safety arguments

  • Is it useful?

    • ​maybe, it's one approach

https://twitter.com/_faineance

Links

https://twitter.com/_faineance

Takeaways

  • Use existential names to discuss values at the type level

  • No runtime overhead

  • Give user combinators and proofs to construct their own safety arguments

  • Is it useful?

    • ​maybe, it's one approach

https://twitter.com/_faineance

Simplified Example

 
 
newtype Rev xs = Rev ()

reverse 
  :: ([a] ~~ xs) 
  -> ([a] ~~ Rev xs)
reverse xs = 
  coerce (P.reverse (the xs))

rev_rev 
  :: Proof (Rev (Rev xs) == xs)
rev_rev = 
  axiom "reverse reverse is identity"

Ghostly Proofs

data Proof p = QED
axiom :: Proof p
axiom = QED


data p || q
data p && q
data p == q

andElimL 
  :: Proof (p && q) 
  -> Proof p
or_introL 
  :: p 
  -> Proof (p || q)

-- sitting in phantom type variables- no constructors needed

Usage

 
 
data IsCons xs
data IsNil  xs

pattern IsCons 
  :: Proof (IsCons xs) 
  -> ([a] ~~ xs)
pattern IsNil 
  :: Proof (IsNil xs) 
  -> ([a] ~~ xs)

head 
  :: ([a] ~~ xs ::: IsCons xs) 
  -> a
head xs = 
  Prelude.head (the xs)

name [1,3] $ \xs -> case xs of
  IsCons proof ->
    print (head (xs ...proof))
  IsNil proof  -> print “nada”

Other lemmas

 
 
rev_cons 
  :: Proof (IsCons xs)
  -> Proof (IsCons (Reverse xs))
rev_cons _ = axiom

name xs $ \xs -> case xs of
    IsCons proof ->
      print (head (xs ...proof))
      print (head (reverse xs ...rev_cons proof))
newtype Reverse xs 
  = Reverse Defn

reverse
  :: ([a] ~~ xs) 
  -> ([a] ~~ Reverse xs)
reverse xs = 
  defn 
    (Prelude.reverse (the xs))

Questions

  • How do we decide which props to get newtype wrappers?

  • How do we handle props involving multiple values, eg relationships between values?

Made with Slides.com