Overall I’m loving it. I’m using it more as an extra-portable and convenient web-browser/time-waster than as a reader and Amazon-content-delivery system (its obvious purpose), more cheap-and-small iPad than expensive Kindle. Which was pretty much my plan. It works great for that. It even works for some things I honestly didn’t expect it to, like reading powerpoint presentations (I wasn’t surprised so much that it tried as that it succeeded).

Of course there are some annoying things about it. Many would (I assume) apply to any mobile touch-screen toy—typing is painful, mobile websites are missing bits I take for granted (e.g. formatting in gmail). Some (many? most?) android apps don’t seem to be available in the amazon appstore—that is probably changing even as I write.

But the single most annoying thing is something I had expected to be trivial. I had figured it would be trivial to download a free ebook—from Project Gutenberg, say—and start reading it immediately. Not so! You can download a .mobi file, and then it just sits there refusing to be read. The quickest way I’ve found to get the demmed things to import is to

• open QuickOffice
• Documents/Downloads
• Hold your finger down on the file, and pick “Send” when the menu comes up
• Email it to your kindle account
• Wait a while. Wait some more.

Isn’t there a better way to do this? If not, for the love of heaven why?^*

On the subject of free ebooks, I’d like to give a shoutout to someone calling herself Cthulhuchick for digitizing the complete works of H. P. Lovecraft and making them available in a nice free edition. Also for picking a great nom d’internet.

* Maybe I’ll answer my own question: Amazon has no interest in my reading stuff I didn’t buy from them.

To his (relative) credit, Klein eventually realized the problem, and he did a similar exercise with questions slanted the other way (“gun-control laws fail to reduce people’s access to guns”). To what should be no one’s surprise, this time he found that conservatives were the stupid ones. Read about it in the current Atlantic. Klein now thinks what both surveys demonstrate is “myside bias.” Really!

I feel a little sorry for Zeljka Buturovic, Klein’s (possibly more academic) collaborator. According to Klein’s Atlantic article, her goal wasn’t to prove anything about economic literacy, but rather to “[explore] the possibility that ideological differences stem more from differences in people’s beliefs about how the world works than from differences in their basic values.” There might be something to that, although I don’t know how to sort out the causality there (and I haven’t read the journal articles). Since she wasn’t the one who wrote either the WSJ or Atlantic articles, I don’t want to tar her with the same brush. Sorry, Zeljka!

Oh, another annoying thing. The questions and “correct” answers are reported in the most confusing way imaginable. From the Atlantic, citing the questions with the canonically incorrect answers in quotes:

Here’s what we came up with, again with the incorrect response in parentheses: a dollar means more to a poor person than it does to a rich person (disagree); making abortion illegal would increase the number of black-market abortions (disagree); legalizing drugs would give more wealth and power to street gangs and organized crime (agree); drug prohibition fails to reduce people’s access to drugs (agree); gun-control laws fail to reduce people’s access to guns (agree); by participating in the marketplace in the United States, immigrants reduce the economic well-being of American citizens (agree); …

So how many negatives to I have to wade through to figure out what an enlightened person thinks of gun control laws? I’m pretty sure Klein thinks they reduce access to guns (I think that too), but that’s more because that’s what you would ask if your goal is to prove conservatives are wrong than from trying to cancel out the “fail to” and the “incorrect response in parentheses.”

1. For what it’s worth, on the original set of questions I would probably have mostly given the “conservative” answers, but only if “it depends” wasn’t an option, and only if I had inferred the context that would be generally implied from the fact that someone was asking about that particular set of things and using that particular phrasing.

Now some details, aimed at node-n00bs such as myself. Anyone who would like to point out how badly I’ve gotten things wrong, feel free!

First, it’s important to know that node.js is architected to solve a specific problem, to wit, scalability in the presence of lots of concurrent access. The usual way something like apache/php handles concurrency is to spawn a thread for each server request. But threads have overhead, and there’s only so far you can push that before you have to buy more servers.

node.js has pretty much the opposite philosophy. The buzzwords you see are “asynchronous” and “event-driven” or just “evented”—its central element is a single-threaded event loop. But that doesn’t tell you much about why it’s a good idea. I found a much more revealing tagline here: “everything runs in parallel, except your code.”

The idea is that in a typical (non-trivial) server request most of the processing time is taken up in things like database or filesystem access, henceforth referred to generically (and not always completely correctly) as “IO.” Those are things that either don’t take a lot of CPU cycles, or at least are already in their own threads or processes. If the thread running those IO operations waits for them to complete, it will be sitting idle; in a single-threaded event loop that means it will block anything waiting for it. So in a single-threaded event loop, you don’t wait! IO operations in node.js don’t return their data directly; instead, they accept callbacks to process the results when they’re ready. Those callbacks are themselves processed in the event loop.

The callback functions themselves should all be lightweight, so that tens of thousands of them can be executed per second. They palm off all the hard work to “IO functions,” black boxes that may in turn add more callbacks. The node.js API, and good node.js plugin modules, are structured to make it positively difficult to do anything that blocks.

Here’s a “hello world” webserver, straight from the node.js front page, that responds to any request with, er, “hello world”:

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337, "127.0.0.1");

The guts of that there–the argument to http.createServer–is the callback that gets called from the event loop whenever the server fires the “request” event (you don’t see the event loop yourself; you just add callbacks for events, and they are called from the event loop). It does the actual responding by calling methods on res, a ServerResponse object.

