So I showed my confusing problem detailed in this last post to Dave Herman, who after an initial surprise, said that this was probably due to ES4 expansions method binding — that is, o.f sometimes closes over this, but sometimes not.

It doesn’t work in Opera or IE — they return false for both function calls — but it seems that if they implement ES4, the first call will eventually return true. That seems terrible to me — it was so surprising! It also makes it a little difficult to use JavaScript itself as a compiler representation, since you can’t use A-normal form if let-abstraction doesn’t work. Never mind that programmers (read: I) use let-abstraction to break up complicated expressions when debugging, and so this change in behavior will only confuse matters more.

Dave pointed out that in trade-offs between consistency and convenience, the latter sometimes wins, particularly when changes affect thousands and millions of people. But it’s not clear to me how convenient this is; it’s a tiny shortcut for those who know about it, but it’s very fragile. I’d liken it to operator precedences: in only a few cases do people take advantage of the ordering, so arithmetic expressions are generally just written out with parentheses for clarity.

JavaScript woes:

function C() {
    var _this = this;
    this.foo = function () { return _this === this; }; 
    this.bar = function () { return this.foo; };
    return this;
}
var c = new C();

What is the value of c.foo()? What is the value of c.bar()()? Both are true. But let:

var foo = c.bar()

What is the value of foo()?

If you thought it was true, you’re wrong. This doesn’t make much sense at all. Either this is captured by a dot, or it isn’t. Looking at the inner call to c.bar, it’s syntactically obvious that the call to bar has this = c. But why is that preserved when evaluating it within an outer expression, but not when we split the expression into two statements?

I’m sure this has been seen before, but I’ll probably show it to Dave Herman anyway. If I remember correctly, Python gets this right. Between this and a prototype aliasing bug I had yesterday, I’m irritated.

As an aside, I was speaking with Arjun Guha last night, and none of the conventional type theory would have helped me with these problems. In fact, I get almost no type errors in JavaScript — only grotesque object model problems.

Hutton and Wright have a paper What is the Meaning of These Constant Interruptions? in which they prove correct a semantics for exceptions and interrupts in a contrived language relative to a virtual machine by means of a compilation function.

Continue reading

A well-shaven Jim Miller gave a talk at Brown today on introducing dynamic languages into the CLR. I went because (a) they were giving away a free camera (which I didn’t get), and (b) the talk seemed actually interesting. Much more interesting than my last Microsoft talk, which was some interminably boring thing about webservices.

The talk was essentially an overview of the CLR, of the form, “Do you think this is cool? Work for us!” The focus was on IronPython‘s genesis and growth. Those kids love their Python.

I tried to ask him the following question: “You’ve talked a lot about getting basic interoperability between programs written in different languages — object-oriented, procedural, functional — but you’ve said nothing about heterogeneity of styles. How does the CLR cope with that?” I asked because he said that an interface of an object included a way to create it, modify its insides, and so on — not necessarily how I define my datatypes. But then he turned it around, and asked me for an example — the best I could come up with was Erlang’s processes and single-assignment (a red herring) or Haskell’s purity (an academic joke).

Not what I was looking for. The mismatch is more serious, but I couldn’t adequately get at it on the spot. I asked him a follow-up, about GUI programming style. Would a GUI in IronPython need to be written in some bogus Windows Forms style, all callbacks? I didn’t want to compare the callback-GUI system to Flapjax‘s, since that’d be a bit wankerish of me. I didn’t handle it well at all.

So: what did I mean to ask? On the one hand, my problem is this: the mismatch between the CLR and some paradigms is pretty clear. If I wanted to work with Windows Forms in, say, F#, I would have to write in an all-ref style. In other words, the CLR lets me program C# in the language of my choice.

On the other hand, how else would I write a GUI? Flapjax is the most viable FRP implementation I’ve seen, but it’s still extremely nascent. When interfacing with the user, what is better than direct, mutative style? Python uses callback-based Tkinter and WxPython; DrScheme uses the MrEd callback-based framework. So what gives?

I may be more comfortable in the FP world, and happier programming Scheme in Scheme, rather than C# in Scheme, or even worse, Scheme in C# — but it’s becoming increasingly clear to me that my preference may be more related to my own experience than actual advantages.