Designing a library is a conversation between the library author and the users where perhaps the hardest and most important question is "is this the right thing to offer?". It's my belief that types are a powerful language to carry out this conversation and thus the nature of types illustrate a path to having this conversation go smoothly. This talk investigates this idea via a simple real world example: getting configuration data from the environment. It also tells a parallel story of how the structure of types illustrates tradeoffs in this design space. This power arises from the historical roots of type systems in logic by stealing a powerful concept from Wittgenstein, Gentzen, and Dummett: Logical Harmony.

1. Of Harmony and Stinginess
Applicatives, Monads, and incremental library design
Joseph Tel Abrahamson
@sdbo / tel / jspha
July 2015

2. A story
First Iteration

3. $ cd company-app
$ ./app
*** Exception: CLIENT_ID: getEnv: does not exist (no
environment variable)
$ export CLIENT_ID=b114b7e51f0e6810efeacf80132670
$ ./app
*** Exception: CLIENT_SECRET: getEnv: does not exist
(no environment variable)
$ export CLIENT_SECRET=0400eb02db68230048010d39f63fef08
$ ./app
[log] Starting server
.
.
.
*** Exception: NETWORK_ID: getEnv: does not exist (no
environment variable)
$ ahoiyinyasetinoasyet
bash: ahoiyinyasetinoasyet: command not found
$ rm -rf /

4. We have got to be able to do better, right?

5. Transparent abstraction, to draw apart and disentangle

6. data Config =
Config
{ clientId :: String
, clientSecret :: String
, networkId :: String
} deriving ( Eq, Show )
getConfig :: IO Config
getConfig = do
id <- getEnv “CLIENT_ID”
secret <- getEnv “CLIENT_SECRET”
netid <- getEnv “NETWORK_ID”
return (Config id secret netid)

7. main :: IO ()
main = do
config <- getConfig
server <- Server.start config
{- ... -}
Server.bind config

8. A library
First Iteration

9. A type E a
A “computation” which reads from the
environment to produce a value of type a.
An API get :: String -> E String
Get a single key from the environment.
run :: E a -> IO a
Run the E a “computation” in IO to receive the
promised a value.

10. Instances instance Functor E
With this we can interpret Strings from the
environment as more sophisticated types
instance Monad E
With this we can compose calls to get together to
build larger types like Config

11. Applicative Monad<=

12. Instances instance Functor E
With this we can interpret Strings from the
environment as more sophisticated types
instance Monad E
With this we can compose calls to get together to
build larger types like Config
instance Applicative E
… well, Monad implies this so we might as well
throw it in there, too

13. data Config =
Config
{ clientId :: String
, clientSecret :: String
, networkId :: String
} deriving ( Eq, Show )
getConfig :: E Config
getConfig = do
id <- get “CLIENT_ID”
secret <- get “CLIENT_SECRET”
netid <- get “NETWORK_ID”
return (Config id secret netid)

14. main :: IO ()
main = do
config <- run getConfig
server <- Server.start config
{- ... -}
Server.bind config

15. Is this the right design to offer?

16. Let’s talk about types

17. zero :: Nat
succ :: Nat -> Nat
A type
An operation

18. unwind :: Nat -> (r -> r) -> (r -> r)
:: (r -> r) -> r -> (Nat -> r)
:: (r -> r, r) -> (Nat -> r)
unwind :: (r -> r, r) -> (Nat -> r)
unwind (succ, zero) n = {- ... -}

19. data Nat = Zero | Wind Nat

20. -- the data type
data Nat = Zero | Wind Nat
-- the introductory side of the API
zero :: Nat
wind :: Nat -> Nat
-- the elimination side of the API
unwind :: (r -> r, r) -> (Nat -> r)
unwind (wind, zero) n = {- ... -}

21. Things fit together
—- if we let (r ——> Nat)
unwind (wind, zero) :: Nat -> Nat
unwind (wind, zero) == id

22. Logical harmony
Gentzen Wittgenstein Dummett

23. Intros Elims
{Intros, elims, data decls} fit together

24. Harmony

25. {Intros, elims, data decls} of known data types fit together

26. Let’s talk about unknown types

27. Lets talk about libraries
Second Iteration

28. Library design is often API-first

29. concrete = we know everything

30. abstract = some parts are unknown

31. A type E a
A “computation” which reads from the
environment to produce a value of type a.
An API get :: String -> E String
Get a single key from the environment.
run :: E a -> IO a
Run the E a “computation” in IO to receive the
promised a value.

32. get run
E a

33. Is this the right design to offer?

34. My theory
As we discover the “right” API for a library we move
from offering unknown types to concrete ones and must
gradually move to respect logical harmony

35. A corollary
If we offer too much, too quickly on the side of elims or
intros then this lack of balance will eventually be felt

36. Another story
Second Iteration

37. $ cd company-app
$ ./app
*** Exception: Environment requires following vars:
CLIENT_ID, CLIENT_SECRET, NETWORK_ID, TIMEOUT.
$ ./app --help
Some Company, Inc THE APP
Usage: app
Environment:
CLIENT_ID: id for authentication handshake
CLIENT_SECRET: secret for authentication handshake
NETWORK_ID: name for server to listen on
TIMEOUT: milliseconds to wait
$ :)
bash: syntax error near unexpected token `)'

38. A type E a
A “computation” which reads from the
environment to produce a value of type a.
An API get :: String -> E String
Get a single key from the environment.
run :: E a -> IO a
Run the E a “computation” in IO to receive the
promised a value.
examine :: E a -> [String]
Extract from the computation all variables that
will be accessed when run.

39. Instances instance Functor E
With this we can interpret Strings from the
environment as more sophisticated types
instance Monad E
With this we can compose calls to get together to
build larger types like Config
instance Applicative E
… well, Monad implies this so we might as well
throw it in there, too

41. data E a =
E
{ examine :: [String]
, run :: IO a
}

42. data E a =
E
{ examine :: [String]
, run :: IO a
}
deriving instance Functor E
get :: String -> E String
get name = E { examine = [name], run = getEnv name }

43. data E a =
E
{ examine :: [String]
, run :: IO a
}
instance Applicative E where
pure a = E { examine = [], run = return a }
E ns1 io1 <*> ns2 io2 =
E (ns1 ++ ns2) (io1 <*> io2)

44. -- No monad.

45. E a ~ (Const [String] a, IO a)

47. (>>=) :: Const e a -> (a -> Const e b) -> Const e b

48. Const e >>= _ = Const e

49. Applicative Monad<=

50. Applicative T Monad T<=
Given a type T

51. Applicative Monad<

52. Monad run
examine

53. A library
Third Iteration

54. data E a =
E
{ examine :: [String]
, run :: IO a
} derving Functor
instance Applicative (E a) where
pure a = E [] (pure a)
E ns1 io1 <*> E ns2 io2 =
E (ns1 <> ns2) (io1 <*> io2)
get name = E [name] (getEnv name)

55. data Config =
Config
{ clientId :: String
, clientSecret :: String
, networkId :: String
, timeout :: Int
} deriving ( Eq, Show )
getConfig :: E Config
getConfig =
Config
<$> get “CLIENT_ID”
<*> get “CLIENT_SECRET”
<*> get “NETWORK_ID”
<*> fmap read (get “TIMEOUT”)

56. Harmony

57. Thank you

58. “Of Harmony and Stinginess”
Joseph Tel Abrahamson
@sdbo / tel / jspha.com
Questions?