Of course a real response will be more complicated (starting with url-parsing, which I’ll ignore completely). Traditionally that might look something like

http.createServer(function (req, res) {
  var data = do_some_io_operation(req);
  var output = do_some_more_processing(data);
  res.writeHead(200, {'Content-Type': 'text/html'});
  res.end(output);
}).listen(1337, "127.0.0.1");

But those two function calls, if they do anything IO-ish or otherwise nontrivial, are not kosher node.js. This should be something like this:

http.createServer(function (req, res) {
  do_some_io_operation(req, function(data) {
    do_some_more_processing(data, function(output) {
      res.writeHead(200, {'Content-Type': 'text/html'});
      res.end(output);
    });
  });
}).listen(1337, "127.0.0.1");

What happens on a request is:

• The handler calls do_some_io_operation, which registers a callback and fires off whatever the operation is. It–and the handler–return immediately, and processing can move on to anything that’s waiting in the event queue.
• When the io operation completes, the first inner callback gets executed. That calls do_some_more_processing, which registers yet another callback, starts whatever it starts, and returns.
• When THAT finishes, the inner callback finally takes all the data it now has available and finishes responding to the request.

Database access might look something like this (not real code, but it might be close, modulo error handling)

http.createServer(function (req, res) {
  dbase.connect('tcp://whateverdbase@localhost/whatever', function(connection) {
    var query = connection.query('SELECT * FROM some_table');
    res.writeHead(200, {'Content-Type': 'text/plain'});
    query.on('row', function(row) {
      res.write('<p>' + row + '</p>');
    });
    query.on('end', function(row) {
      res.end('Hello World\n');
    });
  });
}).listen(1337, "127.0.0.1");

Connecting to the dbase is an IO operation, and since everything depends on that almost the whole response function is inside a callback. Setting up the query as I have it here doesn’t necessarily do anything immediately, so it does NOT need to take a callback, but that would be an alternative API. However, you do have to wait for the results of the query, so it gets callbacks for its “row” and “end” events.

I rather like this functional quasi-continuation-passing style of programming, mostly because I like finding out the abstruse theoretical concepts turn out to be useful for real. It might get a bit messy in real examples, though. At the very least I wonder if it would call for a different indentation style .

