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

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Mark S. Miller-2
On Sun, Mar 23, 2008 at 11:28 PM, Brendan Eich <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

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

Brendan Eich-2
On Mar 24, 2008, at 6:45 PM, Mark S. Miller wrote:

> 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.

That's a charge you have yet to demonstrate.

It's ironic to read your charge that ES4 is statically typed, just  
after reading Matthias Felleisen in Steve Yegge's blog comparing  
"Proposed ES4" to TypeScheme and criticizing ES4 because it does not  
impose a static type system on JS.

> It pays most of
> the costs of static typing but obtains few of the benefits.

How do you know this?

> And it
> inherits all the costs of having been dynamically typed, but retains
> few of the benefits.

How did you use "Proposed ES4"? Did you write programs in it?

> 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)

Or Flex Builder, which emits a rough subset of "Proposed ES4". Or  
once upon a time ASP.NET emitting JScript.NET.

The same retort (we are operating at a crude level of rhetoric here,  
almost fact-free, but I'll play along) applies to your other three  
bullet points above.

> Costs of Static Typing
>
> * language complexity

And over-minimizing a language imposes a complexity tax on  
programmers using it. This happened long ago with JS1 and it was  
compounded by foot-dragging monopolist misconduct since 1999.

To decide whether to evolve JS or shrink it, you need only look at  
two things: 1) problems JS hackers run into every day, which are not  
solved by more idiomatic functional programming hacks that add cycle  
and space bloat to their libraries and applications; 2) competition  
from other languages in runtimes vying to displace the browser.

> * limit expressiveness to statically checkable type "predicates".
> :int, but no :prime

Not for want of trying: see

http://wiki.ecmascript.org/doku.php?id=proposals:contracts

Still possible in ES5 after we finish ES4.

I would like to point out that PLT-style contracts are *research*,  
and we've been criticized without justification for "doing research"  
in ES4. Why are you promoting contracts when the research has not  
been reduced to efficient practice yet, and AFAIK depends on a module  
system to keep the contracts on the outside of modules, not on the  
inside?

> * two "expression" languages - static type expressions vs dynamic
> value expressions

That's a fair point. In order to support an *optional* static  
checker, the ES4 design restricts type expressions.

Why this is a hardship has yet to be demonstrated, since your  
preferred style of language offers zero type checking at runtime (or  
optionally at compile time). If you are arguing the static side of  
the equation, please cite statically typed languages that allow full  
value expressions as types. I know of research languages, but besides  
having undecideable type systems, they are (again) *research*.

> * multiple partial type theories: nominal, structural, duck, ...

The inclusion of a structural type system is a virtue, since untyped  
objects are common on the web even in the face of the nominal DOM and  
browser object types, and since no one can revise all code entangled  
on the web to use nominal types, at once or even ever.

I don't know what you mean by "duck", it's ill-defined and generally  
unsound when used in other languages. Structural types address the  
latent typing disciplines used in current Ajax libraries, JSON  
schema, etc.

> * verbosity

On the contrary:

// Version 1 of a webmail client, in pure ES3

function send(msg) {
   validateMessage(msg);
   msg.id = sendToServer(JSON.encode(msg));
   database[msg.id] = msg;
}

function fetch() {
   handleMessage(-1);                  // -1 means "get new mail"
}

function get(n) {
   if (uint(n) !== n)                  // JS1: n>>>0 === n
     throw new TypeError;
   if (n in database)
     return database[n];
   return handleMessage(n);
}

var database = [];

function handleMessage(n) {
   let msg = JSON.decode(fetchFromServer(n));
   if (typeof msg != "object")
     throw new TypeError;
   if (msg.result == "no data")
     return null;
   validateMessage(msg);
   return database[msg.id] = msg;
}

function validateMessage(msg) {
   function isAddress(a) {
     return typeof a == "object" && a != null &&
            typeof a.at == "object" && msg != null &&
            typeof a.at[0] == "string" && typeof a.at[1] == "string" &&
            typeof a.name == "string";
   }
   if (!(typeof msg == "object" && msg != null &&
       typeof msg.id == "number" && uint(msg.id) === msg.id &&
       typeof msg.to == "object" && msg != null &&
       msg.to instanceof Array && msg.to.every(isAddress) &&
       isAddress(msg.from) && typeof msg.subject == "string" &&
       typeof msg.body == "string"))
     throw new TypeError;
}

// ES4 version of same:

type Addr = { at: [string, string], name: string };
type Msg = {
   to: [Addr], from: Addr, subject: string, body: string, id: uint
};
type MsgNoId = {
   to: [Addr], from: Addr, subject: string, body: string
};

function send(msg: like MsgNoId) {
   msg.id = sendToServer(JSON.encode(msg))
   database[msg.id] = msg wrap Msg
}

function fetch()
   handleMessage(-1);

function get(n: uint) {
   if (n in database)
       return database[n];
   return handleMessage(n);
}

function handleMessage(n) {
   let msg = JSON.decode(fetchFromServer(n))
   if (msg is like { result: string } && msg.result == "no data")
       return null
   return database[msg.id] = msg wrap Msg
}

$ wc /tmp/*way
       30     102     688 /tmp/newway
       47     177    1302 /tmp/oldway
       77     279    1990 total

ES3 code shrinks when rewritten in "Proposed ES4".

> (inside Google, we've expanded to a 100 column limit for
> Java generics)

(What has that to do with anything but Java as used inside Google?  
There's no point in arguing about behind-the-firewall non-evidence.)

> * inappropriate for casual scripting audience

ES3 is a subset of "Proposed ES4" and supports evolution and code  
migration, along with single specification and implementation  
(critical on small-device browsers). Beliefs about "Proposed ES4" and  
what is appropriate for "casual scripting audience" members need  
demonstration, not assertion.

> Benefits of Dynamic Typing
>
> * lambda abstraction / objects is all you need

We know that lambda is all you need. Why bloat things with objects?  
For that matter, why speak English instead of Standard Business  
English, the subset Guy Steele made up for his "Growing a Language"  
OOPSLA '98 talk, or Esperanto?

> * Tennent correspondence
> <http://gafter.blogspot.com/2006/08/tennents-correspondence- 
> principle-and.html>

Java closures are years late and mega-dollars short of the mark,  
compared to first-class functions and closures. Perhaps you agree?

> * all abstractions first-class, composable

That's our goal too, but you'll have to study "Proposed ES4" to show  
us where we've failed, instead of citing irrelevant Java non-evidence.

> * simple meta-interpreters can enable powerful meta-programming

I'm not sure what you mean. Could you give an example? I wrote a meta-
circular ES3 interpreter in a superset of ES3 (SpiderMonkey extended  
to host and boostrap Narcissus), but I don't know what you are  
implying cannot be done by ES4, or can be done better, or  
exclusively, by ES3 here.

> * syntactic simplicity supports other metatools: minifiers, lints, ...

Syntax is also user interface, and again minimizing it too much makes  
programming harder. If this bullet were overriding, we'd be using S-
exprs.

> * rapid prototyping

Done all the time using ES3 and "Proposed ES4" approximations and  
piece-wise implementations, some already shipped (JS1.8 in Firefox 3  
beta), some much closer to ES4 being implemented now.
>
> Costs of Dynamic Typing
>
> * runtime space and time costs

Space costs are indeed an issue.

I am happy to ignore time costs, and stipulate that they can be  
reduced to noise by clever optimization techniques for most cases.

> * less static knowledge of dynamic behavior

A lot less ;-).

> 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.

Have you read anything about 'like' types in "Proposed ES4"'s  
overview document or evolutionary programming tutorial?

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

These bullets all arguably apply to "Proposed ES4".

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

This is a selective argument, since (a) we have structural types and  
'like', which cover common cases (common meaning probably > 80%, but  
to be demonstrated, I admit); (b) we can add contracts in the future  
if the need arises *and the research is "done"*.

>                                                          Classes as  
> Sugar
>
> Given something like the __createProperty__

(__defineProperty__ in the latest spec, FYI.)

> 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(...);
>     }

What is the point of all of this? I can map ES4 to ES3 too, and so  
can others -- some are even building translators. But programmers  
should (a) not have to do this by hand; (b) not have to procure and  
use an offline ES4 to ES3 translator to reap the benefits of ES4,  
except for the transparent debugability (instead, they get leaky-unto-
flooding-abstraction hell).

> 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.

This was considered too, see:

http://wiki.ecmascript.org/doku.php?id=discussion:nullability#example

I like the first part -- constructor parameters in the class head.  
The odd-looking special form "function Foo { ... }" for the  
constructor code loses compared to an intact constructor function,  
though.

> 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.

I favor allowing classes in "Proposed ES4" to be nested in functions,  
for what it's worth. Since we aren't done yet, perhaps this will come  
to pass, although "lexical nestability" is not a burning issue in  
general.

"Multiply instantiable" is indeed relevant on the web with various  
window objects and browser-specific sandbox objects hosting  
instances. We can do better, but so could your example. There's no  
reason to force everyone to write, or translate to, a minimally  
extended ES3 and suffer the performance and debugging consequences.

> The key to the correctness of the above code is that every call to
> makeBrand create a distinct nominal Envelope type,

In ES4 as proposed you can use eval to make distinct nominal types.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

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

treilly (Bugzilla)
In reply to this post by Mark S. Miller-2

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: [hidden email] on behalf of Mark S. Miller
Sent: Mon 3/24/2008 6:45 PM
To: Brendan Eich
Cc: [hidden email]; 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

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

Brendan Eich-2
On Mar 24, 2008, at 11:21 PM, Thomas Reilly wrote:

> ... and all
> that static information sure doesn't hurt when it comes to
> performance (can I say that much Brendan? ;-)

If you've got it, use it -- no point in dropping type information  
during a source to bytecode or other transformation. Just don't  
expect the web to type-annotate the way Flash authors did (with some  
grumbling) based on the carrot of speed that you guys dangled.

> Sometimes loosey
> goosey is good, in large frameworks (and certainly OSes) not so
> much.  We think that one language can serve both ends.

I'm pretty sure Mark wants to avoid loose geese too, but he has  
reached different conclusions. My goal is to work from conclusions  
backward to premises such as "ES4 is statically typed" and try to  
identify the reason for that kind of statement.

This may not succeed. As Graydon once observed, a lot depends on  
"mood" of the language. People see static type checkers (even  
optional ones, as optional as JSLint) and type annotations (also  
optional), and the 'class' keyword (which is used in dynamic  
languages too), and suddenly it's a statically typed language and  
therefore b-a-d.

The charge Matthias leveled about intentional loopholes (ES4's *  
type, which is the default annotation) meaning errors can (as is  
usual in ES3 today) originate from anywhere in a large system and  
mess over your hybrid or partially typed code is pretty much on  
target. But we are trying not to do Contract or TypeScheme research,  
and we are definitely not imposing a static type system (not even  
within new modules -- and defining a module is turning out to be  
quite hard in JS on the web). Contrary to all the claims alleging  
that we are doing those bad things.

If ES4 users want to lock a module down in a static-typing sense,  
they can annotate all API entry points with non-like types (wrap  
would allow untyped client code to pass plain old objects and arrays,  
at a price). Further self-imposed B&D programming inside the module  
is optional in my view. This is the best that I believe we can do for  
ES4. It beats purely dynamic typing for any non-trivially-small  
codebase. I wish I had the option to code in this language when  
writing Narcissus.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

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

treilly (Bugzilla)

> If ES4 users want to lock a module down in a static-typing sense,
> they can annotate all API entry points with non-like types (wrap
> would allow untyped client code to pass plain old objects and arrays,
> at a price). Further self-imposed B&D programming inside the module
> is optional in my view. This is the best that I believe we can do for
> ES4. It beats purely dynamic typing for any non-trivially-small
> codebase. I wish I had the option to code in this language when
> writing Narcissus.

And I think that's good enough.  Flex has a "strict" mode where you get
a warning if you don't statically type things.  Typically I turn it off when
prototying around and turn it back on if I'm implementing anything others have
to use.   I never really stopped to think why this is.  Is it as simple as
facilitating code sharing and declarative input validation or is there more to
it?  I suspect it might be that simple.

One thing that occurs to me is that classes facilitate wrapping up code into
a compiled form and sharing it as a fixed closed entity.  Not sure that will
ever apply to browsers but its a very common idiom in Flex (and Java/C/C++...).
Here static typing is just facilitating creating code boundaries I guess.

Boundaries are definitely a good thing when trying to coordinate the efforts of
many.  But then I see things like this:

http://ptrthomas.wordpress.com/2006/06/06/java-call-stack-from-http-upto-jdbc-as-a-picture/

Its kinda awe-inspiring to look at but part of me wonders if maybe there's a better way
(and wow, the JVM must have an unbounded stack)?   Maybe with ES4 all the boxes are there
with similiarly defined boundaries but the meat inside the boxes is leaner/clever dynamic
code.  How's that for an ES4 pitch, like Java but with leaner meat ;-)   Taste great, less
filling.

-----Original Message-----
From: Brendan Eich [mailto:[hidden email]]
Sent: Tue 3/25/2008 12:19 AM
To: Thomas Reilly
Cc: Mark S. Miller; Dave Herman; [hidden email]
Subject: Re: Classes as Sugar (was: Renaming ECMAScript 4 for the final standard?)
 
On Mar 24, 2008, at 11:21 PM, Thomas Reilly wrote:

> ... and all
> that static information sure doesn't hurt when it comes to
> performance (can I say that much Brendan? ;-)

If you've got it, use it -- no point in dropping type information  
during a source to bytecode or other transformation. Just don't  
expect the web to type-annotate the way Flash authors did (with some  
grumbling) based on the carrot of speed that you guys dangled.

> Sometimes loosey
> goosey is good, in large frameworks (and certainly OSes) not so
> much.  We think that one language can serve both ends.

I'm pretty sure Mark wants to avoid loose geese too, but he has  
reached different conclusions. My goal is to work from conclusions  
backward to premises such as "ES4 is statically typed" and try to  
identify the reason for that kind of statement.

This may not succeed. As Graydon once observed, a lot depends on  
"mood" of the language. People see static type checkers (even  
optional ones, as optional as JSLint) and type annotations (also  
optional), and the 'class' keyword (which is used in dynamic  
languages too), and suddenly it's a statically typed language and  
therefore b-a-d.

The charge Matthias leveled about intentional loopholes (ES4's *  
type, which is the default annotation) meaning errors can (as is  
usual in ES3 today) originate from anywhere in a large system and  
mess over your hybrid or partially typed code is pretty much on  
target. But we are trying not to do Contract or TypeScheme research,  
and we are definitely not imposing a static type system (not even  
within new modules -- and defining a module is turning out to be  
quite hard in JS on the web). Contrary to all the claims alleging  
that we are doing those bad things.

If ES4 users want to lock a module down in a static-typing sense,  
they can annotate all API entry points with non-like types (wrap  
would allow untyped client code to pass plain old objects and arrays,  
at a price). Further self-imposed B&D programming inside the module  
is optional in my view. This is the best that I believe we can do for  
ES4. It beats purely dynamic typing for any non-trivially-small  
codebase. I wish I had the option to code in this language when  
writing Narcissus.

/be


_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

complexity tax

Douglas Crockford
In reply to this post by Brendan Eich-2
Brendan Eich wrote:

> And over-minimizing a language imposes a complexity tax on programmers
> using it. This happened long ago with JS1 and it was compounded by
> foot-dragging monopolist misconduct since 1999.
>
> To decide whether to evolve JS or shrink it, you need only look at two
> things: 1) problems JS hackers run into every day, which are not solved
> by more idiomatic functional programming hacks that add cycle and space
> bloat to their libraries and applications; 2) competition from other
> languages in runtimes vying to displace the browser.

I think this is the specific point of disagreement. Complexity in a language
does not necessarily reduce the complexity of programs. I think the opposite may
be truer. The difficulties we have had in the development community since 1999
were not due to over-minimization. They were due to features that did not work
as expected or reliably over the various brands and versions. I think that with
minimal changes we can significantly improve this language. Most of the changes
I would make would make it simpler, not more complex. And of course, our
overwhelmingly most important problem, insecurity, is not addressed by this
proposal. The proposal is trying to solve a problem from a 2000 viewpoint. We
have moved on since then. We have new problems now, and the proposal does not
match them.

I believe that it will be easier to improve the performance of the language by
simplifying it. That performance improvement will be critical as we move toward
mobile.

I can't make sense of your point about competition. The web's competitors all
provide access to multiple languages, including JavaScript. In the unlikely case
that the proposed language is successful, I would expect them to support it too.
It would seem that the web would be more competitive if it also offered multiple
languages. I don't believe that a single, all-inclusive monster language will be
competitive.


_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: complexity tax

Ric Johnson
On 3/26/2008, "Douglas Crockford" <[hidden email]> wrote:

>
>I think this is the specific point of disagreement. Complexity in a language
>does not necessarily reduce the complexity of programs. I think the opposite may
>be truer. The difficulties we have had in the development community since


I think this is THE point of prose rather than technique in that I can
argue either side.
An example is Microsoft’s LINQ - it is already implemented in .Net 3.5.
I can do the same effects using delegates to static IEnumerable in older
versions of .Net but it would take me several (dozen) more lines of
code.  When compiled, the result may be the same, but my implementation
may not be standard.  (Doing it my own way may allow me to discover
something better, but that is another discussion)

I respect both sides:  I trust Brendan as the language designer, but I
can not get over Doug’s fear of ‘The Ghost of Netscape’.

Let us take action instead of throwing opinions around:
Brendan: What new features that can not be implemented via code
constructs now?
Doug: Please give concrete example of YUI code that accomplishes
something proposed

Then we, as computer SCIENTISTS can calculate the complexity ratio of
code vs. language implementation.  We could keep on arguing about speed
and best specific algorithms after that if you want.

Ric
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: complexity tax

ToolmakerSteve
In reply to this post by Douglas Crockford
"Douglas Crockford" wrote:

> Brendan Eich wrote:
>> 2) competition from other
>> languages in runtimes vying to displace the browser.
>
> I can't make sense of your point about competition.

>From my perspective, this is about:
. Flash; Silverlight; Java (client side).

Three major approaches requiring large plug-ins to provide a rich
environment. Notably all three approaches have languages substantially
beyond Javascript. As a toolmaker, I would love to see convergence between
Javascript and Flash and a Silverlight language that was powerful enough to
also use server side a la Java.

Does such a language need to be as extensive as ES4? Probably not.

Is this more urgent than the topics Douglas mentions? That seems worthy of
more discussion.

Best Regards, ~TMSteve

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: complexity tax

Brendan Eich-2
In reply to this post by Ric Johnson
On Mar 26, 2008, at 10:01 AM, Ric Johnson wrote:

> Let us take action instead of throwing opinions around:
> Brendan: What new features that can not be implemented via code
> constructs now?

This is reductionism, therefore between silly and wrong, but I will  
list a few things:

* you can't make read-only properties in ES3;

*you can't make don't-delete properties of plain old objects (only  
vars in closures);

* you can't make objects that cannot be extended;

* you can't make don't-enum properties in plain old objects;

* you can't yield from a function to its caller, saving state  
automatically in local variables, and send a value back to the  
suspended activation of that function.

The last is generators, but let's suppose that we add those. I'm  
intentionally leaving out things that are hard to do, but can be  
done, with closures (e.g., guaranteeing that |this| binds to a  
particular object when a method is called; or guaranteeing that a  
particular method *will be* called by a given name on an object).

Suppose further that you chose the absolute minimal set of additions  
to support some semblance of a solution for the first four bullets.

My response is that adding a few meta-methods to flip property  
attributes is not thereby "enough", since it is still incredibly  
verbose, error-prone, inefficient, and subject to "in the middle of  
construction" integrity attacks to build up "classes" or other ES4  
features using objects with const/permanent/non-enumerable additions.  
Almost no one will write such "classes" out by hand.

I noted years ago to Doug (after a talk at Yahoo! I gave) how a macro  
system would help programmers use some primitives better without  
adding more surface syntax. He wondered whether we shouldn't do  
macros first. Problem is macros are not theoretically worked out yet  
-- and that's in the context of Scheme. So rather than starve the  
patient further, I argue we should be willing to add syntactic  
conveniences as well as syntax for new substance. Macros may come,  
and much can be recast in terms of them, and the ecosystem can take  
over the business of syntactic extension, to a great extent.

Anyway, I don't think my answer here helps decide what to do.  
Opinions and tastes vary about things like syntax, dynamic meta-
programming using fewer primitives vs. declarative new forms that can  
be (optionally) statically checked, etc. Some people will always  
prefer to use fewer primitives. It seems better to me to grow  
JavaScript based on existing "design patterns" used (at some cost) on  
top of ES3, and based on solutions from "nearby" languages such as  
Python and ActionScript 3 (to take just two examples).

Even this does not mean anything particular about complexity budgets.  
I will say this: ES4 has overspent its complexity budget in order to  
explore a large design space. It is now shrinking to meet practical  
budgets involving Ecma member consensus, prime mover commitments,  
fatigue effects, community expectations, and the like. No one working  
on ES4 wants it to be like Perl 6. We aim to finish this year. So  
you'll see proposals like multimethods getting deferred.

/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: complexity tax

Garrett Smith
In reply to this post by Douglas Crockford
On Wed, Mar 26, 2008 at 8:23 AM, Douglas Crockford
<[hidden email]> wrote:
> Brendan Eich wrote:
>
>  > And over-minimizing a language imposes a complexity tax on programmers
>  > using it.

That is true.

>  > To decide whether to evolve JS or shrink it, you need only look at two
>  > things: 1) problems JS hackers run into every day, which are not solved
>  > by more idiomatic functional programming hacks that add cycle and space
>  > bloat to their libraries and applications; 2) competition from other
>  > languages in runtimes vying to displace the browser.
>
>  I think this is the specific point of disagreement. Complexity in a language
>  does not necessarily reduce the complexity of programs.

Not necessarily, but to be specific, simply adding 'private' access
modifier would avoid a closure. This is good because its a lot more
convenient and a lot clearer.

I think the opposite may
>  be truer. The difficulties we have had in the development community since 1999
>  were not due to over-minimization. They were due to features that did not work
>  as expected or reliably over the various brands and versions.

That is true. Implementation differences are significant difficulties.
Other difficulties had to do with browser differences/competing
technology platforms (<layer>, document.all).

There are also limitations to the language itself that cause problems
(no access modifiers, limited typechecking, enumeration). I disagree
that limitations in the language did not cause difficulties. I think
the opposite is true. I think that developers ran into problems when
trying to add to Object.prototype. I think developers have struggled
trying to figure out if [some_object] was a function or array. I think
that developers exploited closures for all that closures had to offer.
Closures are the most useful thing we have because there simply aren't
other alternatives available.

Garrett

>
>
>  _______________________________________________
>  Es4-discuss mailing list
>  [hidden email]
>  https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: complexity tax

Ric Johnson
In reply to this post by Brendan Eich-2
Brendan,

I admit to being a lurker and a bit of a troll, except the discussions I
inspire are actually help me understand.  Inso much that the community
also learned, mayhaps I am an 'ethical' troll.

On 3/26/2008, "Brendan Eich" <[hidden email]> wrote:
>This is reductionism, therefore between silly and wrong,

Can you explain the above fragment?

>* you can't make read-only properties in ES3;

I think I can! Maybe a bad developer could re-define parts of my objects,
but is the intention sugar or hacker proof?

>*you can't make don't-delete properties of plain old objects (only
>vars in closures);

Again, I can make it pretty darn hard to remove privledged fields without
killing the tree, and I ususally use plain old objects (poo) as data
only.

>* you can't make objects that cannot be extended;

This may be true.  But I think the crazy guy that invented livescript did
this to allow the power of prototype and redefine the Object/ Function
constructors actually had a good idea: JS is not a CLASSical language.

>* you can't yield from a function to its caller, saving state
>automatically in local variables, and send a value back to the
>suspended activation of that function.

I actually have a hack that used recursion, a global hash, timers, and
closures that effectively did YIELD (and it worked most of the time too!)

> It is now shrinking to meet practical
>budgets involving Ecma member consensus, prime mover commitments,
This is good news that we are coming to consensus, even if it is only for
timelines (for now).

Thank you for your considered response!
- Ric

P.S. I would also love to hear from Doug on this, if you are out there!
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: complexity tax

Brendan Eich-2
On Mar 26, 2008, at 4:47 PM, Ric Johnson wrote:

> On 3/26/2008, "Brendan Eich" <[hidden email]> wrote:
>> This is reductionism, therefore between silly and wrong,
>
> Can you explain the above fragment?

The whole of a language is more than the sum of its parts. The lambda  
calculus is enough for computation but no one wants to use only it.  
Danny Hillis built a computer from tinkertoys once...

>
>> * you can't make read-only properties in ES3;
>
> I think I can!

How?

> but is the intention sugar or hacker proof?

Hacker.

>> *you can't make don't-delete properties of plain old objects (only
>> vars in closures);
>
> Again, I can make it pretty darn hard to remove privledged fields  
> without
> killing the tree,

How?

>> * you can't make objects that cannot be extended;
>
> This may be true.  But I think the crazy guy that invented  
> livescript did
> this to allow the power of prototype and redefine the Object/ Function
> constructors actually had a good idea: JS is not a CLASSical language.

That does not solve problems where integrity matters more than it  
does for the obvious use-cases I had in mind in favoring mutability.

>> * you can't yield from a function to its caller, saving state
>> automatically in local variables, and send a value back to the
>> suspended activation of that function.
>
> I actually have a hack that used recursion, a global hash, timers, and
> closures that effectively did YIELD (and it worked most of the time  
> too!)

I don't think you read what I wrote: save local variables, resume the  
same function activation. Sure, you can implement state machines with  
other techniques, which are ugly and hard to use by comparison :-P.

/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: complexity tax

David Teller-3
In reply to this post by Douglas Crockford

On Wed, 2008-03-26 at 08:23 -0700, Douglas Crockford wrote:
> The difficulties we have had in the development community since 1999
> were not due to over-minimization. They were due to features that did not work
> as expected or reliably over the various brands and versions.

In my experience, the main problem with JS was the impossibility of
extending it. That is, no notion of libraries and no built-in
pre-processor (although reflexivity could be used for similar purposes).
A consequence was that any extension deemed important by the developers
of a browser had to be bolted-on in non-specified manners.

Now, all the features I see en ES4 are nice (my favorite being the
hybrid type system, although type inference is going to be a heck to
design and implement) and I can see myself using most of them, but I
would have been content with just the addition of libraries and
pre-processor.

Cheers,
 David
--
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act
brings liquidations.

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: complexity tax

Mike Shaver
On Thu, Mar 27, 2008 at 7:06 AM, David Teller
<[hidden email]> wrote:
>  In my experience, the main problem with JS was the impossibility of
>  extending it. That is, no notion of libraries and no built-in
>  pre-processor (although reflexivity could be used for similar purposes).
>  A consequence was that any extension deemed important by the developers
>  of a browser had to be bolted-on in non-specified manners.

I don't quite understand this -- could you give an example of a
language that has better support for libraries as part of its language
specification?  I don't think the C specification includes linking (or
even the ABI, though C++ grew an ABI specification later), so it seems
to be about at the same point of "get your code into scope somehow".
Browsers use <script> for that, and many an AJAX toolkit has added new
capabilities to the environment through just that means.

Mike
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: complexity tax

Neil Mix
In reply to this post by Douglas Crockford
> I think this is the specific point of disagreement. Complexity in a  
> language
> does not necessarily reduce the complexity of programs. I think the  
> opposite may
> be truer. The difficulties we have had in the development community  
> since 1999
> were not due to over-minimization. They were due to features that  
> did not work
> as expected or reliably over the various brands and versions. I  
> think that with
> minimal changes we can significantly improve this language. Most of  
> the changes
> I would make would make it simpler, not more complex. And of course,  
> our
> overwhelmingly most important problem, insecurity, is not addressed  
> by this
> proposal. The proposal is trying to solve a problem from a 2000  
> viewpoint. We
> have moved on since then. We have new problems now, and the proposal  
> does not
> match them.

The community of JS developers is wide and deep, and the applications  
of JS differ dramatically in scope.  I, for one, am a member of "we"  
who couldn't disagree with you more.  So who exactly is "we"?  What  
evidence do you have that simplification would meet the needs of the  
vast majority of "us"?

I say this not to be argumentative, but to point out that the  
"development community" can't be generalized so easily as you  
suggest.  You represent an important voice in the community to be  
sure, but it's by far not the only one.

> I believe that it will be easier to improve the performance of the  
> language by
> simplifying it. That performance improvement will be critical as we  
> move toward
> mobile.

Do you have evidence to support this claim?  Which simplifications can  
you point to where objective evidence demonstrates that performance  
will improve?

It's all well and good to invoke the "simple is better" mantra (no  
disagreement here), but it needs to be backed up with evidence, detail  
and definition.
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: complexity tax

David Teller-3
In reply to this post by Mike Shaver
Well, most languages have better support for libraries than C or C++.
But there are things that even C has and JS<2 doesn't:
* #include
* a linker
* a somewhat standard manner of distributing these libraries (.a or .so)
* arguably, a [not necessarily hacker-proof] mechanism for sharing
symbols between several components without exposing them to the client.

Note that I'm not attempting to advocate the merits of #include, which I
find rather ugly. I also have no idea whether the linker is part of the
spec or not -- but then, I wasn't discussing specs, more developer
experience, and linkers have been part of the standard package for as
long as I've been programming.

Now, with JS<2, to get something linke #include + linking (or Java's
import), you need to use somewhat more convoluted methods. In addition,
all the techniques I have seen require some hard-wiring inside the
document, which may be good for small webpages, but looks like a rather
bad practice when you're talking about whole applications: essentially,
this is equivalent to putting all your #includes inside the UI code.
Finally, while the methods may work in a webpage, not all of them apply
well to non-web JS -- I'm thinking about off-line extensions, XPCOM or
server-side JS.

This strikes me as a good reason to improve library management in JS.
Which was the case last time I looked at ES4, although I may have missed
a few developments on that front.

Cheers,
 David

On Thu, 2008-03-27 at 10:30 -0400, Mike Shaver wrote:

> I don't quite understand this -- could you give an example of a
> language that has better support for libraries as part of its language
> specification?  I don't think the C specification includes linking (or
> even the ABI, though C++ grew an ABI specification later), so it seems
> to be about at the same point of "get your code into scope somehow".
> Browsers use <script> for that, and many an AJAX toolkit has added new
> capabilities to the environment through just that means.
>
> Mike
>
--
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations.

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: complexity tax

Douglas Crockford
In reply to this post by Brendan Eich-2
Brendan Eich wrote:

> On Mar 26, 2008, at 10:01 AM, Ric Johnson wrote:
>
>> Let us take action instead of throwing opinions around:
>> Brendan: What new features that can not be implemented via code
>> constructs now?
>
> This is reductionism, therefore between silly and wrong, but I will list
> a few things:
>
> * you can't make read-only properties in ES3;
>
> *you can't make don't-delete properties of plain old objects (only vars
> in closures);
>
> * you can't make objects that cannot be extended;
>
> * you can't make don't-enum properties in plain old objects;

It looks like these omissions will be corrected in ES3.1 by the
Object.defineProperties function. These essential features will be added without
resorting to new syntax.
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: complexity tax

Brendan Eich-2

On May 19, 2008, at 4:32 PM, Douglas Crockford wrote:

> Brendan Eich wrote:
>> On Mar 26, 2008, at 10:01 AM, Ric Johnson wrote:
>>
>>> Let us take action instead of throwing opinions around:
>>> Brendan: What new features that can not be implemented via code
>>> constructs now?
>>
>> This is reductionism, therefore between silly and wrong, but I  
>> will list
>> a few things:
>>
>> * you can't make read-only properties in ES3;
>>
>> *you can't make don't-delete properties of plain old objects (only  
>> vars
>> in closures);
>>
>> * you can't make objects that cannot be extended;
>>
>> * you can't make don't-enum properties in plain old objects;
>
> It looks like these omissions will be corrected in ES3.1 by the
> Object.defineProperties function.

Of course, Ric asked "What new features [...] can not be implemented  
via code constructs now?" Code constructs added in 3.1, with or  
without new syntax, don't count.


> These essential features will be added without
> resorting to new syntax.

New syntax is what's needed to make these usable. Who wants to use  
Object.defineProperties on a closure to bind a read-only property  
when you could use 'const'?

The problem with Object.defineProperties, apart from standardizing it  
in two committees, is the verbosity and (at the limit) overhead.  
There's really no reason not to have better UI for the underlying  
semantics.

/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: complexity tax

Mark S. Miller
On Mon, May 19, 2008 at 4:46 PM, Brendan Eich <[hidden email]> wrote:

>> These essential features will be added without
>> resorting to new syntax.
>
> New syntax is what's needed to make these usable. Who wants to use
> Object.defineProperties on a closure to bind a read-only property
> when you could use 'const'?
>
> The problem with Object.defineProperties, apart from standardizing it
> in two committees, is the verbosity and (at the limit) overhead.
> There's really no reason not to have better UI for the underlying
> semantics.


I agree that it would be nice to have better syntactic conveniences
for some of these features. I also agree that the ES4 syntax has some
decent conveniences. Given the inescapable legacy compatibility
constraints, it's amazing how well they turned out; kudos! If I could
have a language with some of the syntactic conveniences of ES4 but
without ES4's semantics, I'd be quite happy. My "Classes as Sugar"
proposal <https://mail.mozilla.org/pipermail/es4-discuss/2008-March/002496.html>
suggests how some of ES4's syntactic conveniences  could be applied to
a language with only ES3.1's semantics.

However, so long as ES4 ties these syntactic conveniences to ES4's
semantics, ES3.1's successors cannot grow in the direction of the
"Classes as Sugar" proposal without violating the subset agreement.
Given our current situation, I think maintaining the subset agreement
is more important. For some, ES3.1 is too little. For others, ES4 is
too much. From prior discussions, I don't believe it's possible to
find something in the middle that we can all agree on -- though I
would still like to!

--
Text by me above is hereby placed in the public domain

 Cheers,
 --MarkM
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: complexity tax

Brendan Eich-2
On May 19, 2008, at 6:54 PM, Mark Miller wrote:

If I could
have a language with some of the syntactic conveniences of ES4 but
without ES4's semantics, I'd be quite happy.

What semantics in particular, can you pick on something specific that's not in your classes as sugar proposal (rather than have me guess)? BTW, since you missed the cuts in the spreadsheet, you may have missed the optional type checker being cut too: 'use strict' is good-taste mode, a la Perl and in accord with discussions we've had at the last two TC39 meetings.

Thanks for the kind words, although since neither 3.1 nor 4 is done yet, specific constructive criticism is even better.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
12