
Monadic I/O and Unix shell programming (2001) - DyslexicAtheist
http://okmij.org/ftp/Computation/monadic-shell.html
======
thinkpad20
The analogy has a couple of problems with it. There is the fact that programs
can be run in parallel, with one program feeding the other output in real
time. This one the article covers although I don’t completely buy their
explanation.

For another example, ‘cmd | cat’ is often not the same thing as ‘cmd’, because
a command can inspect whether stdout is a tty or not and alter its behavior.
This is why ‘ls’ normally outputs all in one line, but changes to one-per-line
when used with a pipe (e.g. grep).

The other issue that comes to mind is that bash provides multiple concepts of
“monadic” sequencing; not just with pipes but with the && and || operators, if
logic, for/while loops, etc, which form a more traditional “imperative
programming” monad. Perhaps bash could be considered then to be a nested monad
(monad transformer?) but I’m not sure how precisely you could model its
semantics while keeping things elegant.

But yes, in general you can view the shell as a monad, and there are libraries
in Haskell which do exactly this (Shelly and Turtle come to mind). In general,
the divergences from a purely monadic model come from the fiddly bits of real-
world programming which can cause edge cases.

------
yanowitz
This is a fun read (fair warning: you should have _some_ understanding of
monoids and monads before reading) and further validates my hypothesis that
understanding category theory would make me a more effective engineer.

If you've had the joy of constructing useful shell pipelines, and part of it
is in the ease of knowing how it will behave. this is a nice formal statement
that the underlying reasons WHY it just “feels right” are because of category
theory--which means if I can just learn category theory, I’ll have a new tool
for approaching and factoring problems that will be, technically speaking,
hella useful.

I suppose I should start (re)working my way through
[https://www.youtube.com/watch?v=I8LbkfSSR58&list=PLbgaMIhjbm...](https://www.youtube.com/watch?v=I8LbkfSSR58&list=PLbgaMIhjbmEnaH_LTkxLI7FMa2HsnawM_)

~~~
yesenadam
I had a look (at the original 2001 article) - seems you have to know Haskell
to understand anything.

~~~
denis1
Edit: The OP expanded that the post was about the linked article... now my
comment doesn't make too much sense.

If you say that about Milewki's talks then I don't agree. He does use Haskell
notation a lot, but gives C examples as well and most of his arguments are
based in category theory/general programming.

Anyway, I think that the series of talks linked in the GP are a must watch.
Even for people that don't fully agree with the viewpoint of Category Theory
being a "holly grail" the videos do provide a different point of
understanding.

~~~
yesenadam
"Milewki's talks"? Don't know what he or that is. Nope, I was just trying to
say, the linked article "Monadic I/O and Unix shell programming" was about
Haskell (and Unix pipelines), and maybe I should have known that from the
title, but didn't. And I had to stop reading after 2 lines because it assumed
Haskell familiarity.

edit: Didn't see edited comment you mentioned until after I wrote that.
Thanks.

~~~
tempodox
Bartosz Milewski: [https://bartoszmilewski.com](https://bartoszmilewski.com)

------
ridiculous_fish
> Operator | (a pipe), "forces" a command, which is a promise of output, on
> its left producing a stream, an argument for a command on the right-hand
> side of the pipe. A shell pipe thus is an equivalent of a monadic >>=
> operator.

Why is this monadic and not just function composition? Why not just identify
`a|b` with `b.a` and `a;b` with `seq a b`?

------
peteretep
What?

> From shell's point of view, the filters -- echo and cat -- are pure,
> referentially-transparent functions of their arguments

Yes, in this somewhat bizarre, contrived, tautological use of `cat`, maybe.
But `cat` is more commonly used not as an identity function (the explicit
identification of which would seem to strengthen the author's case, but isn't
made), but as a way of pulling in data external to the command-line input,
making it neither pure nor referentially transparent.

> Operator | (a pipe), "forces" a command, which is a promise of output, on
> its left producing a stream, an argument for a command on the right-hand
> side of the pipe

That seems to be more simply a description of function composition, rather
`>>=`, which concatenates functions that have multiple output modes.

Indeed:

> UNIX filter is expected to sequentially consume its input and produce a
> single output stream

is suggestive that filters on the command line have no side-effects, which is
not a typical usage of the term.

