For the first time in three years of research, I'm really proud of a paper that I worked on with my research group: The Essence of Form Abstraction, by Ezra Cooper, Sam Lindley, Philip Wadler and Jeremy Yallop, to be published in APLAS 2008. The paper shows how you can create compositional HTML forms which package up their data in any desired type. It shows an OCaml implementation but we also use the idea in our web-centric language, Links.

Though this is the first good group work that I've contributed to, the others have been doing some great work. In particular, Jeremy, Sam, and Phil did some nice work characterizing the expressive power of idioms, arrows, and monads. They first defined a metalanguage, like Moggi's monadic metalanguage, which can encompass all three notions, in The Arrow Calculus, by Sam Lindley, Philip Wadler and Jeremy Yallop (unarchived). Then they showed the hierarchy of the three, under which idioms are the loosest interface but therefore their language is the strictest to program with, and monads are the strictest interface, therefore their language is the most free, and arrows can be seen as lying in between. The work is described in Idioms are Oblivious, Arrows are Meticulous, Monads are Promiscuous (ibid.), MSFP 2008.

To summarize this, you can see the arrow calculus as a syntax like the do notation of Haskell:

do y <- f x
   z <- g y x
   return (h x y z)

Now to put the result crudely, monads allow expressions like the above, where the value bound at each step can be used in all future steps (this makes them "promiscuous"). The use of arrows restricts this so that the value bound at each step can be used only at the next step, as in:

do y <- f x
   z <- g y x
   return (j x z)  -- y cannot be used here

You can still use arrow operations to manually pass data forward through each step, but this is a nuisance. Hence Lindley, Wadler and Yallop coined the term "meticulous" to describe arrows.

The idiom laws restrict this further so that each value can be used only in a final return clause (the return clause is "oblivious"):

do y <- f x
   z <- k x        -- y cannot be used here
   return (h x y z)

An astute reader will note that return is not required in do syntax. What happens if there is no return clause? Then you can add one:

do y <- f x
   z <- k x
   q

is equivalent to

do y <- f x
   z <- k y x
   result <- q
   return result

But either way the idiom laws require that q cannot depend on y or z.

This shows that the three notions progressively restrict (and fairly naturally) the ways that you can program with them. But, in a familiar appearance of contravariance, the notions are reverse-ordered in how restrictive they are to create. An idiom, being the most restrictive on its user, is least restrictive to its writer. Thus you can model some computational notions as idioms which you could not model as monads. This fact came in handy in our latest paper, where we used idioms to model form abstraction.

I encourage you all to read about idioms, arrows and monads, as it's turning out to be a very nice theory.

newsham: > let motor sounds = sounds "vroom! " in motor cycle

lambdabot: "vroom! vroom! vroom! vroom! vroom! vroom! vroom! vroom! vroom! vroom! vroo...

I was looking at the German version and I don't know anything about German. But Google Translate and the BeoLingus online DE-EN dictionary came to the rescue. (Phil tells me he has a translation, but where's the fun in that?)

The result was satisfying:

Eine nähere Untersuchung der besonderen Eigenschaften des natürlich Kalküls fürte mich schließlich zu einem sehr allgemeinen Satz, den ich im folgenden "Hauptsatz" nennen will. Der Hauptsatz besagt, dass sich jeder rein logische Beweis auf eine bestimmte, übrigens keineswegs eindeutige, Normalform bringen lässt.

which I render,

