Status Report: Specifying JavaScript with ML

David Herman Cormac Flanagan

Northeastern University University of California, Santa Cruz
[email protected] [email protected]

Abstract semantics. Section 7 discusses the future of JavaScript and possi-

The Ecma TC39-TG1 working group is using ML as the specifi- bilities for further exploration of the language using the Standard
cation language for the next generation of JavaScript, the popular ML reference implementation as a tool.
programming language for browser-based web applications. This
definitional interpreter serves many purposes: a high-level and 2. JavaScript 1.x
readable specification language, an executable and testable specifi- The JavaScript programming language was invented by Brendan
cation, a reference implementation, and an aid in driving the design Eich at Netscape and first appeared in 1996 in the Netscape Nav-
process. We describe the design and specification of JavaScript and igator 2.0 web browser. Despite its name, the language has little
our experience so far using Standard ML for this purpose. to do with the Java programming language beyond minor syntac-
Categories and Subject Descriptors D.2.1 [Software Engineer- tic similarities. JavaScript is a dynamically typed, prototype-based
ing]: Requirements/SpecificationsLanguages; D.3.1 [Program- object-oriented programming language with mostly lexical scope
ming Languages]: Formal Definitions and TheorySemantics and first-class function closures.
The language was first standardized at Ecma International in
General Terms Documentation, Languages, Standardization 1997 under the name ECMAScript. The third edition of the EC-
Keywords JavaScript, Standard ML, definitional interpreters MAScript specification, published in 1999, is the current standard
and forms the basis of all major implementations of JavaScript, in-
1. Introduction cluding those of Mozilla Firefox, Microsoft Internet Explorer, the
Opera web browser, Apple Safari and WebKit, Rhino (now ship-
Thirty-five years ago, John Reynolds wrote of the importance of ping as an extension language with the Java standard library), and
using definitional interpreters as a tool for language specifica- the Adobe/Macromedia Flash scripting language ActionScript.
tion (Reynolds 1972). Despite the many developments in computer In the remainder of this section we give a brief introduction
science of mathematical frameworks for formal semantics, this en- to the JavaScript programming language. Examples shown at an
gineers approach to language design and specification still holds interactive shell are prefixed with a prompt (> ).
relevance today.
In this paper we describe ongoing work in the Ecma TC39- Objects
TG1 working group using Standard ML for the specification of The primary datatype of JavaScript is the object, essentially an
the next generation of the ECMAScript programming language, associative array or table of properties with fast lookup and update:
better known as JavaScript (Ecma 1999). JavaScript is a popular
programming language for browser-based web applications, made > var o = { name: "Alice", age: 41 };
even more popular since the advent of Ajax (Garrett 2005), a style > ++o.age
of rich, interactive web applications for which JavaScript is the 42
key enabling technology. The fourth edition of the ECMAScript Functions
standard represents a major advance in the history of JavaScript,
both in the scope of the language design and in the approach to Functions are first-class values in JavaScript (and in fact are them-
specification, and ML has played an important role in the process. selves objects with property tables). Function objects close over
Our paper proceeds as follows. In Section 2, we describe the their lexical environment.
essential pieces of the original JavaScript language. In Section 3, Object methods are nothing more than properties whose values
we introduce some of the interesting new features of JavaScript happen to be functions. This results in a somewhat subtle interpre-
2.0. Section 4 describes the history of approaches to specifying tation of references to this. The interpretation of a method call
JavaScript, and Section 5 describes the rationale behind using Stan- expr .ident(val , . . .)
dard ML as a specification language by contrasting it with other
approaches. Section 6 describes some of the specific uses of Stan- is to look up the function bound to expr .ident, and invoke it with
dard ML language features for modeling elements of the JavaScript this bound to the result of the left-hand side expression expr .
> var o = { name: "Alice",
age: 42,
toString: function() {
Permission to make digital or hard copies of all or part of this work for personal or return ("[employee "
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
+ this.name
on the first page. To copy otherwise, to republish, to post on servers or to redistribute + "]");
to lists, requires prior specific permission and/or a fee. } };
ML07, October 5, 2007, Freiburg, Germany. > print(o.toString());
Copyright c 2007 ACM 978-1-59593-676-9/07/0010. . . $5.00 [employee Alice]
Because methods are unrestricted function values and may be Name management
bound to ordinary lexical variables, there are no restrictions on the The only reliable form of information hiding in JavaScript 1.x
appearance of this. Rather, in ordinary function calls, the binding is lexical scope. Because all object properties are accessed by
of this defaults to the single global object, an ambient object string names, it is not possible to prevent clients from guessing or
whose properties include the top-level variable bindings. discovering object properties that are meant to be internal.
> var name = "Nobody"; To provide some name control while retaining backwards-
> var f = o.toString; compatibility, JavaScript 2.0 is generalizing property names from
> print(f()); simple strings to pairs of special namespace values and string
[employee Nobody] names. When the namespace is left unspecified, a default names-
pace is used to preserve backwards-compatible behavior. However,
Prototypes programs can generate lexically scoped, hidden namespaces and
explicitly store private data in properties keyed by these names-
The object system of JavaScript is based on prototypes, inspired paces.
by the Self programming language (Ungar and Smith 1987). At
runtime, every object has an implicit link to another object, its pro- Gradual typing
totype. Property lookup (for dereference, assignment, or method With the desire to create sophisticated applications comes the need
call) recursively searches the prototype chain, providing a dy- to document and check program invariants as types. JavaScript
namic form of inheritance. 2.0 is introducing a static type system with both nominal types to
Programmers can explicitly construct the prototype relation- support the class-based portion of the language and structural types
ships of new objects by creating constructor functions. Any func- such as function types, array types, and record-like object types,
tion in JavaScript can serve as a constructor. The runtime system to support functional and lightweight object-oriented programming
uses the prototype property of the function object to create the idioms.
internal prototype link of new objects. As a simple example, con- Naturally, backwards-compatibility demands that dynamically-
sider a definition of an Employee constructor: typed programs continue to work unchanged. Some of the legacy
function Employee(name, age) { constructs of the language, such as the prototype system, are no-
this.name = name; toriously difficult to fit into a static typing discipline (Anderson
this.age = age; et al. 2005; Thiemann 2005). Furthermore, common idioms in web
} applications involve dynamic constructs such as loading and eval-
Employee.prototype = { uation. For all these reasons, JavaScript 2.0 needs to support flexi-
toString: function() { ble interoperation between static and dynamic typing. This style of
return ("[employee " type system has become popularly known as gradual typing (Siek
+ this.name and Taha 2006, 2007; Herman et al. 2007). As of July 2007, there
+ "]"); is still ongoing discussion regarding what notion of gradual typing
} will be supported by JavaScript 2.0.
};
Control constructs
Every instance of Employee inherits the properties of the proto- JavaScript 1.x already contains several non-local control con-
type, namely the toString method: structs, including for, while, and do loops, the standard break
> var a = new Employee("Alice", 42); and continue loop control operators, simple untyped exceptions,
> var b = new Employee("Bob", 34); and return. JavaScript 2.0 is introducing several new control con-
> print(a.toString()); structs that we model in Standard ML.
[employee Alice] In JavaScript 2.0, function calls that are not within the scope of
> print(b.toString()); an exception handler and that appear in tail position with respect to
[employee Bob] the return operator are specified to be tail calls. There are several
subtleties involved in designing tail calls for JavaScript, including
Notice that this is bound to the newly created object in the body function return-type checks in gradually-typed languages (Herman
of the constructor function when called with new. et al. 2007).
JavaScript 2.0 is introducing a form of coroutines called gener-
ators, based on a construct from Python (Schemenauer et al. 2001;
3. JavaScript 2.0 van Rossum and Eby 2005). A generator is a function that uses the
The work in progress on ECMAScript Edition 4/JavaScript 2.0 new yield keyword to suspend its current activation and return an
represents a significant revision to the language (Horwat 2001). intermediate value to the calling context. Callers can resume the
The advent of Ajax (Garrett 2005) has increased the popular- suspending activation, passing in a value for the yield expression
ity and prevalence of increasingly complex web applications. As to evaluate to. We discuss the specification of generators in Sec-
JavaScript applications have grown in maturity and sophistication, tion 6.
so too must the language to keep up with the needs of its commu-
nity. 4. Evolution of ECMAScript specifications
Previous editions of the ECMAScript standard used a simple, im-
Class-based OOP perative pseudocode as a meta-language for semantics specifica-
One of the most common idioms found in contemporary JavaScript tion, such as the example shown in Figure 1. This meta-language
applications and frameworks is emulation of class-based object- was never formally specified, but its semantics was perhaps sim-
orientation through the prototype system. JavaScript 2.0 is there- ple enough to be inferred. Nevertheless, the low level of abstraction
fore standardizing a system of classes and interfaces similar to Java and imperative nature of the language (including both mutation and
or C] (Gosling et al. 2000; Ecma 2006). go to) sometimes resulted in rather obfuscated pseudocode. Even
Grammar production:
ConditionalExpression LogicalORExpression ? AssignmentExpression : AssignmentExpression

