Washington, D.C., part 2: Choosing the SCOTUS arguments and when to arrive

(Just started reading? See part 1.)

If I was to combine a trip with a visit to family for Easter, I was limited to arguments in April. One sitting stood out as particularly interesting: the April 18 sitting in which Tapia v. United States and Microsoft v. i4i Limited Partnership would be argued. Tapia concerned the permissibility of considering in-prison rehabilitative programs during sentencing — not an issue of particular interest to me. But Microsoft concerned patents, which are certainly relevant to anyone in the software industry. It made a good fit: my weekend was chosen.

The US Capitol at night from Constitution Avenue, northeast of Capitol Hill
02:17: The Capitol as seen on the walk to the Court

Supreme Court oral arguments are open to anyone who arrives “early enough”, which depends on the interest level of the cases being argued. Tapia, as a sentencing case not touching a contentious issue like the death penalty, was low-interest. But “the showcase intellectual property case of the year” might well draw a moderate crowd. And I knew from a Mozillian who’d attended Bilski v. Kappos, the last major patent case before the Court, that arriving at 22:00 the day before a patent case could be good for a spot near the end of public seating. (Huge caveat: the other arguments that day concerned juvenile life imprisonment without possibility of parole.)

The Capitol dome
02:18: The Capitol dome

Based on one suggestion of 05:00 for “mid-major” cases (which I suspected Microsoft to be) and the effort I was making just to get to D.C., I decided to err heavily on the side of caution by waking up at 1:00. I would take a shower, get dressed in a suit purchased Friday (Visa flagged it as a fraudulent transaction, and I think they were on to something), and walk forty minutes to the Supreme Court. Better to get less sleep but be guaranteed to see the argument than to gamble and lose after making such an effort to even have a chance to see it.

The Capitol dome and the south wing of the Capitol building
02:34: The Capitol from the east, between it and the Supreme Court

Next time: sitting in line for the arguments.


Washington, D.C., part 1: Bobbleheads!

Among my various eccentricities, I subscribe to the Green Bag, an entertaining journal of law (I read about equally for entertainment and for interesting knowledge) which occasionally produces extra gifts, such as Supreme Court justice bobbleheads, for its subscribers. If the Green Bag sends you a certificate, you might (they qualify to the hilt any possibility you might get anything other than the subscription) be able to go to George Mason University just outside Washington, D.C. and exchange it for some number of bobbleheads. (Or have a proxy do it, but that has its own problems.)

A few months ago the Green Bag sent me a certificate potentially good for bobbleheads. I live on the west coast, so how was I to redeem it? I’m not crazy enough to fly across the country just for bobbleheads (even Supreme Court bobbleheads!). But if I planned it right, I could combine a trip with one to visit family for Easter, economizing the number of long-distance flights I’d take doing both trips. It was enough justification for me to visit D.C. from April 15 to April 19.

John Jay, John Rutledge, William Cushing, James Wilson bobbleheads
John Jay, John Rutledge, William Cushing, James Wilson: the four senior members of the first Supreme Court

I’m not much of a tourist, so I didn’t visit museums or do much traditional exploration in D.C. (I also planned to work most of Friday and Monday while visiting, a plan mostly-successfully executed from a couple Starbucks.) I caught up with a couple friends (Mozillians may remember Joey Minta of calendar, Thunderbird, and kill-rdf fame, now working at a D.C. law firm) and attempted to catch a game of ultimate on the National Mall that got foreclosed by rain. I also tried to sample area cuisine: Five Guys (NB: they’re in Sunnyvale now!), Founding Farmers, Potbellys (not especially local to D.C., but I’d never seen them before), and Momiji Restaurant (the Asian pear martini was quite tasty).

But most specially, I went to a sitting of the Supreme Court and watched two oral arguments. More on that over the next several days, starting with which cases to attend and when to arrive.


JavaScript change for Firefox 5 (not 4): class, enum, export, extends, import, and super are once again reserved words per ECMAScript 5

Most programming languages have keywords or reserved words: names which can’t be used to name variables. Keywords have special meaning, so using them as variable names would conflict with such use. Reserved words are keywords of the future: names which might eventually be given special meaning, so they can’t be used now to ease future adoption.

JavaScript and the ECMAScript standard that underlie it historically have had an excessively large set of keywords and reserved words “inherited” from Java. ES5 partially loosened ES3‘s past keyword restrictions. For example, byte, char, and int were reserved in ES3 but aren’t in ES5.

