I’ve started noticing many pieces of data in my programs that
basically serve as functions: a data type like data Match a = Anything | This a
can be interpreted as a subset of functions Eq a => a -> Bool
, witnessed by the function match :: Eq a => Match a -> a -> Bool
. This talk looked at the connection between functions and data in
a few different ways, focusing more on practical implications than
theoretical ones.
This talk digs into the right-associativity of the (->)
operator. It
is well-known that a -> b -> c
is the same as a -> (b -> c)
. Supplying one argument to a “multi-argument function” will return
a function, but newer functional programmers are often less fluent at
thinking this way. By explicitly writing the “redundant” parentheses,
we can trick our brains into seeing familiar functions in a new light.
This talk is a whirlwind tour of Haskell’s type-level features. We
touch on DataKinds
, GADTs
, ConstraintKinds
, PolyKinds
,
MultiParamTypeClasses
, FunctionalDependencies
, TypeFamilies
, and
ScopedTypeVariables
with small motivating examples. A little
familiarity with these features makes it much easier to trace how
advanced Haskell libraries work their magic. Which is convenient,
because Brad Parker will be following up
with a demonstration of how Servant’s type-level DSL
works.
Functional Reactive Programming (FRP) is often introduced by discussing events and behaviors, and how to transform and mix them. But once you understand the primitives, what do you do with them? Where do the first events come from, and how do you wire these parts into a larger whole?
FRP promises benefits in more domains than just user interfaces, so let’s take a look at Reflex outside its most common habitat of web frontends. There’s now a fairly up-to-date version of Reflex on Hackage, so we can play with it right away and leave GHCjs, Reflex-DOM, special build tools, and the custom nix frameworks for later.
An FRP network of events and behaviors runs inside a library called a “host”, which interfaces between the FRP network and the outside world. Using an interactive OpenGL program as our example, we’ll explore how a slightly larger reactive program hangs together, and how it uses the host’s features to do what it needs to do.