A closer examination of the special properties of the natural calculus led me to a general theorem that I have called the `fundamental theorem'. The fundamental theorem says that any purely logical proof can be brought to a certain (incidentally, non-obvious) normal form.

And much later, after introducing the natural deduction calculi for classical (NK) and intuitionistic logic (NJ), as well as the respective sequent calculi (LJ and LK), we get to this understated result:

Hauptsatz: Jede LJ- bzw. LK-Herleitung läßt sich in eine LJ- bzw. LK-Herleitung mit der gleichen Endsequenz umwandeln, in welcher die als Schnitt bezeichnete Schlußfigur nicht vorkommt.

Every LJ- (resp. LK-)derivation can convert to a LJ- (resp., LK-)derivation with the same end sequent, in which the rule called ``snip'' does not appear.

Instead of the usual name "cut," I've merrily translated the German "Schnitt" as "snip," because it pleases me--I like direct, etymological, native translations of this kind. (OED traces the English "snip" to Low German "schnipp," not terribly far off; "cut" has, of course, OE origin.)

(Sadly, I can't remember where I got the PDF of this original. The browsable online version linked above is from Gentzen's own alma mater, Göttingen University.)

(Miscellanea: Fans of typographic history will appreciate the printer's use of letter spacing for emphasis, a practice unknown in English but apparently traditional in German, according to Wikipedia. It could be used roughly wherever we use italics in English.)

If you're like me, you thought that GROUP BY clauses partitioned your columns into "grouping columns" and "non-grouping columns" and that the MUST to be processed with aggregate functions (count, sum, max, min, average) and that the second MUST NOT be processed that way. This would have been a problem for converting Peyton Jones and Wadler's Comprehensive Comprehensions to SQL, since that technique uses a ncie uniform treatment of group-by clauses: they transform all the query's bound variables to list type for the remainder of the query. Example—here's a simple query that takes a table, groups it on values from columna a, and returns pairs of the value from a and the sum of the list of corresponding column b values:

select a, sum(b) from t group by a

Fine and simple. And as you may know, the following produces an error:

select a, b from t group by a

Because we've grouped on a, we can't just select column b within each grouping because there are multiple column b values. The DBMS will insist that we use an aggregate function to convert this collection to a primitive-type value. Such are the restrictions of the relational model.

But Peyton Jones and Wadler's proposal simply treats all columns, when grouped, as lists. So

[(a, b) | (a, b) <- t, group by a]

is a perfectly legal expression of type [([A], [B])] (letting A and B be the raw column types of a and b, resp.). What they expect you to do, to make SQLizable expressions, is to apply some other function to reduce each column, a typical example being

[(the a, sum b) | (a, b) <- t, group by a]

which corresponds to the first SQL query above: it collects the values from a and matches these with the sums of corresponding values from b. But the above syntax allows you to do things like this:

[(sum a, sum b) | (a, b) <- t, group by a]

which seems to correspond to SQL that applies an aggregate function to a grouped column as well as an ungrouped column. "Whither SQL!?" I worried! Yet all was not lost. SQL treats grouped columns as being alternately bag-typed or primitive-typed, depending on the context. So the following is a valid query:

select sum(a), sum(b) from s group by a

Huzzah! This shows SQL to be in closer accordance with a sensible, uniform, orthogonal languge such as Peyton Jones and Wadler's than I'd imagined. In other ways, too, I keep finding it easier and easier to make SQL queries out of difficult FP expressions by using little-known SQL features. Cheers, guys.

That's Microsoft, as always, blending the sublime and the ridiculous.

(Thanks also for the bogus etymology of "covariance": "In mathematics, covariance is a measure of the degree to which two variables move up or down together. The term was co-opted by the OO crowd to describe..." Way to overlook category theory, guys!)]]> http://ezrakilty.net/research/2008/08/namedgzipstream_covariance_and.html http://ezrakilty.net/research/2008/08/namedgzipstream_covariance_and.html Programming Languages Fri, 22 Aug 2008 14:50:34 +0100 I like this vision Michael Miztenmacher is promoting for a book aimed at high school sophomores that explains well-understood topics in theoretical CS and describes a big open problem in each area. Besides getting the word out about the great ideas we have, it could stir enthusiasm through the big looming problems.

When I was around that age, I gorged myself on A. K. Dewdney's The Turing Omnibus: 61 Excursions in Computer Science (now 66), which treats a variety of topics very readably. It rotates around: one chapter might be on some kind of automaton and the next on an AI technique, but each area returns in time, so it develops each in chewable doses.

Several recent language designs have offered a unified language for programming a distributed system; we call these “location-aware” languages. These languages provide constructs that allow the programmer to control the location (the choice of host, for example) where a piece of code should run, which can be useful for security or performance reasons. On the other hand, a central mantra of web engineering insists that web servers should be “stateless”: that no “session state” should be maintained on behalf of individual clients—that is, no state that pertains to the particular point of the interaction at which a client program resides. Thus far, most implementations of unified location-aware languages have ignored this precept, usually keeping a process for each client running on the server, or otherwise storing state information in memory. We show how to implement a location-aware language on top of the stateless-server model.

One instance is the end of a case, in a proof by cases. Each of these is a major branch of the proof, which dead-ends in the middle. Variables may be brought into scope, which evaporate when the case is completed, so it's important to know the bounds of that case.

My contribution, then, to the technique of proof-by-cases, is to introduce the marker "huzzah!" indicating the simple end of a case as well as one's excitement at having proven something—a miminal proof-unit, perhaps. Here it is in a screenshot:

Having trouble achieving this effect yourself? Here's a TeX macro:

\def\huzzah{\hfill\emph{huzzah!}}

Update: According to Wikipedia, "Paul Sally at the University of Chicago is known for ending proofs with a pirate face symbol." This doesn't seem to be true of the couple of books coauthored by Sally that I could get through Google Books.]]> http://ezrakilty.net/research/2008/04/huzzah.html http://ezrakilty.net/research/2008/04/huzzah.html Pure Math Thu, 03 Apr 2008 22:43:37 +0100 excellent overview of "monkey patching," or adding methods to a class from the outside, and other possible solutions to the same problem, none of which satisfy.]]> http://ezrakilty.net/research/2008/03/bracha_on_monkey_patching.html http://ezrakilty.net/research/2008/03/bracha_on_monkey_patching.html Programming Languages Thu, 27 Mar 2008 14:25:13 +0100

It's sort of hilarious that Ferro was solving cubic equations before negative numbers were worked out. It should serve as a lesson: we mathematicians often work on fancy stuff before understanding the basics. Often that's why math seemss hard! But often it's impossible to discover the basics except by working on fancy stuff and getting stuck.

—John Baez, This Week's Finds in Mathematical Physics, Week 261