[<<][meta][>>][..]

Tue Aug 16 11:56:21 CEST 2011

## Kleisli arrows

Let's assume that the Monad trouble from the previous entries can be
solved. The resulting structure is quite neat.
The basic idea is that the monad values are signals, and processors
are represented by the corresponding Kleisli arrows.
{- Signal operators are Kleisli arrows of the monad. -}
type Opr s i o = i -> Sig s o
_kleisli :: Opr s1 a b -> Opr s2 b c -> Opr (s1,s2) a c
_kleisli f g = \x -> (f x) `_bind` g
I still think the way the type looks is a bit ugly, so I'm using a
translation from something that is easier to work with:
{- Convert a convenient state space model sigature to a Kleisli arrow. -}
_signal :: s -> ((s,i) -> (s,o)) -> Opr s i o
_signal s0 f = f' where
f' i = Sig s0 u where
u s = (o, s') where
(s',o) = f (s,i)
Anwyays. Enter blog post of Dan Piponi[1], who seems to be going into
an entirely different way implementing causal stream functions.
However, his stream functions do not seem to be recursive (FIR but no
IIR).
So how to use kleisli arrows in do notation?
Creating a signal that is twice the integral of the constant 1:
do
one <- return 1
ramp <- int one
square <- int ramp
There doesn't seem to be much of an issue. Though this only works if
int is not wrapped in a class, but is a "naked" arrow a -> M b.
The moral of the story seems to be: if binding (variable names,
applicative programming, value-oriented programming) is required, then
it's best to just use do notation. For "operator algebra" it's best
to use the arrows as objects themselves.
[1] http://blog.sigfpe.com/2006/06/monads-kleisli-arrows-comonads-and.html

[Reply][About]

[<<][meta][>>][..]