Today was mostly a catch-up day. In the morning there was much Web Page Editing done concerning my and my advisor's ICFP submission — he made a big performance improvement to Redex but it broke backwards compatibility, so I needed to update all the sample code from our paper to make it work. In addition, Redex is now distributed via my package management system, PLaneT; the instructions got changed too.

After that was Adam's jazz concert. Swank!

Afterwards there was work done on the Programming Contest. That cannot be talked about too much, so I'll just say that it was done.

I've been thinking more and more recently about the concept of a persistent-set-based functional programming language. I have over the last several years found that continuations are a fundamental idea behind web programming; over the past couple years of actually implementing web services, I've come to the opinion that persistence is another one. When you write a web service, nine times out of ten you're going to be writing a program that has some kind of sequential programmatic logic, but ninety-nine times out of a hundred its job will be either to read data from a database, write data to a database, or both. Fundamentally, the notion that's being captured is that there's some information independent of any program to which a web application is giving you some kind of interface.

I think this is actually more important than continuations for web programming, as demonstrated by the truly staggering array of web technologies that do nothing or virtually nothing to address the continuation problem but that nail database access (here ColdFusion is the earliest example I can think of, but by no means the only). We know that for control, continuations are a natural and powerful way to model the phenomenon of web interaction, but is there anything better than glorified SQL syntax for modeling persistence?

My guess is that the answer is that a programming language should have strong support for tuple sets as values, and that those tuple sets should be naturally persistent and program-independent (but be able to store any kind of value, including functions and continuations, anyway). Python and Lua, among probably dozens of others I don't know about due to woeful ignorance, are based on the notion of a hash-table as the fundamental value around which the language is based; what would a language based around persistent tuple-sets look like?

There are bunches of languages like PL/SQL around that have answers to that question, but they're not particularly satisfactory. For one thing, they're centered around the database; I'm more interested in sets as sets (with database backing) rather than databases as the inspiraton for semantics. For another, I think that sets could be treated completely functionally except for the points at which they are remembered.

I don't know whether this idea can be done in Scheme, just because Scheme has already got so much listiness built-in already. Furthermore, I think for web programming a typed language is the right choice -- unit testing is difficult, XHTML is a complicated datatype, and programs rarely need the extra expressiveness you get in an untyped language. I don't know where all this is going, though, and I don't have time to go there right now. But it's something to think about.