Many years ago, before work started on ECMAScript after ES3, a few browsers stopped reserving all of ES3’s reserved words. In response browsers generally started to un-reserve many of these names. As it turned out this un-reservation went too far: ES5 un-reserved many of these words, but it didn’t un-reserve all of them. In particular, while some implementations un-reserved the names class, enum, export, extends, import, and super, ES5 did not.

Firefox un-reserved these names then along with some other browsers. But as ES5 corrects the over-reservation of ES3 without un-reserving these names, we are moving to align with ES5 by re-reserving class, enum, export, extends, import, and super in all code. (Firefox 4 reserves these names only in strict mode code.)

You can experiment with a version of Firefox with these changes by downloading a TraceMonkey nightly build. Trunk’s still locked down for Firefox 4, so it hasn’t picked up these changes just yet. (Don’t forget to use the profile manager if you want to keep the settings you use with your primary Firefox installation pristine.)


Considering a new keyword for Bugzilla

Bug databases track issues at several levels.

There’s the level of the specific problem. For example: this sequences of graphics calls causes a crash.

Then there’s the level of the meta-bug: a bug tracking a number of different issues in some genre. For example, there might be a bug tracking, say, crashes involving some particular feature: graphics drawing functionality, for example. In Bugzilla this is known as a “meta-bug”, because it isn’t really a bug but rather a bug about bugs. In b.m.o such bugs are given the meta keyword.

Last, there’s the level consisting of bugs which track meta-bugs. For example, you might have a bug tracking a bug for crashes involving graphics drawing functionality, a bug for rendering glitches involving graphics drawing functionality, a bug for unimplemented functionality in the specification, a bug for performance problems involving graphics drawing functionality, and a bug tracking progress at investigating the relative stability of graphics functionality run on hardware with various graphics cards and driver versions. The logical progression is to call this a “meta-meta-bug”.

Therefore, shouldn’t Bugzilla have a meta-meta keyword to associate with such bugs? But let’s not be over-hasty: let’s have a fair discussion first. Perhaps people should comment or blog about this idea a bit. What do readers think?


JavaScript change in Firefox 5 (not 4), and in other browsers: regular expressions can’t be called like functions

Callable regular expressions

Way back in the day when Netscape implemented regular expressions in JavaScript, it made them callable. If you slapped an argument list after a regular expression, it’d act as if you called RegExp.prototype.exec on it with the provided arguments.

var r = /abc/, res;

res = r("abc");
assert(res.length === 1);

res = r("def");
assert(res === null);

Why? Beats me. I’d have thought .exec was easy enough to type and clearer to boot, myself. Hopefully readers familiar with the history can explain in comments.


Callable regular expressions present one immediate problem to a “naive” implementation: their behavior with typeof. According to ECMAScript, the typeof for any object which is callable should be "function", and Netscape and Mozilla for a long time faithfully implemented this. This tended to cause much confusion in practice, so browsers that implemented callable regular expressions eventually changed typeof to arguably “lie” for regular expressions and return "object". In SpiderMonkey the “fix” was an utterly inelegant hack which distinguished callables as either regular expressions or not, to determine typeof behavior.

Past this, callable regular expressions complicate implementing callability and optimizations of it. Implementations supporting getters and setters (once purely as an extension, now standardized in ES5) must consider the case where the getter or setter is a regular expression and do something appropriate. And of course they must handle regular old calls, qualified (/a/()) and unqualified (({ p: /a/ }).p()) both. Mozilla’s had a solid trickle of bugs involving callable regular expressions, almost always filed as a result of Jesse‘s evil fuzzers (and not due to actual sites breaking).

It’s also hard to justify callable regular expressions as an extension. While ECMAScript explicitly permits extensions, it generally prefers extensions to be new methods or properties of existing objects. Regular expression callability is neither of these: instead it’s adding an internal hook to regular expressions to make them callable. This might not technically be contrary to the spec, but it goes against its spirit.

Regular expressions won’t be callable in Firefox 5

No one’s ever really used callable regular expressions. They’re non-standard, not all browsers implement them, and they unnecessarily complicate implementations. So, in concert with other browser engines like WebKit, we’re making regular expressions non-callable in Firefox 5. (Regular expressions are callable in Firefox 4, but of course don’t rely on this.)

You can experiment with a version of Firefox with these changes by downloading a TraceMonkey nightly build. Trunk’s still locked down for Firefox 4, so it won’t pick up the change until Firefox 4 branches and trunk reopens for changes targeted at the next release. (Don’t forget to use the profile manager if you want to keep the settings you use with your primary Firefox installation pristine.)

« NewerOlder »