Going to WWW

Exciting, my work with Ras on parallelizing the steps in a browser between parsing and rendering -- layout -- has been accepted to WWW 2010, as has been my work with Adrienne on membrane-style wrappers for JavaScript with aspect-like hooks for tamper-proof policies. I actually submitted 3 papers, but my favorite one was rejected :(

One day, I'll have a paper accepted outside of North America. Probably not this year =/ Now only waiting to hear about my paper from MSR..

Back to work!

Chunking away (at rule languages)

I want to demo my formalized+parallel CSS work in Tahoe next Weds (Thurs?) so I've been hacking away the last few days to put in some missing pieces. I wrote the basic cascade algorithm and moved on to translating from CSS to my (parallel) kernel language... and realized I had an ambiguity. Well, there are many -- e.g., what happens with '!important' declarations in user agent style sheets? -- but one that shouldn't have existed given a principled approach to language design.

Consider the following page:

div {
background-color: gray;
background: pink;
}
p {
background: pink;
background-color: gray;
}
...

<div> hello
<p> world

What are the background colors of the dividing box and of the paragraph? Pink and then gray. Instead of using the most specific declaration in a set of declarations, the last applicable one is used. The *only* time I would have thought that would happen is if there were conflicting most-specific definitions. But no, specificity is only a notion applied to selectors, not extended to describe what they're assigning. Now I need to back-pedal and propagate lexical positions of declarations (in theory... not a priority). Not as bad as dealing with hoisting in JavaScript, but another one of those gotchas.

I'm finding a lot of these little things. They're not earth shattering, and seem mostly due to inertia. However, especially when I'm dealing with actual layout rules, stuff is often flat out undefined -- though these points of ambiguity might also be an opportunity (e.g., pick a normative definition that facilitates parallelism ;-)).

The 'become' operator, advice, and JavaScript

I've been involved in a couple of security projects recently about adding advice to JavaScript (and the next one is ramping up!). I'm not the only one, and I've heard about uses for other contexts. What's interesting is, for most of these recent systems, the main pointcut is a reference to a function. In contrast, in almost all other aspect systems, pointcuts are based on types or some ambiguous notion of symbol name. There are compelling reasons to use references from a practical perspective (what else would a pointcut be?) and theoretical ones (e.g., type-based pointcuts, unless there's a special module system I haven't heard about, can be viewed as a source of ambient authority). But... is this new at a general level?

Gilad Bracha had a fun post about the become primitive in Smalltalk. "foo become bar" means anything that pointed to what foo points to now points to what bar pointed to and vice versa. The comments on the post are pretty good too.

Is `become' as powerful as reference-based around advice on functions? Yes:

function adviseAround (aFunc, advice) {
var swapMeIn = function () {
advice(swapMeIn, arguments);
};
aFunc become swapMeIn;
}
adviseAround(XMLHttpRequest, alert);

How about the other direction? Can we implement become (on functions) using adviseAround? Ignoring a lot of noise cases (exceptions, returns, etc.), and hoping I got the interleaving right:

function become(a, b) {
var goRaw = false;
function swap (base, advice) {
adviseAround(base, function (raw) {
if (goRaw) { raw(arguments); }
else { goRaw = true; advice(arguments); goRaw = false; }
});
}
swap(a, b);
swap(b, a);
}
become(XMLHttpRequest, alert);

At least for function objects, leaving the rest as an exercise, 'become' and 'around' are the same.

Ironically, Gilad comments "AOP. I have never made it a secret that I don't believe in that stuff." Given the above, that's an odd stance. However, he also writes "Security is another concern: containing this magic power to suspends the natural laws of the universe in a capability is crucial." Perhaps our restriction to references is what he means, distinguishing it from typical advice that can touch pretty much anything in principle. It's not an obvious approach -- for example, one of my co-workers decided to break function encapsulation due to his use cases -- but as we were interested in security, I thought it was key that we took the capability perspective.

Anyways, neato.