[And I have a "solution" for that. Or at least something that's kept me happily occupied for the last couple of days. More on it later, if I ever get around to it.]

The fact that this is all in javascript has a few real advantages. Javascript is halfway to being a functional language, and is thus well suited to this style of programming. But it’s not Lisp or Haskell, so existing programmers don’t have to rewire their brains to use it. (I love Haskell, but I can’t imagine trying to find and manage a team to write a Real Product with it.) Indeed, any web programmer will already be fluent in javascript, and used to working with callbacks, if not quite to the pervasive level that node.js requires.

Using the same language on the client and server is a nice benefit, too. It makes it easy to share code between the two sides, something that can be useful (caveat: writing javascript that will work properly in a browser and inside node.js is NOT completely trivial, but it’s usually not that difficult either). And it’s nice for us programmers to avoid the annoying context switches between languages. Going from javascript to python, for example, I am forever forgetting to put quotes around dictionary keys.

And compared to other dynamic languages, javascript on google’s V8 engine, which node uses, is really fast. For “pure” stuff, just function calls and for loops and the like, it appears to be more in the C/C++ range than the Python/Ruby/php range.

Now for the downsides. Actually, for all I know there aren’t any prohibitive ones! But node.js is still relatively new, and I although I think the core is relatively stable the general ecosystem isn’t. There are lots and lots of modules for doing various things, but in this sort of open-source world it’s really difficult to know what you can trust. In the Perl world, for example, I’ve seen CPAN hailed as the greatest thing since sliced bread, but I’ve seen a lot of crap there, and sorting through it can be a real cost.

node.js itself is quite low-level, lower-level even than php. Someone needs to encapsulate even simple things like (e.g.) gathering get and especially post data into dictionaries of query values and data (not that that’s hard, but it does need to happen). There are some embryonic higher-level frameworks—Express looks very promising, and at least does that post-data processing—I am fairly certain there’s nothing anywhere near as mature and trustworthy as Ruby on Rails or Django (or asp.net, if you like that sort of thing).

And conceptually not everyone agrees that eventing is the way to handle concurrency. There are lots of partisans of Erlang and the aforementioned Haskell and even of traditional threading who beg to differ. I’m a bit out of my depth here, so can’t comment usefully.

So who do we blame for the Sugar-coated Satan Sandwich? Which on its own merits isn’t as bad as it could have been, really… at least civilization didn’t collapse, as was a real possibility; and the creation of the terrifyingly-named Super Congress has the great virtue of postponing the really awful decisions for a few months. No, the real problems with it are the precedents it set, and the fact that our governing class’s (including the punditocracy) has decided to respond to a genuine economic crisis by focusing on the single least relevant factor and as a result implementing the stupidest possible policies. Who can we blame for that?

The obvious answer for liberalish coastal elites like me is the Tea Party. But that’s too easy. Sure, the Tea Partiers are stupid and crazy, and it’s absolutely terrifying how much power they wield. But that is their nature, and you can’t expect them to go against their nature. They’ve said all along that they don’t like government, so by golly they’re going to try to get rid of it any way they can. They’re the mad bomber from Source Code (name whited out in case you don’t want to know what I’m very mildly spoiling) (paraphrasing, because I forget the real quote): “We can build a new and better society out of the rubble. We just need to make the rubble first.” No wonder they’re cross that they got everything they asked for: they didn’t hold the government and economy hostage to have their demands met; they made their demands so they could shoot the hostage. This is crazy, but, well, they’re crazy, and have a pretty credible insanity defense. “Forgive them, father, for they know not what they do.”

The sane Republicans, insofar as that’s not an oxymoron now, are considerably more culpable. They at least knew what they were doing, and I can only hope they’re full of self-loathing now. This goes double, of course, for Boehner and Cantor, who remind me of Count Baltar from the old Battlestar Galactica (Baltar from the NEW Battlestar Galactica is much more interesting), allying with the sworn enemies of their very existence. But I can almost understand them; like so many politicians through history, they’re acting out of fear, terrified for their jobs. Well, Cantor is trying to get a better job, but close. Again, you can’t expect someone to against their nature.

How about the Republicans’ corporate masters? We’re getting closer here. At the risk of having Godwin’s Law justifiably invoked, they are treading perilously close to the Weimar-era German business interests who backed the Nazis, thinking they would be easily-controlled tools. I do hope the Chamber of Commerce is reconsidering its priorities. But business leaders in our society, even the allegedly brilliant ones, are always short-sighted, greedy, and stupid, so again you sort of have to expect this.

Pundits? Journalists? Bloggers? Well, yes, they’re mostly pretty bad. But there’s only so much pundits can do to influence the national debate, as much as they would like to think otherwise.

It’s fashionable among my progressive brethren and sisteren to blame Obama for all this. Now I won’t pretend that I’m not disappointed in Obama, but honestly, what could he have done? Obama really wants to make deals and compromise and bring people together, not productive strategies in dealing with modern Republicans, but I honestly don’t know what anyone could have done, no matter how tough. You can’t play chicken with someone who WANTS a head-on collision. Yeah, I know, he should have seen this coming, but IIRC that was just after the LAST hostage crisis; even if Obama could have imagined the teabaggers were that crazy it would have been difficult to continue. It’s kind of like the way we didn’t attack the Russkies in August 1945.

So who do I blame? How did we get to this point anyway? The proximate cause is of course the great Shellacking of 2010, an inevitable result of a lousy economy and a high unemployment rate (and a fickle Democratic base). But one lousy election—one where only one house of Congress changed parties—really shouldn’t have sent the nation’s political discourse so quickly off the sanity cliff. I can easily imagine a parallel universe in which the Democrats lost the House not to the Tea Partiers but to more or less sane Republicans. My theory is that the underlying problem is in what should have been Obama’s greatest triumph, health care reform. You’d think that people would be pleased with some guarantee of health insurance, but no, they HATE it. And it was that hatred (say I) more than anything else that allowed the teahadists to sweep into office, so cowing Democrats that in their confusion and terror they willingly stipulated to the Republican view of the world.

Obviously much of the anti-Obamacare bile is due to Republican lies, not just the flashy ones like Death Panels, but the underlying lie that our health care system is The Best In The World (something I think you can only believe if you’ve never actually meant someone from another country). But lies can only get you so far. As I see it the real problem was with the Democrats themselves, specifically with the Senate Democrats, for doing such a miserable job of getting the the thing passed, and inviting the world in for an open house at the Sausage Factory. The most egregious example (that I know of; perhaps were even worse things that weren’t so obvious) was the legendarily odious Cornhusker Kickback—even though it didn’t make it into the final bill, it was so appalling that it rather justifiably convinced the world that the whole process was corrupt and its result inevitably evil. So, on behalf of the Tea Party, thank you Ben Nelson!

It’s not fair of me to expect the same level of juicy detail from ancient history as there is (or can be) in classical or modern history; there is simply more information about the more recent periods. As far as I know the Egyptians had no analogs of the wonderfully chatty and gossipy (and unreliable) classical historians, and although they were great record-keepers there just isn’t the same sort of detail we have about more recent times. But I’ll compare anyway. Here’s the sort of thing I love, from Strange Victory , by Ernest May (which I recommend!):

Canaris was a strange character. There were many such, of course, at the center of the Third Reich, but Canaris stands out among them…. Five feet four, with prematurely white hair, he detested tall men and, above all, tall men with small ears. The loves of his life were Seppel and Sabine, two dachshunds from whom he was almost inseparable. When traveling, he would require from his staff frequent reports on their apparent emotions and their bowel movements…

…[A]other possibility is anger over encroachments in his domain by Reinhard Heydrich, the head of Himmler’s security service. Outwardly, his relationship with Heydrich was cordial; the Canarises and the Heydrichs were neighbors and dined together. But Heydrich was thought repulsive by men who had no such reaction to Himmler or Bormann. Also, he was very tall and had small ears.

And then there’s Egypt. Egypt is far more familiar to us American rubes than Babylonians and Assyrians and Mittanians. It’s hard not to be exposed to all sorts of things about Egypt, romantic things like pyramids and mummies and sarcophagi for cats and animal-headed gods and King Tut. Yul Brynner and Anne Baxter (“Mo-o-o-ossses…”) are deeply ingrained as my Platonic forms of Pharaoh and Pharaohess (Pharaoness? Pharessa?). But the ancient Egyptian civilization lasted for 3,000 years. That is a long time, half as long again as it’s been since it it became part of Rome until now, and apart from “Cleopatra was at the end” all that history is compressed in our collective unconscious into an undifferentiated mass of pyramids and mummies and sarcophagi for cats and animal-headed gods and King Tut and Yul Brynner and Anne Baxter.

So when I read about Toby Wilkinson’s The Rise and Fall of Ancient Egypt, a popular history of the entire civilization, I hied me to the library and found a copy. It serves its purpose well: I’m much clearer—well, somewhat less vague—on what the difference between the Old and Middle and New Kingdoms, and where Memphis was (and why), and who the Hyksos and the Sea People were, and even to a certain extent which king was which and which did what. I know now where the word “Pharaoh” comes from (“Per-aa,” or “Great House,” applied metonymically to its inhabitant) and why (awkwardness about what to call Hatshepsut—there was no such thing as a “Queen”). The book is easy to read, and it zips right along. If you’re looking for a summary of all of ancient Egyptian history, bearing in mind that a “summary of all of ancient Egyptian history” will necessarily be a few hundred pages, this is it.

One of the highlights (I thought) comes at the very beginning of the Egyptian kingdom. Among the artifacts of that era, now a highlight of the Egyptian Museum of Cairo (and of Adrian Veidt’s—Ozymandias’s!—office in Watchmen) is the Narmer Palette. That’s “palette” as in a thing for mixing paints, in particular cosmetics; the ur-Eqyptians apparently used them as ceremonial objects in those days, a development of sacred face painting among in nomadic cultures or some such. The Narmer palette (apparently) commemorates the very unification of the Two Kingdoms of Egypt under Narmer, Egypt’s possibly mythical first king and founder of its First Dynasty. The obverse is full of Mespotamian motifs: the king as a bull destroying a walled town, those “serpopards” whose intertwined necks frame the pigment-mixing depression. The reverse is more distinctly Egyptian, with the now-human king wearing the crown of Upper Egypt. Although to my untrained and untrustworthy eye there is still some of Mesopotamia there—the king’s calf muscles look distinctly Assyrian to me, and I wonder how much those cows at the top (proto-Hathors, apparently) owe to Mesopotamian predecessors—the Narmer palette represents the very beginning not only of the Egyptian kingdom but of Egyptian, which (again to my untrained eye) remained remarkably consistent for millennia thereafter.

But this isn’t a perfect book. Reading it is a great first step in understanding Egyptian history, but all those kings still blur together. To some extent, I suppose that’s unavoidable—there were a lot of them, after all, and really I don’t know that there is always much to distinguish them. But Wilkinson’s (I hate to say it) somewhat cliched writing doesn’t really help. There are too many “brilliant demonstrations of the unite-and-rule concept” and “brilliant flashes of inspiration” and “brilliant but simple expedients.” I’m sure there is precious little that can really be said about any individual, king or otherwise, especially given Egyptian kings’ perennial habit of erasing all record of their predecessors, but I would desperately like more indivuating details, and anecdotes.

And I’d also like to know more about the Egyptian religion (or should that be religions?). Gods and priests and temples obviously permeate Egyptian history and life, but really all I can say I got from the book is that there were a confusingly large number of gods, whose cults were more or less important in various cities. How did those cults develop, and split and merge, and relate to each other in general? How did perceptions of the gods and details of their cults change over time? What did all those priests do all day, anyway?

So, definite thumbs up, but I am left wanting more. Which is certainly better than left wanting less—

• A Hopf fibration viewer. The Hopf fibration is interesting and important mathematically—it’s part of the reason homotopy theory turns out to be so much more complicated than homology, for example—but its real importance to me is that it makes for great pretty pictures.
• AMandelbrot set “explorer.” That’s the first thing everyone does when they learn about shaders, right?
• A Julia set explorer. It turned out far trippier than I had hoped for.

I’m comfortably certain these are not models of good WebGL practice. (Or good html/javascript practice, for that matter).

So what have I learned? For starters, half the people I’ve tried to show these things to can’t run them, for whatever old-browser and old-graphics card/driver reasons. How long will it be before you can reasonably assume any random user is likely to be able to use this stuff? I suppose it does make sense to learn it now so as to be ready in five years when it’s generally supported. Or maybe it’s that the primary audience is gamers, happy to have an excuse to buy a new graphics monstrocard every few months.

As for the thing itself, it’s interesting comparing it to what little I remember from the days when I knew OpenGL. From a high level it’s pretty much what you’d expect from a translation of OpenGL, or a stripped-down version of it, into javascript, the most obvious difference being that you have to provide your own shaders. I’m rather glad to have to reason to learn about shaders, really; they’re new since my day.

I haven’t figured out all the nuances of GLSL. As an example of the sort of thing I’ve run into, the Mandelbrot fragment shader has a big loop to count iterations. for-loops in GLSL must be of a form like

    for(int i=0; i<CONST; i++) {

where CONST is some actual constant—I assume, possibly wrongly, that that’s so loops can be implemented by unrolling. That I learned quickly enough. Where I ran into problems was figuring out what the CONST could be. Some machines, at least older ones, seem to have a cutoff of 255, and behave oddly (it doesn’t look like a simple mod, but I haven’t tried to figure it out) if the bound exceeds that. The GLSL spec (which appears to be somewhat out of sync with what WebGL as implemented uses; am I looking in the wrong place, or otherwise missing something?) wasn’t much help there.

Back to WebGL vs. OpenGL in general, the other immediate difference is that there’s no more glBegin/glEnd: you have to do everything with buffers. That seems to add to the boilerplate. And of course a lot of the familiar OpenGL and glu methods for things like matrix handling are missing, so you have to provide them yourself. Or find a library that does them all. I don’t think I particularly like either of the ones I’ve seen, but haven’t really thought about them much yet. I can see performance being an issue with getting libraries right.

And finally it’s a bit annoying that WebGL only knows from floats, not doubles. That rather surprises me, but I don’t know enough about this stuff to rant without making a fool of myself.

As long as I can stick to my machine, a relatively beefy Macbook Pro, I’m impressed by how well this stuff works, despite the whingeing above. I haven’t done any real stress tests, but what I have done seems to work well and quickly. As expected, both chrome and Firefox support it. Interestingly, the Firefox implementation seems to be noticably more performant than Chrome. During animations Chrome seems to seize up (garbage collecting?) every couple of seconds. Firefox is nice and smooth.

This entire post is, or is intended to be, a Literate Haskell file. You can copy-paste the whole thing into an .lhs file and run it with ghc (I vouch for it only in version 6.12.3). Some caveats: I am not a Haskell programmer. At worst you should suspect everything I say of being, well, wrong, and at best I’m comfortably certain the code in here is not as elegant as it ought to be. Apologies for all the references that I neglected to include either out of ignorance or out of laziness. And as will be clear I’ve been awfully sloppy throughout.

A while back I started thinking about comonads. I now have little idea why—“a while” is nearly two years—but I think I must have been troubled by the apparent lack of symmetry between monads and comonads in functional programming. It seemed somehow ufair that monads are so useful and get so much attention, while their poor duals are neglected. Really I just wondered whether some of the standard monad constructions and connections—monad notation, most obviously, and the connection with Applicative Arrows—had any dual consructions, and whether they might be useful. It turns out they there are indeed dual constructions, although I suppose I can’t truly swear to the usefulness part. Herein are most of my collected thoughts on the subject.

BTW, I have little idea how much of what follows is original, but a couple of things way down below the fold might be. You can easily find a fair bit about comonads and examples thereof, but I haven’t seen either real proposals for comonad notation (not that I’m claiming there’s one of those here either) or anything about “Coapplicative Arrows” elsewhere.

First, some preliminaries:

> {-# OPTIONS_GHC -XArrows -XImpredicativeTypes #-}
>
> import Prelude hiding (id, (.))
> import Control.Category
> import Control.Arrow
> import Control.Monad

We’ll be using arrows, so we need to turn on arrow notation and import the relevant modules. We’ll also need Impredicative Types later on. GHC 6.12 will warn about impredicative types, but I hope that something very much like this will work in GHC 7 (maybe with more type annotations, probably not a bad thing). Since Control.Category defines . and id, we’ll hide the Prelude versions. The comonad module (here missing its module declaration, for pedagogical purposes) was lifted from here.

Now to work. So what’s a comonad, anyway? As a quondam mathematician, I find it easiest to think of both monads and comonads in terms of categories and arrows. For programming purposes an “arrow” is a generalization of “function”—they are things that can be composed like functions, but which can have all manner of other structure. In Haskell they are encapsulated by the Arrow class. See this for an introduction to Haskell arrows—this post will make little sense if you don’t—and this for a very nice lecture about monads from this perspective.

Now many arrows can be expressed in terms of plain old functions. It may happen that

    a b c

can be expressed as the set of functions from b to some more compicated type based on c:

    a b c = b -> m c ,

And that’s what a monad is! Or rather, the type constructor m is a monad. From the Arrow class’s composition >>> we can construct the usual bind and join operations on the monad, and from the arrow laws we can derive the monad laws.

Some other arrows can be expressed the other way round. That is they’re functions from some complicated thing to a plain old type:

    a b c = w b -> c

In that case w (“w” is a sort of upside-down “m”…) is a comonad.

In category theory comonads are the duals of comonads, pretty much the same things with all the arrows turned around. In functional programming more or less the same is true. Just as you can always “put something into” a monad with return, you can always “get something out of” a comonad. As you can flatten multiple levels of monad constructors with join, you can introduce more levels of comonadic constructors. Bind has an obvious analog in cobind. In detail

> infixl 1 =>>
> infixl 1 .>>
>
> class Functor w => Comonad w where
>   extract :: w a -> a
>   (=>>) :: w a -> (w a -> b) -> w b
>   duplicate :: w a -> w (w a)
>   (.>>) :: (w a -> b) -> (w b -> c) -> w a -> c
>
>   duplicate x = x =>> id
>   f .>> g = \x -> g ( x =>> f )

[Credit: as I said, I stole this from here].

The comonad functions should satisfy laws that are the duals of the monad laws, e.g.

    extract ( x =>> f ) = f(x)
    x =>> extract = x

We’ll also have occasion to use comonadic fixpoints:

> class (Comonad w) => ComonadFix w where
>     wfix :: w (w a -> a) -> a

This will make sense with examples. The simplest one is of course the Identity functor, but that is too simple. Slightly more interesting is taking a product with some fixed type:

> instance Comonad ((,) c) where
>   extract   (c,x) = x
>   (c,x) =>> f = (c, (f (c, x)))

This is dual to the Either monad; mathematically we get a monad from a coproduct and a comonad from a product (and vice versa, sort of—see below). It’s also left adjoint to the (->) monad: the same arrow type can be expressed as either a monad or a comonad. That is,

    (c, b) -> d

is the same as

    b -> c -> d .

More interesting still is state. This is one of the principal inspiration for the use of monads, where we have the State monad

    St s a = s -> (s, a)

(well, conceptually that’s what it is). An object of a State monad type is a “state transformer,” a function that takes transforms a state while extracting a value. That makes more sense (to me!) as a model for computation in terms of arrows: the associated Arrow type is

    a b c  =  b -> (s -> (s, c))

which through the Cartesion adjunction is the same thing as

    a b c  =  (s, b) -> (s, c)

The arrows are plain old functions, but we’ve tacked states on to everything.

We can do the same thing with (->) rather than (,). From the arrow type

    a b c  =  (s -> b) -> (s -> c)

we can use the adjunction the other way and get a COmonad

    a b c  =  (s, s -> b) -> c .

These arrows are functions that map “value extractors” into each other. In gory detail,

> data CoState s a = CoState s (s->a)
>
> instance Functor (CoState s) where
>     fmap g (CoState s f) = CoState s (g . f)
>
> instance Comonad (CoState s) where
>     extract (CoState s f) = f s
>     cs@(CoState s f) =>> g =
>           CoState s (\x -> g (CoState x f))

These can represent a notion of “computation in a context.” And indeed comonads generally can be viewed as a way of adding context to computations.

Another prototypical example is streams, that is, endless lists. We can define them, and their comonad structure (and some generally useful functions) thusly (see this, from which this example and the next were adapted, for more details on streams):

> infixr 1 :<
> data Stream a = a :< Stream a
>
> instance Functor Stream where
>     fmap f (v :< s) = (f v) :< fmap f s
>
> instance Comonad Stream where
>   extract (v :< _)    = v
>   val@(x :< xs) =>> f = f val :< (xs =>> f)
>
> headS (h :< t) = h
> tailS (a :< t) = t
>
> takeS :: Int -> Stream a -> [a]
> takeS 0 s = []
> takeS i (v :< s) = v : (takeS (i-1) s)

Cobinding a function to a stream simply applies the function to each successive “tail” in turn:

    (1, 2, 3, 4, ... ) =>> f =
        ((f (1, 2, 3, 4, ... ),
            (f (2, 3, 4, 5, ...),
                (f (3, 4, 5, 6, ...), ...)

Duplicate collects all the tails into a single stream, so

    duplicate (1, 2, 3, 4, ... ) =
        ((1, 2, 3, 4, ...),
            (2, 3, 4, 5, ...),
               (3, 4, 5, 6, ...), ...)

Comonadic stream computations—the associated arrows—map streams to streams in a “historyless” way. The nth value in the resulting stream depends only on the nth and greater values in the origin stream. If we want something more general we can add a list representing “what we’ve seen so far”:

> data LS a = LS [a] (Stream a)
>
> instance Functor LS where
>     fmap f (LS l s) = LS (fmap f l) (fmap f s)
>
> instance Comonad LS where
>     extract (LS _ (h :< _)) = h
>     ls@(LS l s) =>> f = LS (bindL l s) (bindS l s)
>         where
>             bindL [] _ = []
>             bindL l@(h:t) s = h2:l2
>                 where
>                     h2 = f(LS t (h :< s))
>                     l2 = bindL t (h :< s)
>             bindS l s@(h :< t) = h2 :< s2
>                 where
>                     h2 = f(LS l s)
>                     s2 = bindS (h:l) t
>
> nextLS (LS l (h:< t)) = LS (h:l) t
>
> instance ComonadFix LS where
>     wfix fls@(LS fl fs) = v where
>         wff [] (f :< fs) ls@(LS h s) =
>             let v = f ls
>                 LS _ t = wff []
>                   fs (LS (v:h) (tailS s))
>             in LS h (v :< t)
>         wff (fh : ft) fs ls =
>                   nextLS (wff ft (fh :< fs) ls)
>         LS h t = wff fl fs (LS [] t)
>         v = extract (LS h t)
>
> toStream :: LS a -> Stream a
> toStream (LS [] s) = s
> toStream (LS (h:t) s) = toStream (LS t (h :< s))
>
> nextLSF (LS _ (_:< h:< _)) = h
>
> -- go back to the previous place in the "history"
> -- if we're already at the beginning, prepend
> -- the given value
> delayCF :: a -> LS a -> a
> delayCF a (LS [] _) = a
> delayCF a (LS (h:_) _) = h
>
> delay :: a -> LS a -> LS a
> delay a w = w =>> delayCF a
>
> takeLS :: Int -> LS a -> [a]
> takeLS n = takeS n . toStream

That’s also equivalent to a “stream with position.”

Simlarly, comonads can be used to represent all sorts of structures with positions therein. Cellular automata on various sorts of regular grids provide another example.

Armed with specific examples—Stream is generally a good one—we can think about some generalities. We’ve seen some of the relationship between arrows and monads and comands, but let’s make it more precise. If we have a monad we can make an arrow type by taking Kleisli arrows. And pretty much the same thing works with comonads (including fixpoints):

> newtype CoKleisli w a b =
>       CoKleisli { unCoKleisli :: w a -> b }
>
> instance (Comonad w) => Category (CoKleisli w)
>       where
>           id = CoKleisli extract
>           (CoKleisli f) . (CoKleisli g) =
>               CoKleisli (\x -> f (x =>> g))
>
> instance Functor (CoKleisli w a) where
>   fmap f (CoKleisli g) = CoKleisli (f . g)
>
> instance (Comonad w) => Arrow (CoKleisli w) where
>   arr f = CoKleisli (f . extract)
>
>   CoKleisli a &&& CoKleisli b
>         = CoKleisli (a &&& b)
>
>   CoKleisli a *** CoKleisli b
>         = CoKleisli (a . fmap fst
>             &&& b . fmap snd)
>
>   first a  = a *** arr id
>   second a = arr id *** a
>
> extractA :: (Comonad w) => (CoKleisli w) b b
> extractA = CoKleisli extract
>
> instance ComonadFix w => ArrowLoop (CoKleisli w)
>   where
>     loop (CoKleisli f) =
>         let
>             -- g :: w a -> w (w (a, b) -> (a, b))
>             g wa = wa =>> (\a -> \wab ->
>                        (extract a, snd (f wab)))
>             -- k :: w a -> (a, b)
>             k wa = wfix (g wa)
>         in
>             CoKleisli (\wa -> fst (f (wa =>> k )))

Something interesting (by my nerdly definition of “interesting”) here is that, in a sense, comonads make better Arrows than monads do. The product function *** as applied to monads is not really a product in the categorical sense. It’s not necessarily even a functor. We really should have

    (f *** g) >>> (arr fst) = (arr fst) >>> f

but we don’t—try it with lists, for example. But in the comonadic case *** really does act like a proper product.

On the other hand, monads do have nice Choice functions—(+++) is a real coproduct. Comonads do not. We can still define (+++) for CoKleisli arrows, but it is ill-behaved in the same way as products in the monadic case. This we can do by extracting a value from the comonad, constructing a new “constant comonad” from that value, and apply the given function. For left, that looks like

> instance (Comonad w) => ArrowChoice (CoKleisli w)
>   where
>     left (CoKleisli f) =
>         let
>             g (Left x) cm = Left $
>                   f (cm =>> \y -> x )
>             g (Right x) cm = Right x
>             h x = g (extract x) x
>         in
>             CoKleisli h

I don’t know if this is practically useful or not.

Mathematically (and here you might want to skip to the next paragraph, even if you’ve somehow managed to make it this far), that’s a deepish result of the nature of monads and comonads. Given a monad M in some category, we have adjoint functors F |- G, where F sends objects to their counterparts in the Kleisli category, while G sends them back to their monadified versions. Since F is a left adjoint, it preserves colimits, including coproducts, so (F (x|y)) is the coproduct F x | F y. There’s no particular reason for the same to hold with products, though. Looking at arrows and translating to Haskell, that leads to the observations above. Since comonads are dual, we can apply the same reasoning switching “left” and “right”, adding “co-” everywhere it isn’t, and removing it everywhere it is. We thus find that the functor to the CoKleisli category is a right adjoint and preserves limits, including products.

Haskell’s monad notation is of course enormously convenient, so it’s natural to ask whether something similar could be done with comonads. There are of course complications. We can’t really identify a (co)do black with a comand, but rather with a comonadic arrow. We’ll use (probably unwisely) “proc” to name the argument, as with arrows. We also can’t really use the nice nested-lambda translation that is one definition of a monadic do-block, or at least it’s awkward to get it to work (try it!). Instead we’ll “push” the do-bound variables through each line, as in arrow notation (more or less) or in actual implementations of monadic do-blocks (I think).

Suppose we want to attach a meaning to

    proc w -> do
        x <- foo
        y <- bar
        baz

foo, bar, and baz are expressions of “simple” type in which w, x, and y appear free as variables of comonadic type. We would like that to mean something along the lines of

    (\w -> foo) .>> (\x -> bar) .>> (\y -> baz)

but that won’t work if w appears in bar or baz. We can get around this by defining the do-block to be (here using “fst”, “snd”, and the imaginary “third” very loosely!)

    \m0 ->
    let m1 = m0 =>> (\w -> (extract w, foo))
        m2 = m1 =>> (\m ->
                let w = fmap fst m
                    x = fmap snd m
                in (extract w, extract x, bar)
        m3 = m2 =>> (\m ->
                let w = fmap fst m
                    x = fmap snd m
                    y = fmap third m
                in bar
    in extract m3

or something like that. Needs some work.

However it should work, there’s no comonad notation now, but there is arrow notation, and we can use that to assemble comonadic functions. So let’s go back to the relationship between comonads and arrows.

The Kleisli arrows of a monad are instances of ArrowApply, with an arrow

    app :: a (a b c, b) c

This is just an arrowfied version of the usual eval function

    eval :: (b -> c, b) -> c
    eval (f, x) = f x

Conversely, any instance of ArrowApply whose app satisfies a few conditions leads to a monad, where (in psedocode now)

    m b = a () b
    x >>= f = () -> arr ( () -> (f, x) ) >>> app

We’ve “tied up” the first type argument of an arrow type simply by setting it to (), analogously to the fact that

    b <-> () -> b

Then we can “apply” an arrow to a monadic object in the obvious way:

    m b >>= f  <->  a () b >>> f

If we can establish a corresponence between arrows and monadic functions then we’re done: and this is where we use the app arrow:

    f :: a b c  <->
        \x -> arr (\(y::a () b) ->
                (y >>> f, ())) >>> app

What about comonads? We already know how to get an arrow from a comonad, but can we go back the other way? It turns out that we can. To do that we need to be able to construct some type w a from an arrow type and establish some correspondence between arrows and ordinary functions w a -> b. To get a comonadic type from an arrow we need to tie up the second type argument. This takes a little more cleverness than the monadic case did. We can do it by taking a sort of double dual:

    w b = forall c . (a b c -> c)

(and here’s where we start seeing impredicative types). We can easily cobind an arrow to such a thing

    x =>> f  =  \y -> x ( f >>> y )

To associate an arrow to a comonadic function we can use a sort of adjoint to app:

    coapp :: a b (forall c . a b c -> c)
    f :: w b -> c  <->  coapp >>> arr (\x -> f x)

This works if coapp satisfies conditions including

    coapp >>> arr (\g -> g id) = id
    f >>> coapp =
        coapp >>> arr (\g -> (\h -> g (f >>> h)))

To formalize all this we’ll define a type class

> class Arrow a => ArrowCoApply a where
>     coapp :: a b (forall c . a b c -> c)

CoKleisli arrows are coapplicative:

> instance (Comonad w) => ArrowCoApply (CoKleisli w)
>   where
>     coapp = CoKleisli (\wb -> \(CoKleisli f) -> f wb)

It’s easy to check the coapp conditions. And now to go back from arrows to comonads:

> newtype ArrowCoApply a => ArrowComonad a b =
>     ArrowComonad (forall c . a b c -> c)
>
> instance ArrowCoApply a => Functor (ArrowComonad a)
>   where
>       fmap f (ArrowComonad g) =
>           ArrowComonad (\h -> g (arr f >>> h))
>
> instance ArrowCoApply a => Comonad (ArrowComonad a)
>   where
>     extract (ArrowComonad f) = f (arr id)
>     (ArrowComonad f) =>> g =
>         let garr = coapp >>>
>               arr (\x -> g (ArrowComonad x)) in
>         ArrowComonad (\h -> f (garr >>> h))
>
> -- Translation between arrows and
> --    comonadic functions
> comonadToArrow :: (ArrowCoApply a) => ((ArrowComonad a b) -> c) -> a b c
> comonadToArrow g = coapp >>> arr (\x -> g (ArrowComonad x))
>
> arrowToComonad :: (ArrowCoApply a) => a b c -> (ArrowComonad a b) -> c
> arrowToComonad x (ArrowComonad f) = f x

We’ll close by demonstrating that this actually works by using comonads and arrows to compute Fibonacci numbers in a few increasingly abstruse ways. A simple one first, using CoKleisli arrows of streams; we’ll use arrow notation to make comonadic functions:

> -- a utility class for streams and LS's:
> -- a comonadic "next" function
> class Comonad s => HasNext s where
>       next :: s a -> a
> instance HasNext Stream where
>       next (_ :< x :< xs) = x
> instance HasNext LS where
>       next = extract . nextLS
> nextA :: HasNext w => CoKleisli w a a
> nextA = CoKleisli next
>
> fibhelp :: Stream Integer-> Integer
> fibhelp =
>     let f = proc x -> do
>         y <- nextA -< x
>         extractA -< x+y
>     in unCoKleisli f
>
> fibs :: Stream Integer
> fibs = 1 :< 1 :< (fibs =>> fibhelp)

If we use streams-with-history, we can build the recursion into the proc/do block, through ArrowLoop:

> delayA x = CoKleisli (delayCF x)
>
> fibhelp2 :: LS () -> Integer
> fibhelp2 =
>     let f = proc a -> do
>                 rec z <- extractA -< x + y
>                     y <- delayA 1 -< z
>                     x <- delayA 1 -< y
>                 extractA -< x
>     in (unCoKleisli f )
>
> nothingS = () :< nothingS
> fibs2 = (LS [] nothingS) =>> fibhelp2

and for a particularly recondite and impractical last act, we can take one of these comonads, turn it into an arrow, and then back into a comonad:

> -- take a comonad into the "double dual" comonad
> -- via CoKleisli and ArrowComonad
> toCC :: Comonad w => w a -> ArrowComonad (CoKleisli w) a
> toCC x = ArrowComonad $ \(CoKleisli f) -> f x
>
> fibsCC = toCC fibs
> fibsLSCC = toCC fibs2
>
> nextCC :: HasNext w =>
>       ArrowComonad (CoKleisli w) a -> a
> nextCC = arrowToComonad nextA
>
> takeCC :: HasNext w =>
>       Integer ->
>           (ArrowComonad (CoKleisli w) a) -> [a]
> takeCC 0 x = []
> takeCC n x =
>       (extract x) : takeCC (n-1) (x =>> nextCC)
>

And we use all this machinery in a main function of startling banality

> main = do
>       putStrLn "Comonad testing"
>       putStrLn "Streams:"
>       putStrLn $ show $ takeS 10 fibs
>       putStrLn "LS:"
>       putStrLn $ show $ takeLS 10 fibs2
>       putStrLn "Streams via arrows and back:"
>       putStrLn $ show $ takeCC 10 fibsCC
>       putStrLn "LS via arrows and back:"
>       putStrLn $ show $ takeCC 10 fibsLSCC