Via Dave Herman and Lambda the Ultimate: ADTs in JavaScript 1.8. Shouldn’t be too hard to Flapjax-ify, which might make the handling of lists a little nicer.
I have to say, I can breathe a sigh of relief now that the expression problem has been solved in JavaScript. All of the interpreters and compilers I’d written in JavaScript were so inextensible!
Reading this experience report from the DARPA challenge via Slashdot, I wondered: if event registration caused object retention, how can we deal with these memory issues in Flapjax?
Worrying about memory leaks in JavaScript is a losing battle — the browsers have different collectors. But given functional reactive programming in other settings (e.g., Java/C#), how can we solve this kind of problem? We looked at deletion briefly, but never had time to address the issue in detail. The complexity in our case is that the event registration encodes the entire application — how do you decide that a certain code path is dead? It may be helpful to view a functional-reactive program as a super-graph of data producing, splitting, merging, and consuming nodes; the application state is the subgraph induced by the active nodes reaching the consumers. Then there’s a certain static overhead for the program, plus the dynamic overhead of its active components.
Most of the Flapjax code I’ve written has been for the user interface, so binding and unbinding isn’t much of an issue: if the interface changes temporarily (e.g., tabs), the older behavior is usually recoverable and shouldn’t be collected. When working with more complex models with longer lived state, a deletion policy is more important. Shriram has been working on larger Flapjax applications with application logic as well as presentation — I wonder if he’s run into serious GC issues.
In the Flapjax programming language, ‘lifting’ is the automatic conversion of operations on ordinary values into operations on time-varying values. Lifting gets its name from an explicit operation used with Flapjax-as-a-library; we use the transform method call or the lift_{b,e} functions. To better understand lifting, we’ll walk through a simple implementation of the Flapjax library.
I consider the (excellent) Flapjax tutorial prerequisite reading, so it will be hard to follow along if you’re not vaguely familiar with Flapjax.
The following code is all working JavaScript (in Firefox, at least), so feel free to follow along.
I spent about two hours tracking down a DOM node sharing bug — nodes were being put into a new structure outside of the document before the salient data had been read out. While there was no information in these nodes, the lens system insisted that they still be there. (More on that — eventually.)
After finally tracking it down and writing a version of cloneNode that also copies event handlers, everything worked. Between this and the last prototype aliasing bug I had, I got an idea. A programmer could keep a “bug journal”, a list of bugs found and described first by their behavior, then by their solution (and, if those two aren’t descriptive enough, the underlying problem should be described as well). For example, two days ago I ran into my first genuine typing bug in JavaScript — a type checker would have rejected my program, and from the errors generated it wasn’t obvious where the problem was.
This practice could be useful in a few ways. First, the process of writing down the description can help the programmer find the solution. Tedious, but perhaps worthwhile. Surely some bugs would end up being described post facto, since it’s not worth the time when the fix is fairly clear. Second, the solution may add to a ‘bag of tricks’ at the programmer’s/team’s disposal. Third, the bug and solution tease out invariants in the program, and so the bug journal could be gleaned for inter-module and system-level documentation.
Fourth, and dearest to my heart, I think it’s an interesting way to evaluate programming languages. The bug log of a programmer writing an e-mail interface in Java and that of one writing such an interface in JavaScript would provide for some interesting contrasts. To provide more than anecdotal evidence, you’d need to use a much larger sample size of programmers and kinds of programs being written.
I think the bug journal would differ profoundly from examination of bug tracking logs. Only the truly mysterious bugs and the large, architectural shortcomings make it into the tracker. On a daily basis, programmers struggle with making buggy code workable — before it ever hits version control. So bug tracking logs can highlight difficulties in design and with the team, but a bug journal shows exactly what a programmer has to deal with.
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.
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.
The response to the template language in Flapjax has been mixed, to say the least. The most common complaint is that they mix content with style. True — this can be done with our templates. But nothing stops a developer from putting CSS in the HTML directly. Nothing except good sense, that is.
In response to a recent post on our discussion group for Flapjax, I wrote about this briefly:
…the only compiler specific syntax is the templates: curly-bang — {!, !} and triple-stick — |||. But these are parsed out of HTML PCDATA and attribute nodes, so a JavaScript/Flapjax programmer needn’t consider them. We introduced the syntax as a way to reduce the clutter of “insertDomB” and “insertValueB” calls. For example, the template language is:
It's been {! currentSeconds ||| (loading...) !} seconds since the beginning of 1970, and it's all been downhill.while we must write the following without it:
It's been (loading...) seconds ... .This can become a huge mess, so the templates simplify it. We wouldn't want to encourage doing all of your computation in the display layer! I'd compare it to Smarty or JSP -- while you can include complex computations in the tags, it's meant only to ease the interface between models in code and presentations on screen.
I think that soundly characterizes the template language. Shriram wants that in the tutorial, so that'll show up there eventually. (Some people take classes during the semester, but the Flapjax team has much more important things to do. Or so we're told.) But it would be a big mistake to see Flapjax as providing just that -- the functional reactivity is the interesting bit.
Tonight we're presenting the language to the undergraduates in the DUG; there's an exciting contest announcement coming up, as well. Who has time for midterms?
Since I got back from Israel, I’ve been working on a top secret project: a programming language for the Web. Well, for the Web 4.0 — we gave 3.0 a miss. The language is Flapjax. As you’ll note on the homepage linked above and on the Flapjax development blog, it’s multifaceted. I’ll mention the salient major features here.
The main feature is functional reactivity, found in flapjax.js. Functional reactive programming (FRP) has been around for a while in the Haskell community. The PhD lead on our project, Greg Cooper, wrote FrTime (read Father Time), which embeds FRP in Scheme.
To learn more about FRP, you might as well walk through our tutorial. It’s a callbackless world in which values vary over time and whole expressions are appropriately re-evaluated. For example, the text in a textbox can be computed with over time — no need to register callbacks for onfocus, onblur, onthis, or onthat.
In essence, FRP is a monad. But in practice, this means that FRP is a driver/callback manipulator and CPS-ed code. In FrTime, CPS-ing isn’t done directly, but instead all of the language’s primitives (+, cons, etc.) are lifted. In Flapjax, either the programmer does it manually or the compiler (my work) translates the code to CPS. There are arguments in either direction — the compiler’s aggressiveness can make it hard to use.
While on the topic of the compiler, we also introduced a templating language for in-lining Javascript/Flapjax in HTML elements and attributes. More on this and it’s utility later.
But the Web 4.0 has to subsume all of Web 2.0. Which is where the -jax morpheme comes in. Given a functionally reactive language, we can deal with values from a server — via AJAX — as they vary over time, without having to fight with request scheduling and callback handling, and so on. In a few dozen lines (and with a Flash proxy, written by Aleks Bromfield, to get around Javascript’s outmoded security model) you can hook up, say, Google Maps and Yahoo! Local. Seriously, we did that: Yaggle. So that’s pretty cool.
If AJAX without the callback mess wasn’t enough, we also wrote a generalized object store. It’s accessed via AJAX (really AJAJ, since we use JSON extensively), and was built to allow quick and easy sharing. We don’t have a demo as cool as Yaggle yet, but it’s certainly in the works.
So that’s it. Future blogging topics are: the templating syntax, compiler internals, client API internals, basic howtos. The whole project was immensely fun. Shriram got me on board by asking me what would happen if PL people actually got together and wrote something for real — that is, fully implemented an idea and sent it out at the world in a language the world can use. We both chuckled for a moment, thinking how funny it would be to actually apply PL. And then he pointed out that there’s nothing funny about that at all.
A quick addendum: Flapjax is an experiment. Shriram will kill me for saying this, but the truth has to get out: Flapjax is a functional programming language. You can’t write loops, you can’t write if — you can use fold and map and expression-if (also called ternary if: test ? consequent : alternate). Can the world handle it? We promise, fame, riches, glory, callback elimination — the stuff of dreams! …but at what cost? All hyperbole, of course. You can write loops and if statements and so on, but we require a separation of the functional, declarative Flapjax language and the procedural, imperative world of Javascript. The real question is: do programmers know the difference?