Ezra's Research

ECMAScript 4 & Apple's resistance

2008-10-13T12:14:19Z

Because I'm out of the loop with my head in a thesis, I was surprised to hear about the dropping of tail calls in the plans for ECMAScript 4. There's a bit of interesting discussion on tail calls on that thread before it wanders off into general pure/impure flames. One gem is a Google Docs spreadsheet which shows the ECMA industrial members' votes on various proposals, including Apple's bleeding-red No column. That reads to me as an uncharacteristic resistance to innovation from Apple.

Formlets; Idioms, arrows and monads

2008-09-12T12:04:05Z

[UPDATE: The broken link to "The Essence of Form Abstraction" has been fixed. Sorry!]

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.

motor sounds

2008-09-09T12:03:34Z

Overheard on #haskell:

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

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

Der Hauptsatz

2008-09-04T20:13:32Z

Had a good time today puzzling over Gerhard Gentzen's 1934 paper, "Untersuchungen über das logische Schließen. I." ("Investigations into logical reasoning"). I wanted to determine that this was really what I thought it was: the paper where he introduced cut-elimination and the subformula property, which I'm examining now in my research.

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.)

Discovery! \qedhere

2008-09-01T16:44:22Z

Just made an exciting discovery! The TeX command \qedhere can be used within an AMS proof environment; it forces the proof-tombstone to go on the present line, whereas it would normally go after the end of the \begin{proof}/\end{proof} block, which often puts it outside an itemize or enumerate environment, looking ugly on a line of its own. Of course, the command properly suppresses the tombstone at the end of the proof environment. Ah comfort, O infinite luxury of macros!

Sensible SQL: The second typing for grouped columns

2008-08-27T22:50:46Z

SQL keeps turning out to be more sensible than I thought it was.

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.

Slow blog year chez Ezra

2008-08-22T13:54:10Z

Hey, I haven't been blogging very much! Sorry about that, guys. It's just, well, research is so vague and inconclusive most of the time. But, I'll try and do better. Watch this space!

NamedGZipStream, Covariance and Contravariance

2008-08-22T13:50:34Z

Favorite MSDN article title of the month: NamedGZipStream, Covariance and Contravariance.

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!)

Mitzenmacher's Theory Book

2008-04-24T22:46:06Z

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.

null == undefined

2008-04-24T22:20:36Z

(Salad with) Steve Jenson lays it down for you: the null vs. undefined nonsense in JavaScript. Better recognize.

Yhc : Haskell -> JavaScript

2008-04-14T00:58:56Z

A note on compiling Haskell to JavaScript, and interfacing with the DOM, in Yhc.

A located lambda calculus

2008-04-13T20:19:08Z

Oh right. Last week I submitted a paper to ICFP. Here it is: "A located lambda calculus," by Ezra elias kilty Cooper and Philip Wadler. The abstract:

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.

Huzzah

2008-04-03T21:43:37Z

It's customary to indicate the end of a proof with a little square (a "tombstone"), with "Q.E.D.," or elsewise. These marks almost never seem helpful to me, but there are other points where significant proof obligations are discharge, and I wish these were marked.

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.

Bracha on Monkey Patching

2008-03-27T13:25:13Z

Gilad Bracha just gave an 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.

Fancy math, basics

2008-03-21T01:03:59Z

John Baez' enthusiasm is infectious, and his perspective appealing:

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