Language Size (was Re: [TLUG]: ECMAScript ("Javascript") Version4 - FALSE ALARM)

[Lars Hansen]

> -----Original Message-----
> From: es4-discuss-bounces at mozilla.org 
> [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Maciej 
> Stachowiak
> Sent: 31. oktober 2007 11:47
> To: Maciej Stachowiak
> Cc: es4-discuss; Steven Johnson; Chris Pine
> Subject: Re: Language Size (was Re: [TLUG]: ECMAScript 
> ("Javascript") Version4 - FALSE ALARM)
> 
> 
> Does anyone else have other ideas for objective metrics of 
> language size?

Complexity of the implementation, certainly.  Complexity of the
semantics, maybe.

I joined TG1 in early 2006 as a representative of Opera (the position
Chris Pine occupies now).  My main concern was then to make sure the new
language could be handled by an implementation that would just read
source code off the wire and compile it in an on-line fashion,
generating code as it went along, without building trees for anything
more complex than expressions and without maintaining databases of
compiler-only data.  (I know for a fact this is possible for ES3, and it
would be helpful to embedded implementations if it was also possible for
ES4.)  The language should be implementable by a system that could, as
Graydon wrote the other day, evaluate everything lazily and not worry
about a thing until it couldn't put them off any longer, just like the
case is for ES3.

(A fallout of that (my victory or my fault, depending on how you see it)
is that ES4 does not require things like definite assignment analysis,
which would have required more elaborate data structures than a compiler
on an embedded system would be happy with.  Instead we have a syntactic
workaround (the "settings" section of the constructor) and other rules
to handle non-nullability.  Kludgy?  Depends on your point of view.  My
view is that embedded is a prime target for the language, and we adapt
accordingly.  Until most phones have fast CPUs and a lot of RAM,
embedded is hard.)

I still think that ES4 can be compiled that way, classes and packages
and parameterized types and all.  And I do think that says something
about the relatively low complexity of the language and how fit it is
for difficult environments.

(In fairness, we don't know yet how well a commercial implementation can
do on-line compilation under the pressure of performance requirements
both for the compiler and for the compiled code, but I have confidence,
based on no little experience from ES3, that it will be fine.)

--lars