Evaluation:
1. Evaluate LogicalORExpression. fun evalCondExpr (regs:REGS)
(cond:EXPR)
2. Call GetValue(Result(1)). (thn:EXPR)
3. Call ToBoolean(Result(2)). (els:EXPR)
: VAL =
4. If Result(3) is false, go to step 8. let
5. Evaluate the first AssignmentExpression. val v = evalExpr regs cond
6. Call GetValue(Result(5)). val b = toBoolean v
in
7. Return Result(6). if b
8. Evaluate the second AssignmentExpression. then evalExpr regs thn
else evalExpr regs els
9. Call GetValue(Result(8)). end
10. Return Result(9).

Figure 1. Pseudocode from ECMAScript Edition 3 (left) compared with corresponding Standard ML code (right).

more problematic was the fact that the pseudocode was not exe- act structure of abstract syntax tree), and a rather surprising amount
cutable, which precluded testing. This resulted in quite a few bugs of iteration and refactoring. The reference implementation is now
in the standard (Horwat 2003a). over 20 KLOC of ML code, with the main phases being:
Due to the limitations of earlier, informal specification mech- parsing (7 KLOC),
anisms, there was a clear desire on the part of the committee for
some sort of formal or executable specification, whereby the abil- a definition phase that includes name resolution and identifying
ity to execute this specification on a variety of JavaScript programs compile-time constants (3 KLOC),
would help detect errors early in the language design process, and type checking (2 KLOC),
would provide additional confidence in the correctness, complete-
and evaluation (5 KLOC).
ness, and consistency of the final specification.
In the initial stages of development of ECMAScript Edition 4, In addition, there is around 10KLOC of ES4 code that defines most
Waldemar Horwat addressed the lack of precision in previous stan- of the Javascript standard libraries. Writing this code in ES4 helps
dards by defining an Algol-like, typed metalanguage. Early propos- reduce the complexity of the core semantics, with some cost in
als used this metalanguage to specify the language constructs, and performance.
an implementation in Common Lisp served as an early reference A pre-release of this reference implementation is available at
implementation (Horwat 2003b,c). Horwat attempted to provide a http://www.ecmascript.org/download.php.
denotational interpretation for the types and terms of the metalan-
guage, but this proved unwieldy. 5. Language specification styles
Beginning in early 2006, we explored the use of term-rewriting
languages such as Stratego (Visser 2001) or PLT Redex (Matthews In this section we briefly reflect on our experiences to date in using
et al. 2004) to develop an executable operational semantics. In order ML to write a definitional interpreter for ECMAScript Edition 4,
to accomodate the non-trivial static semantics and syntactic sugar and compare this approach with two commonly-used alternatives:
in the language, we considered designing yet another intermediate informal prose, such as is used in the Java Language Specifica-
language that would be close in flavor to the pseudocode in pre- tion (Gosling et al. 2000);
vious specifications, while still being fully formalized. However,
formal, mathematical specifications, such as that used to specify
this approach would essentially have required designing two lan-
guages concurrently (ECMAScript Edition 4 and its specification Standard ML (Milner et al. 1997).
language), introducing significant additional work and perhaps un- Thus, the choice of language specification styles can be succinctly
necessary complexity. summarized as
Hence, in November 2006, we decided to use an existing pro-
gramming language as the specification language for Edition 4, Code vs. Prose vs. Math
with ML being an obvious choice for the specification language. 5.1 Language specifications: Code vs. Prose
There was some subsequent discussion of which dialect of ML to
use, with the committee initially leaning towards OCaml (in part Our initial discussions before November 2006 almost exclusively
due to somewhat better tool support, error messages, etc), but even- used prose, together with some JavaScript code fragments, both
tually choosing SML (based in part on arguments that it is a more in person, on whiteboards, and on a wiki (Ecma 2007). Many of
mature language and is formally specified (LtU 2006)). these discussions were at a fairly high level, and assumed a fairly
Over the next several months, much of the work of the commit- substantial amount of background knowledge regarding JavaScript
tee became essentially a software engineering effort, based around implementations. As might be expected, underlying assumptions
a version control system (Monotone 2007) and, later, a bug tracking were often left implicit and occasionally mis-understood, and the
database (Trac 2007). This work largely has involved reifying the interactions between various features were not always explored in
current language design as code. There has been a fair amount of complete detail.
discussion of various implementation details (for example, the ex- This communication style worked well early in the design pro-
cess, as various design alternatives were being compared, and there
was little benefit to fully formalizing a design alternative that may cussions and descriptions always felt overly vague and imprecise.
later be discarded. One of the authors (Flanagan) developed several formal models
Once we switched to a definitional interpreter, the interaction of the operational semantics and type systems for gradual typing,
style of the committee changed substantially, from monthly 1 12 -day but these were inaccessible to many committee members. More re-
discussion-oriented meetings to 3-day hackathons, interspersed cently, we developed a definitional interpreter for the gradually-
with technical discussions, as various corner cases in the language typed lambda calculus, which finally provided a concise and pre-
design and implementation were discovered and resolved. The def- cise description that all committee members could understand and
initional interpreter worked well in forcing the committee to clarify discuss. That is, in this instance, code succeeded where prose and
many unspoken assumptions, and provided a concrete artifact that math had both failed.
grounded many discussions that might otherwise have been overly Many of the committee members found formal semantics daunt-
abstract. It also provided valuable implementation experience for ing, especially working on an aggressive timeline. However, ev-
Edition 4. ery single member of the committee is an expert programmer. Ex-
The style of code is an important aspect of a definitional inter- pressing semantics in a programming language, albeit unfamiliar
preter. Overall, there was fairly clear agreement on clarity over to some, turned out to be far more accessible than many semantics
performance, that is, the primary goal of the definitional inter- formalisms. This allowed more committee members to contribute
preter is to be define the language specification, rather than describe to the specification rather than leaving a small subset of the mem-
a realistic, efficient implementation of that language. We strive to bers on the critical path. We expect this will have benefits for the
emphasize clarity, readability, and abstractness in our code, never readability of the specification as well, since more people in the tar-
efficiency. Of course, this results in a slow implementation, but the get audience are likely to be familiar with functional programming
purpose of the reference implementation is specification rather than than with formal semantics.
usability. Definitional interpreters do work at a somewhat lower level
Another important guideline we have followed is to keep the of abstraction than operational or denotational semantics, in part
core semantics as small as possible by modeling most of the stan- because they deal with more low-level details. Nevertheless, we
dard library in JavaScript, minimizing the reliance on magic believe that it has been significantly easier for the committee to
hooks into the semantics. For example, the reference implementa- formalize the Edition 4 semantics as code than as mathematics,
tion does not implement regular expressions natively in ML, even because:
though most realistic implementations would do so to improve per-
1. it requires much less specialized training;
formance.
As might be expected, writing a definitional interpreter for 2. it leverages prior experience on programming language imple-
a large and realistic language such as ECMAScript Edition 4 mentation (as opposed to semantics);
involved a substantial time investment, and required significant 3. SML provides various linguistic features (side effects, callcc,
communication and co-operation by committee members. This etc) that have proven quite useful; and
time investment included both essential and accidental complex-
ity (Brooks 1986): the essential complexity being the actual cost 4. as mentioned above, type systems and test suites are invaluable
of specifying the language semantics in full detail; the acciden- in debugging the language semantics.
tal complexity included the learning curve with SML and its tool
5.3 Language specifications: Code and Prose
suite, wrestling with unintuitive parts of the SML language, and
dealing with imprecise error messages (eg, there is a type error The increased precision of code over prose can also be a draw-
somewhere in these 200 lines of code). We partially overcame the back: because code operates at a lower level of abstraction than
latter problem by providing explicit types for all top-level func- semantics, it can result in overspecification. For example, libraries
tions. Also, the SML module system provides limited support for often leave portions unspecified to allow for multiple implemen-
mutually-recursive modules, with the result that mutually-recursive tation strategies; but an actual implementation does not have the
conceptual modules must be sometimes coalesced into a mono- freedom to leave anything undefined. Often such implementation
lithic SML module, with some loss in clarity. decisions are observable to user programs. For instance, a library
Overall, despite the overheads and costs of the definitional in- function may document its result type as an abstract interface, but
terpreter, our experience to date suggests that it works much bet- reflection facilities would allow programs to observe the concrete
ter in several regards (consistency, completeness, implementation class used to implement that interface.
experience, early defect detection, etc) than an informal English To avoid overspecification, the reference implementation does
specification. not stand on its own as a complete specification, and parts of it will
not even be included in the normative standard. Rather, the doc-
5.2 Language specifications: Code vs Math ument will excerpt portions of the interpreter where appropriate,
The definitional interpreter has essentially two goals: surrounding code with prose where necessary. The reference im-
plementation will likely be provided as an informative appendix or
to precisely define the language semantics, and companion document.
to communicate this semantics to the intended audience (to
other committee members, to language implementors, and to 6. Implementation overview
other language users).
In this section we describe some of the techniques we use for
Other language definition styles, such as operational or denota- modeling JavaScript features in ML. Because of the feature set
tional semantics, could also have satisfied the first goal but not the of Standard ML, it is possible for us to model JavaScript in a
second, in large part because mathematical semantics involves spe- direct style, using the implicit control and store of ML to model
cialized notation that is unfamiliar to large parts of the target au- those of JavaScript. Of course, we could write the interpreter in
dience. (Additional formal notations would be necessary to also continuation-passing and store-passing style, using ML as little
specify the type system of the language.) more than an executable lambda calculus. This would bring the
This limitation became quite clear in the committees discus- model closer to a formal semantics. Indeed, in some cases the price
sions of lightweight strategies for gradual typing. Our English dis- we pay for direct style is the need for somewhat less natural models
datatype VAL = Object of OBJ catches instances of TailCallException and invokes the asso-
| Null ciated thunk.
| Undef
First-Class Continuations
and OBJ = The one non-standard feature of SML that we are considering ex-
Obj of { ident: OBJ_IDENT, ploiting is callcc. Because the semantics of generators (see Sec-
tag: VAL_TAG, tion 3) involves suspending and reifying a delimited portion of
props: PROP_BINDINGS, the current continuation, some amount of reification of control is
proto: VAL ref, necessary. To convert the entire interpreter to continuation-passing
magic: MAGIC option ref } style just to support this one, largely orthogonal language feature
would be unfortunate. Instead, we could use a non-native encoding
and VAL_TAG = of the delimited continuation operators shift and reset imple-
ObjectTag of FIELD_TYPE list mented with native callcc (Herman 2007). While non-standard,
| ArrayTag of TYPE_EXPR list the semantics of continuations are well understood and widely im-
| FunctionTag of FUNC_TYPE plemented.
| ClassTag of NAME
6.2 Engineering the reference implementation
and MAGIC = The current pre-release of the reference implementation is built
UInt of Word32.word with Standard ML of New Jersey (Appel and MacQueen 1991).
| Int of Int32.int We are currently working on ports to MLton (Weeks 2006) and
| ... SML.NET (Benton et al. 2004). Porting to multiple implementa-
tions of SML has helped us to discover non-standard features we
withtype OBJ_IDENT = int used unwittingly, improving portability and forcing us to code to
the standard language. We also hope to reap the benefits each im-
and PROP = { ty: TYPE_EXPR, plementation has to offer, specifically performance from MLton
attrs: ATTRS, and interoperability from SML.NET.
state: VAL } The reference implementation is already delivering on its
promise to help with testing. The first and probably most impor-
and PROP_BINDINGS = (NAME * PROP) list ref tant tests we have performed are regression tests: both Mozilla
and Adobe have contributed sizeable test suites from their own
Figure 2. Definition of runtime values in ECMAScript Edition 4. implementations of ECMAScript. The current build passes more
than 93% of the Mozilla regression tests. The failing test cases are
caused both by out-of-date tests (written for previous versions of
of individual features. But writing in direct style allows us to keep the language), or tests that use features that the reference imple-
these representations localized, resulting in a more modular and mentation does not yet implement correctly.
comprehensible language definition.

6.1 Features of ML 7. Whats next

Reference cells Since SML is a formally-specified language (Milner et al. 1997),
we argue that the definitional interpreter provides a fully-formal
The vast majority of the reference implementation is written in semantics, if sometimes overspecified. We hope this definitional
a pure functional style. However, for specifying the imperative interpreter will provide a foundation for further research. In par-
elements of JavaScript, reference cells provide a natural model of ticular, it enables us to concisely formalize type soundness for
mutable variables and object properties. JavaScript:
Figure 2 shows most of the data definition for ECMAScript
Edition 4 values in Standard ML. There are two special sentinel if a JavaScript program passes the type checker,
values in ECMAScript Edition 4, null and undefined; all other then certain run-time errors do not occur.
values are of the Object variant of VAL. Every object has a unique Given the size of the definitional interpreter (upwards of 20
identity, a runtime type tag, a mutable table of properties, a link to a KLOC), unsurprisingly type soundness remains unproven. How-
prototype object, and an optional magic internal value. This latter ever, various forms of model checking could be applied to discover
field is used to handle values of primitive types such as integers and counter-examples to type soundness (Darga and Boyapati 2006),
floating point numbers. or to provide additional confidence in the implementation. Eventu-
ally, we hope interactive (but highly automated) theorem provers
Exceptions could be used to formally verify type soundness for our language
JavaScript includes a number of non-local jumps that can be mod- specification.
eled as ML exceptions, from JavaScript exceptions to loop breaks Acknowledgements: We would like to thank Lars Hansen, Bren-
and function return. Modeling tail calls is somewhat more subtle, dan Eich, and the anonymous reviewers for valuable feedback on
since installing an exception handler at the entry of every procedure this paper. This work was partially supported by a Sloan Fellow-
activation precludes using a simple tail call to an ML function. In- ship.
stead, we model a tail call as a modified trampoline (Ganz et al.
1999): the function performing a tail call raises an exception of
type References
Christopher Anderson, Paola Giannini, and Sophia Drossopoulou.
exception TailCallException of (unit -> VALUE)
Towards type inference for javascript. In 19th European Confer-
with a thunk to invoke the tail function. The semantics of non- ence on Object-Oriented Programming (ECOOP 2005), pages
tail function calls includes wrapping the call in a handler that 428453, 2005.
Andrew W. Appel and David B. MacQueen. Standard ML of new 2004.
jersey. In J. Maluszynski and M. Wirsing, editors, Proceedings Robin Milner, Mads Tofte, Robert Harper, and David MacQueen.
of theThirdInternational Symposium on Programming Language The Definition of Standard ML - Revised. The MIT Press, May
Implementation and Logic Programming, pages 113. Springer 1997. ISBN 0262631814.
Verlag, 1991.
Monotone 2007. Monotone: Distributed version control, 2007.
Nick Benton, Andrew Kennedy, and Claudio V. Russo. Adventures URL http://monotone.ca/.
in interoperability: the sml.net experience. In PPDP 04: Pro-
ceedings of the 6th ACM SIGPLAN international conference on John C. Reynolds. Definitional interpreters for higher-order pro-
Principles and practice of declarative programming, pages 215 gramming languages. In Proceedings of the ACM Annual Con-
226, New York, NY, USA, 2004. ACM Press. ISBN 1-58113- ference, pages 717740, New York, NY, August 1972. ACM
819-9. Press.
Frederick P. Brooks, Jr. No silver bullet: essence and accidents Neil Schemenauer, Tim Peters, and Magnus Lie Hetland. Simple
of software engineering. In Information Processing 86, pages generators, May 2001. URL http://www.python.org/dev/
10691076, 1986. International Federation of Information Pro- peps/pep-0255/. PEP-255.
cessing (IFIP) Congress 86. Jeremy G. Siek and Walid Taha. Gradual typing for functional
Paul T. Darga and Chandrasekhar Boyapati. Efficient software languages. In Scheme and Functional Programming Workshop,
model checking of data structure properties. In OOPSLA 06: September 2006.
Proceedings of the 21st annual ACM SIGPLAN conference on Jeremy G. Siek and Walid Taha. Gradual typing for objects. In
Object-oriented programming systems, languages, and applica- ECOOP, Berlin, Germany, July 2007.
tions, pages 363382, New York, NY, USA, 2006. ACM Press.
ISBN 1-59593-348-4. Peter Thiemann. Towards a type system for analyzing javascript
programs. In European Symposium On Programming, pages
Ecma 2007. ECMAScript Edition 4 specification wiki, 2007. URL 408422, 2005.
http://wiki.ecmascript.org.
Trac 2007. The Trac Project, 2007. URL http://trac.
Ecma 2006. C] Language Specification. Ecma International, 4th edgewall.org/.
edition, 2006. ECMA-334.
David Ungar and Randall B. Smith. Self: The power of simplicity.
Ecma 1999. ECMAScript Language Specification. Ecma Interna- In Norman Meyrowitz, editor, Proceedings of the Conference on
tional, 3rd edition, 1999. ECMA-262. Object-Oriented Programming Systems, Languages, and Appli-
Steven E. Ganz, Daniel P. Friedman, and Mitchell Wand. Tram- cations (OOPSLA), pages 227242, New York, NY, 1987. ACM
polined style. In International Conference on Functional Pro- Press.
gramming, pages 1827, 1999. Guido van Rossum and Phillip J. Eby. Coroutines via enhanced
Jesse J. Garrett. Ajax: A new approach to web applications, 2005. generators, May 2005. URL http://www.python.org/dev/
peps/pep-0342/.
James Gosling, Bill Joy, Guy Steele, and Gilad Bracha. The
Java Language Specification, Second Edition. Addison-Wesley, Eelco Visser. Stratego: A language for program transformation
Boston, Mass., 2000. ISBN 0-201-31008-2. based on rewriting strategies. System description of Stratego
0.5. In A. Middeldorp, editor, Rewriting Techniques and Ap-
David Herman. Functional Pearl: The Great Escape. In Interna- plications (RTA01), volume 2051 of Lecture Notes in Computer
tional Conference on Functional Programming (ICFP), October Science, pages 357361. Springer-Verlag, May 2001.
2007. To appear.
Stephen Weeks. Whole-program compilation in MLton. In ML
David Herman, Aaron Tomb, and Cormac Flanagan. Space- 06: Proceedings of the 2006 workshop on ML, pages 11, New
efficient gradual typing. In Trends in Functional Programming, York, NY, USA, 2006. ACM Press. ISBN 1-59593-483-9.
April 2007.
Waldemar Horwat. ECMAScript edition 3 errata, June
2003a. URL http://www.mozilla.org/js/language/
E262-3-errata.html.
Waldemar Horwat. JavaScript 2.0: Evolving a language for
evolving systems. URL http://www.mozilla.org/js/
language/evolvingJS.pdf. Lightweight Languages Work-
shop (LL1), 2001.
Waldemar Horwat. ECMAScript 4 Netscape proposal, June 2003b.
URL http://www.mozilla.org/js/language/old-es4.
Waldemar Horwat. JavaScript 2.0 experimental semantics,
2003c. URL http://lxr.mozilla.org/mozilla/source/
js2/semantics/.
LtU 2006. Specifying ECMAScript via ML, November 2006. URL
http://lambda-the-ultimate.org/node/1784.
Jacob Matthews, Robert Bruce Findler, Matthew Flatt, and
Matthias Felleisen. A visual environment for developing
context-sensitive term rewriting systems. In International Con-
ference on Rewriting Techniques and Applications (RTA2004),