I ran across a paper on Hacker News that looks like it probably contains useful insight into a problem I am currently trying to solve – Yield: Mainstream Delimited Continuations, by Roshan James and Amr Sabry. It so happens that I am designing an implementation of ‘yield’ for Radian, and have been thinking a lot about its relationship with C#-style async IO by way of continuations, trying to come up with an architecture which can conveniently express both. After reading this paragraph, I felt some hope that the authors were going to tell me how to do that:

Many mainstream languages have operators named yield that share common semantic roots but differ significantly in their details. We present the first known formal study of these mainstream yield operators, unify their many semantic differences, adapt them to a functional setting, and distill the operational semantics and type theory for a generalized yield operator. The resultant yield, with its delimiter run, turns out to be a delimited control operator of comparable expressive power to shift- reset, with translations from one to the other. The mainstream variants of yield turn out to be one-shot or linearly used restrictions of delimited continuations.

Well, yes, of course yield must be implemented using continuations. How else would you do it? But any hope I had that this paper would help me design a satisfactory implementation vanished when I ran into this sentence on page 6:

We are now ready to introduce the syntax of a monadic meta-language with yield. This language is Moggi’s monadic metalanguage (MML) extended with the opaque monadic type Yield i o r and a type Iterator i o r for interacting with iterators:

I don’t even know how to start understanding what this means, and the following paragraphs wander off into an impenetrable thicket of symbolic goobledygook I can’t quote here without destroying the formatting. I have no idea what happens on page 7.

Variations of this experience have begun to frustrate me with increasing frequency over the last couple of years. I ran into the same problem last month when I was implementing finger trees in Radian: every explanation I found was expressed in such a thick, symbolic academic jargon that I could make no sense out of it. I got halfway through my implementation on the strength of the sole exception, Eric Lippert’s clear, well-written explanation of an immutable deque in C#, and then reverse-engineered the rest of the finger tree concept using a lot of trial and error. I must give credit to Hinze and Paterson for inventing and publicizing the thing, since otherwise I would never have known it was possible to create a data structure with those performance characteristics, but I got nothing of any use out of their actual paper.

The thing which really frustrates me here is the apparently unbridgeable gap between academic computer-science language and practical software-engineering language. Of course the CS researchers are going to write papers in their community dialect no matter how much I’d prefer that they spared me the trouble of translation, but isn’t CS research eventually supposed to produce insight which informs the development of actual software? I don’t understand how I’m supposed to even start learning how to read what they’re writing short of burning ten years on a PhD or something. How is this supposed to work? Whose job is it to learn both dialects and perform the translation, and where can I find their writing?