Classes as Sugar (was: Renaming ECMAScript 4 for the final standard?)

Thomas Reilly treilly at adobe.com
Mon Mar 24 23:21:13 PDT 2008


Pardon the top post, Brandon already seemed to dig into this
proposal with his typical surgical deftness.  I just couldn't
resist relating some Flash history.  As the saying goes, been
there, done that.  Here's the abridged version of ActionScript's
history:

AS1 ~= ES3
AS2 == ES3 + classes as pure compiler sugar
AS3 == proto ES4 with classes as first class citizens

Flash is a couple years ahead of the web in terms of dealing with
application complexity.  If you imagine that the web browser just
gave you a Canvas class and JavaScript you'd have a workable
approximation of Flash, we have no HTML declarative backbone, its
the wild west of scripting.  We introduced classes into AS 8
years or so ago in an attempt to deal with the insuitability of
ES to these growing applications.

As soon as we introduced classes users clamored for coherent
large UI libraries to make their lives easier but any attempt to
build a large coherent library brought the VM to its knees.  So
Flash developers got by with smaller less useful purpose built
frameworks.  A lot of the problems stemmed from having classes as
syntatic sugar.  Weird edge cases permeated the system,
inheritance, class initialization order, proper statics, and
getting overriding working well were issues.  But performance and
memory usage were the kickers.

We know this because we tried multiple times to build the big
honking frameworks in AS2 folks wanted and they ran like poo
eating memory and CPU voraciously.  So we got wise and built
classes into the language as first class citizens with well
defined semantics and a compiler/file format that piped all that
juicy RTTI to the runtime which sported an optimizing JIT.  Then
we built an even bigger honking framework and now it all sings:

http://livedocs.adobe.com/flex/2/langref/

Or look at the Android docs, probably similiar in scope/scale.
The bits about piping juicy RTTI to the vm probably apply too.

My point is that we needed classes to build these rigid, well
defined frameworks that all applications and 3rd party libraries
could build on instead of everyone starting with Canvas and all
that static information sure doesn't hurt when it comes to
performance (can I say that much Brendan? ;-)

The reality is that there's a world of developers out there
waiting to build sophisticated web applications but they are
limited by the adhoc frameworks at their disposal.  The script
kiddies would go nuts if they could build full fledged
applications in web pages with just a veneer of scripting code on
top of a proper UI framework.  A least the Flash script kiddies
have.  Built it and they will come.

I'm not saying AS3 is the be all end all, maybe we drank the Java
cool aid a little too much and its great to see ES4 taking its
time to get it right (righter?) by being more dynamic/pythonic.
The geek in me would love to see classes that could be sliced and
diced and julienned (reflected/generated/extended) at runtime
like the classes as sugar way would avail but that's not always a
good thing.  A damn good Singularity [1] paper I read recently
made some assertions that dynamic loading makes tricky/impossible
proving some type system stability/correctness theorems and I can
buy that.  A better point is what the geeks want isn't what's
necessary good for the rest of the world.  Sometimes loosey
goosey is good, in large frameworks (and certainly OSes) not so
much.  We think that one language can serve both ends.

Flex 3 was just released and we say without a doubt that the
programming in the large structures in AS3 have done amazing
things in scaling the complexity of applications our developers
have built.  We're building full fledged word
processors (buzzword), image editting applications (photoshop
express) and even working on viable video editting [2].  The tiny
hyper dynamic ninja ES3 ain't gonna fit the bill, somethings
gotta give, the web wants heavy artillery (or all the heavy
lifting will be left to Silverlight and Flash, oh and I suppose I
should say Java, its probably still ahead of Silverlight in some
respects).  With AS3 we're seeing people build applications with
complexity rivaling or surpassing that of the player itself.
That never could have happened with AS2 and it won't happen in
the browser with ES3.

To come at it from another angle we envision ES4 as playing a
similar role at Adobe as python has at Google.  Ie something like
only write the super critical bits in C/C++ and glue it all
together with a higher level dynamic scripting language.  Only
we're probably drinking the cool aid too much again and see very
little need for C/C++ (or at least new C/C++).   

Anyways sorry for the rambling but we have some new arrivals and
I haven't ranted in awhile.  Hopefully this background on how the
Adobe folks got here helps somehow.  EcmaScript is about more
than just the web.

[1] http://www.research.microsoft.com/os/singularity/publications/OSR2007_RethinkingSoftwareStack.pdf
[2] http://www.riapedia.com/2007/09/07/adobe_photoshop_express_photoshop_with_flex



-----Original Message-----
From: es4-discuss-bounces at mozilla.org on behalf of Mark S. Miller
Sent: Mon 3/24/2008 6:45 PM
To: Brendan Eich
Cc: es4-discuss at mozilla.org; Dave Herman
Subject: Classes as Sugar (was: Renaming ECMAScript 4 for the final standard?)
 
On Sun, Mar 23, 2008 at 11:28 PM, Brendan Eich <brendan at mozilla.org> wrote:
>  ES4 is not statically typed, so...
>  ... this is a false dilemma.
>
>  These analogies are weak and tendentious in my opinion. Let's try to
>  get back to premises and argue forward. Can we start with why you
>  seem to believe that ES4 is statically typed?

The language design I accused of being statically typed is the
language design currently called "proposed ES4". Of course, one of the
things at stake is whether ES4 will be statically typed. As I've made
clear, I hope not.

Now on to your real question. Why do I seem to believe that proposed
ES4 is statically typed? A fair question. Proposed ES4 lies somewhere
between the simple categories of "statically typed" and "dynamically
typed". However, rather than finding a happy compromise between the
two, it mostly combines the worst of these two worlds. It pays most of
the costs of static typing but obtains few of the benefits. And it
inherits all the costs of having been dynamically typed, but retains
few of the benefits.

