But while fixing it, I got stuck on a puzzle: what exactly is an anamorphism?
Is an anamorphism a higher-order unfold operator? Or is it any function which is defined by partially applying such an operator? Or a function that is defined using a certain syntactic pattern, corresponding to an unfold operator? Or any function at all that could be so defined?
In the almighty "Programming with Bananas, Lenses, Envelopes and Barbed Wire," they seem to use "anamorphism" to refer to a function defined by a certain syntactic pattern. It's a question of interpretation, but they don't seem to define it as a higher-order function, exactly: the text posits some pre-existing operators and then the code sample, which takes just one argument (the "seed" value to unfold from), uses those posited operators.
It seems natural to me to use "anamorphism" to refer to the (unique) unfold operator for a given ADT, and likewise for "catamorphism" and fold. We still have the plural "anamorphisms," since we have many types with such operators. And, I'm not sure to what extent a function is intrinsically "an anamorphism" in Meijer, et al.'s sense. Of course, it is intrinsic whether a function can or cannot be defined that way; but when we start using the whole bag of bananas, lens, envelopes and barbed wire, I think we get multiple ways to define many functions, so it's less intrinsic.
I'd like to hear what others think: What are anamorphisms? Please comment!
]]>Along the way I found a paper by Mitsuhiro Okada from 1989 which proves strong normalization for the combination of STLC with any first-order term-rewriting system. But this paper is hard to read because it has strange notations and concepts and says things like, "If a part s[*/x1, ..., */xn, */y] of t belongs to the cap then the part s[*/x1, ..., */xn, */y] also belongs to the cap." Say what?
I knew I could prove the same result using the Tait-Girard method (the same basic approach Okada takes) in a more straightforward way—at least to me. So I did, and here it is for future reference: "Simply adding lambda won't make your rewrites diverge."
]]>'I explained this basic idea to a non-economist friend, who replied in some dismay, "Isn't that pretty obvious?" And of course it is.' Yet, because it had not been well modelled, the idea had been disregarded by economists for years.
(MacFarquhar, "The Deflationist." The New Yorker, March 1, 2010.)
Much of what we academics do (in computer science and, apparently, in economics) is to take an intuitive idea and make it precise—modelling it, if you will. Those who simply think intuitively may have already absorbed the idea and treat it as old hat—but the model, by making it more precise, illuminates it further and more securely and can lead to new inspirations.
MacFarquhar adds another interesting idea here:
His friend Craig Murphy, a political scientist at Wellesley, had a collection of antique maps of Africa. ... Sixteenth-century maps of Africa were misleading in all kinds of ways, but they contained quite a bit of information about the continent's interior—the River Niger, Timbuktu. Two centuries later, mapmaking had become much more accurat, but the interior of Africa had become a black. As standards for what counted as a mappable fact rose, knowledge that didn't meet those standards—secondhand travellers' reports, guess hazarded without compasses or sextants—was discarded and lost. Eventually, the higher standards paid off—by the nineteenth century the maps were filled in again—but for a while the sharpening of technique caused loss as well as gain.
I'm intrigued by this idea that higher standards of precision can cause us to 'forget' disciplinary knowledge, material that no longer meets the standards. Of course, the higher standards are all about eliminating 'knowledge' that isn't actually correct. But some of it, perhaps, is correct, and anyway there's an outer shape to the knowledge that is useful: after all, there was still a River Niger even if the mapmakers didn't know exactly where it flowed.
This might happen in computer science, too. I think of Don Knuth's penchant for reading antique sources describing algorithms from pre-modern times.
There might be inspiration in the older, less-precise knowledge of one's field: it might be a source of ideas to be modelled.
]]>I had some other interesting job offers, but I took this one because (a) it was in the Boston area, which is where I wanted to be at the time and (b) I wanted to get behind one central product and contribute some programming-language knowledge to it. I was surprised to discover a company that would let me do both.
As part of what how we're improving the product just now, we're building a parallelizing compiler for relational algebra—roughly the sort of stuff that titilates me as a langauge engineer, and tangentially (at least) related to some of my thesis work.
Since it's a company trying to compete against others, I probably won't be blogging much about what I'm doing at work, but I still hope to keep this blog active and post researchy notes here.
]]>The time-saving benefit of this strategy is subtle to grasp but significant. You see, only the reviewers of a paper "must" read it, while everyone else will discard it if it's boring. By voting to publish, you waste no one else's time—but the time you save is your own. If every reviewer did this, the time saved would allow us all to do far more research!
]]>It looks like a subroutine call, but in the case where it occurs as the last thing in the routine, it magically, silently, and automatically gets turned into, now how did I put it? “A highly controlled and structured GOTO.”
A tail-call is a subroutine call. The efficient implementation does not magically transformed into something else; if it doesn't create a stack frame on such a call, it's because one simply isn't relevant.
The essential observation behind the efficient-tail-call implementation (not "optimization"—more on which in a moment) is as follows: For most programming languages, a stack frame is needed not for a subroutine call but only for an argument evaluation, that is, an evaluation whose result is temporary and needs further processing. Calls in the middle of a procedure are "argument" evaluations, because their results need further processing. It's really the temporary, non-final natural of the result that forces us to do the book-keeping that remembers where to come back to.
Another confusion is between semantics and cost model:
Call me old-fashioned, but it just seems wrong when the semantics of two identical function invocations vary wildly as a function of whether there’s an executable statement between the invocation and the function exit.
The semantics of the call doesn't change; the result and the side-effects are the same (that's what's usually meant by "semantics" anyway). The cost, on the other hand, might be quite different depending on whether a stack frame is needed.
Unfortunately, efficient tail recursion has often been described as a transparent "optimization," so that it might or might not be efficient and the programmer can't tell in advance.
Efficient tail calls (or space-consuming ones) really should be part of the official "cost model" of the language, something that goes along with the semantics, as a peer to the semantics, in fact. The cost model tells you how expensive you can expect things to be, but should be a little less binding than the semantics, since language implementors should have some freedom to do additional optimizations.
The idea that stack frames should correspond directly to the call structure is just odd. Maybe we want to know the call structure at runtime; in that case, we should capture that as debugging information, or as a reflection feature of the runtime system, but not as a core language design. Let the language implementation use the stack as efficiently as possible!
To summarize:
I learned today from this NY Times article about handwriting that the root of "cursive" is the Latin currere, "to run."
Recursion, then, is just running again.
]]>The thesis turned out better than I'd hoped, in the sense that all four major pillars of the work were also accepted to conferences (the papers are "Links: Web Programming without Tiers," "The Essence of Form Abstraction," "A Located Lambda Calculus," and "The Script-writer's Dream: How to Write Great SQL in Your Own Language and Be Sure It Will Succeed").
The night I printed it, I was elated, walking to the printer to collect my final copy, knowing I had done it—created some programming language features, written a 180-page thesis, persevered. In a couple of months I'll defend it, warts and all, and then perhaps I'll be completely finished. But it's downhill from here. I think.
Update: The final version has now been submitted, and the above link points to the latest version.
]]>Blocks are a simple extension to C (as well as Objective-C and C++) that make it easy for you to define self-contained units of work. A block in code is denoted by a caret at the beginning of a function. For example, you could declare a block and assign it to x by writing:
x = ^{ printf("hello world\n"); }This turns the variable x into a way of calling the function so that callingx( );in the code would print the words hello world.What’s really powerful about blocks is that they enable you to wrap much more complex functions—as well as their arguments and data—in a way that can be easily passed around in a program, much as a variable can be easily referenced and passed.
Underneath this is a diagram showing that a block is like a function with some associated data.
I think I've seen this idea before somewhere. :-)
Ah, but a closure by any other name would smell as sweet...
]]>It is not every 31-year-old who, in a first government job, finds himself dismantling General Motors and rewriting the rules of American capitalism. ... “He’s got this beard that appears and disappears,” says Steven Rattner, one of the leaders of President Obama’s automotive task force.
Emphasis mine.
]]>[C]omputer engineering was [once] based on starting with clearly-defined things (primitives or small programs) and using them to build larger things that ended up being clearly-defined. Composition of these fragments was the name of the game. However, nowadays, a real engineer is given a big software library, with a 300-page manual that’s full of errors. He’s also given a robot, whose exact behavior is extremely hard to characterize (what happens when a wheel slips?). The engineer must learn to perform scientific experiments to find out how the software and hardware actually work, at least enough to accomplish the job at hand.
It's very perceptive, this idea that a programmer's job is, in part, to work out how an existing system really behaves--through "scientific experiments." It flies in the face of the mathematical approach to programming, where we compose perfect units to accomplish our well-defined goal.
What's more, many programming tasks don't have a clearly-defined goal. You might instead want to explore a certain area by slapping things together. Or the goal may shift as you discover the problem terrain through coding.
None of this is incompatible with functional languages--but it might suggest an argument against purity: it might be very valuable for a language to have back doors, which allow you to do something improper, at least for a time, while you're poking around at the system or the domain.
But "back doors" are also an argument in favor of orthogonal language design. Being able to put functions anywhere, for example, allows you to code routines that are extremely unreadable--truly a vice. But when you're bodging around, it's very handy to be able to plop in a function where there once was a value, or the like. Functional languages win here, since they nearly always take orthogonality much further than imperative ones. (By this measure, though, Perl rates as a functional language!) Hopefully, after discovering what you needed to discover, you'll rewrite the code in a clear way, without very deep nesting of constructs, for example.
]]>You never tune in to your favorite TV show to see a disclaimer like this scroll across the screen:
Tonight's show is not going to be very funny and includes lots of shots of the outside of the house. That's because the writer was hung over all week and one of the actors turned up an hour late because the car wouldn't start—you know how that is!! We're really sorry and we promise that next week's show will be better.
TV shows, like academic talks, are performances, and final products—rather than working products—of the work that went in to produce them.
"The best you can do" doesn't have to be the best thing ever. There's a range in every community, and that's part of life. If someone gives a mediocre presentation one day and a better one another day, we'd say he or she improved. But we never adjust our estimation of someone's work because of excuses.
When you know you've done suboptimal work, or you're not fully prepared, it's best just to press on and give the best performance you can. Maybe your slides are crap—either skip some, or clarify them in words, or redraw them on a whiteboard, or something. Don't just apologize and expect the audience to swallow something bitter-tasting. It may be important to characterize what you've done modestly, for example, being clear about what problems you have and haven't solved, but that's quite different from an apology. You might give a talk where you say, "We tried to solve these three problems but we haven't really solved any of them." And maybe this failure is even because of desultory work; it still might be worth giving a talk and passing on what you've learned. "Here's why these problems are hard," you could say.
Apologies are important, in general, to signal that you know you've made a mistake. In a relationship of trust, when you've messed up, you need to acknowledge it; otherwise your confidantes may think the bad behavior was typical of you, or that you would do it again in the same situation. Such a relationship might be an intimate one—say you forgot your lover's birthday—or it could be a working relationship—the writer on the sitcom, above, who showed up for work hung over, was trusted by his co-workers to give a strong effort on the show. That he turned in dodgy work, causing the show to come out crap, is a mistake worthy of an apology. The apology allows you to regain trust, and of course many mistakes are forgivable. An apology signals that you learned something from the mistake, and so others can risk trusting you again.
Contrariwise, TV viewers are not in a relationship of trust with the production team. They want a damn good show with no buts about it. Anything else will simply drive them elsewhere—likewise, the audiences of technical and academic talks.
]]>So today I reached for an Oblique Strategy and got this:
Look closely at the most embarrassing details & amplify them.
So that's what I'm doing tonight: making it messier.
]]>