Benefits of Static Typing

* static assurance that type mismatch errors will not happen at runtime
* runtime space savings
* runtime time savings
* type-based IDE refactoring support (as in IDEA and Eclipse)

Costs of Static Typing

* language complexity
* limit expressiveness to statically checkable type "predicates".
:int, but no :prime
* two "expression" languages - static type expressions vs dynamic
value expressions
* multiple partial type theories: nominal, structural, duck, ...
* verbosity (inside Google, we've expanded to a 100 column limit for
Java generics)
* inappropriate for casual scripting audience

Benefits of Dynamic Typing

* lambda abstraction / objects is all you need
* Tennent correspondence
<http://gafter.blogspot.com/2006/08/tennents-correspondence-principle-and.html>
* all abstractions first-class, composable
* simple meta-interpreters can enable powerful meta-programming
* syntactic simplicity supports other metatools: minifiers, lints, ...
* rapid prototyping

Costs of Dynamic Typing

* runtime space and time costs
* less static knowledge of dynamic behavior

Benefits of Soft / Gradual Typing

Proposed ES4 and some dynamic languages share some of the advantages
of soft typing systems. A soft typing system is, essentially, a
dynamic typing system with a convenient syntax for declaring type
checks that should be checked at runtime.

* Better documentation of expected interfaces - better project coordination
* Fail-fast runtime behavior
* easy transition from rapid prototypes to production

Benefit of Soft Types absent from Proposed ES4 gradual types:
* type "predicates" are any runtime test expressible in the language


A comprehensive treatment of all these points would need a book. Here,
I will illustrate with a small example as my belated response to Dave
Herman.

I wrote:
>  > If instead classes, for example, were defined purely by syntactic
>  > expansion to the constructs in ES3.1, then classes would inherit the
>  > lexical nestability of the constructs they expand into.

On Tue, Mar 11, 2008 at 5:49 AM, Dave Herman <dherman at ccs.neu.edu> wrote:
>  Nestability is a good design goal, and I'm glad you brought it up.
>  [...]
>  That said, you've hinted at alternative approaches, perhaps with
>  constructs desugaring to closures of some sort

To get discussion going, I will here present a first cut at a
desugaring of something like proposed ES4's class syntax and type
declarations into ES3.1 constructs. Were ES4 to be redefined in terms
of such syntactic sugar, then the desugared semantics could be
precisely ES3.1's would thereby preserve most of ES3.1's virtues. The
example below demonstrates the value of preserving ES3.1's lexical
nestability and first-classness. Browsers would only need to initially
implement ES3.1, and the expansion of ES4 to ES3.1 could happen
initially offline or on the server.


                                                         Classes as Sugar

Given something like the __createProperty__ operation we've been
discussing lately, and that Lars has made progress on specifying, we
could imagine generalizing it to also constrain properties to be
non-overridable (as in proposed ES4 "final") and protected (addessable
only by way of "this."). We could also imagine an operation
constraining an object to be non-extensible (i.e., "fixture"). For
purposes of this note, I will make up a plausible static API for
these. Were the proposed ES4 class syntax defined in terms of the
obvious expansion to ES3.1 + calls to these functions, the first class
definition in the proposed ES4 overview doc

  class C {
    var val;
    var large = Infinity;
    const x = 3.14;
    function f(n) { return n+val*2; }
  }

would expand to

  function C() {
    Object.__createProperty__(this, 'val', undefined, Readable | Settable);
    Object.__createProperty__(this, 'large', Infinity, Readable | Settable);
    Object.__createProperty__(this, 'x', 3.14, Readable);
    Object.fix(this);
  }
  Object.__createProperty__(C, 'prototype', C.prototype, Readable);
  Object.__createProperty__(C.prototype,
                                                    'f',
                                                    function(n)
{return n+val*2;},
                                                    Readable);
  Object.fix(C.prototype);
  Object.fix(C);

ES3 constructor functions are already used as, in effect, nominal type
identities by ES3 instanceof expressions. By expanding the class
syntax to operations that make C's 'prototype' property read-only, we
give integrity to this use of nominal typing. The proposed ES4 type
declaration syntax could then expand to simple nominal type checks:

    var x :C = ...;

expands to

    var x = Object.cast(C, ...);

where

    Object.cast = function(type, value) {
      if (value instaceof type) { return value; }
      throw new TypeError(...);
    }

One further suggestion to make the class syntax more convenient: Get
rid of separate constructors. Instead, allow parameters after the
class name which are then in scope in the class definition. These
would translate directly into the parameters of the constructor
function that the class expands to.

With the expansion above, we seem to have only implemented a subset of
proposed ES4 providing only nominal types. Sure, it's simpler. But how
is it more expressive? Unlike proposed ES4 classes, the expansion
above is lexically nestable and multiply instantiable. This provides
the flexibility of a runtime trademarking system, where the program
can create as many trademarks as are dynamically needed at runtime.
Translating Ping's example from
<http://www.erights.org/elang/kernel/auditors/> into an ES4 using this
sugar:

function makeBrand() {
    var key = {};
    class Envelope(payload) {
        protected const contents = payload;
        function open(k) {
            if (k === key) { return this.contents; }
        }
    }
    return {
        sealer: function(payload) { return new Envelope(payload); },
        unsealer: function(env :Envelope) { return env.open(key); }
    };
}

The key to the correctness of the above code is that every call to
makeBrand create a distinct nominal Envelope type, so that the
unsealer of a sealer/unsealer pair can use it to check that the
alleged envelope argument is not only an instance of the static
Envelope code, but is an envelope created by a call to the
corresponding sealer.


-- 
 Cheers,
 --MarkM
_______________________________________________
Es4-discuss mailing list
Es4-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss




More information about the Es4-discuss mailing list