> But again, two engines don't cut it, for footprint and memory
> reasons. And two engines are intentionally unnecessary by the design
> of ES4.
>
Not to mention the pains of making the two engines interoperable. In
Flash, the new VM is not compatible with the old, and you have to go
to extreme le
On Oct 31, 2007 12:21 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> > One thing could make this a little smoother would be a constructor
> > for a global object, with it's own set of global values, Object,
> > Array, etc. for the sandboxed code to mutilate. Nice, but I don't
> > think necessary.
>
Cyber terrorism has increasingly been mirroring political events in the.
A series of new services and products to drive the takeup of highspeed.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Yes, good points:
* Packages de-sugar to namespaces, pragmas, and a missing primitive
akin to gensym, to make the unforgeable package-public and package-
internal namespaces. They're almost totally syntactic conveniences.
* Along with reflecting the Program production's semantics, program
un
I made an attempt to size the ES3 and ES4 grammars by assigning an ES
edition number to each production, sorting and counting both concrete and
abstract forms. Below are the numbers I came up with. This are very rough,
but having implemented parsers for ES3, AS3 and ES4, the ~2x increase in
number
http://blogs.msdn.com/cwilso/archive/2007/10/31/what-i-think-about-es4.aspx
-dean
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
If you come at this (like I first did) thinking of Packages as
containers, things can get confusing.
The secret to understanding is to start with namespaces, which are
central and critical to ES4 and backwards compatibility. I won't try to
describe namespaces here and will leave that to others
On Oct 31, 2007, at 9:55 AM, Kris Zyp wrote:
> , and this sandboxed eval, with the getters and setters of ES4,
> developers can create safe sandboxes with host object wrappers with
> fine grained access control to enable cross site scripts to be
> loaded and executed with controlled limited
On Oct 31, 2007, at 3:46 AM, Maciej Stachowiak wrote:
I notice some seemingly duplicate features that will perhaps become
more clear on closer reading of the spec. For instance I see all three
of namespace, package and unit productions in the grammar. With my
limited imagination it's hard to thi
>
>
> String.prototype.evaluate = function (scope) {
> /* eval this in scope and only scope -- no other scope chain
> contents! */
> };
To me this like an extremely useful feature for security. If future browsers
had the combination of some ability to make cross-site requests (JSONRequest
or
On Oct 31, 2007, at 9:38 AM, Brendan Eich wrote:
> string.evaluate(someStringLikeThing, theScoleScopeObject);
Heh, theSoleScopeObject of course.
/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
On Oct 30, 2007, at 4:04 PM, Mark Miller wrote:
> AFAIK, the only subset relationships here with unqualified
> compatibility are JSON < ES3 and JSON < proposed ES4. All the
> others have hazards that programmers need to understand in order to
> make use of the subset relationship. In this se
On Oct 31, 2007, at 4:45 AM, Harri Porten wrote:
> But seriously: from my own work on an ES4 interpreter (based on the
> previous draft back then) I saw the biggest impact on the
> implementation
> to be in the "compilation phase". This went hand in the hand with the
> *advantages* of the type s
On Oct 31, 2007, at 5:42 AM, Lars Hansen wrote:
The intrinsic names are for early binding. Since the prototypes
are mutable nothing is known about their properties. So code that
wishes to early-bind to methods would annotate its variables and
open the intrinsic namespace to give preferenc
Hi All -
I've just put up a post outlining some of the bug fixes that are coming along
in ECMAScript 4 (fixing bugs in ES 3). Comments are greatly appreciated (I'll
adjust the post as they come in, as well).
http://ejohn.org/blog/bug-fixes-in-javascript-2/
--John
__
Graydon Hoare wrote:
> Thanks for the patience, and continuing to push. The RI continues to lag
> the spec in a number of places -- there is a bug tracker to follow these
> -- but it's always great to have more hands playing with it.
Of course. I was very happy with the quick response to my feed
Jonathan Watt wrote:
>> I have to look into licensing, but I believe if we can include the
>> Cygwin DLL with the Windows binary, there should be no dependencies
>> whatsoever and you can just download and run.
>
> Fantastic! Hopefully Windows users will soon be able to provide useful
> feedba
Dave Herman wrote:
>> Thanks Dave, that would be great. Could you let us know how things stand once
>> you know more?
>
> It's looking good. Despite the fact that SML/NJ doesn't appear to have
> upcoming plans to support Windows binaries, MLton (http://mlton.org)
> does and has for a long time.
The intrinsic names are for early binding. Since the prototypes are
mutable nothing is known about their properties. So code that wishes to
early-bind to methods would annotate its variables and open the
intrinsic namespace to give preference to intrinsic methods over
prototype methods. The bene
> (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
>
Incidentally, a fair but of what remains is Time getters/setters and the
group of AnyNumber classes. If no one has done it by then, I'll do a chart
of the largest groupings in the morning.
-- Yehuda
On 10/31/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
>
> On Oct 31, 2007, at 4:28 AM, Yehuda
On Oct 31, 2007, at 4:45 AM, Harri Porten wrote:
> Hi!
>
> On Wed, 31 Oct 2007, Maciej Stachowiak wrote:
>
>> Does anyone else have other ideas for objective metrics of language
>> size?
>
> "Compilation time" - of course not that objective as heavily
> implementation specific but still an indica
On Oct 31, 2007, at 4:28 AM, Yehuda Katz wrote:
-- Forwarded message --
From: Yehuda Katz <[EMAIL PROTECTED]>
Date: Oct 31, 2007 3:58 AM
Subject: Re: Language Size (was Re: [TLUG]: ECMAScript
("Javascript") Version 4 -FALSE ALARM)
To: Lars Hansen <[EMAIL PROTECTED]>
A mass
> Thanks Dave, that would be great. Could you let us know how things stand once
> you know more?
It's looking good. Despite the fact that SML/NJ doesn't appear to have
upcoming plans to support Windows binaries, MLton (http://mlton.org)
does and has for a long time. We have written pretty exclus
Hi!
On Wed, 31 Oct 2007, Maciej Stachowiak wrote:
> Does anyone else have other ideas for objective metrics of language
> size?
"Compilation time" - of course not that objective as heavily
implementation specific but still an indicator for the complexity of the
language :)
But seriously: from
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] 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") Versi
On Oct 30, 2007, at 1:23 PM, Maciej Stachowiak wrote:
> By the way, I think the discussions about language size could benefit
> from some quantitative data. I think the following comparisons would
> be interesting:
>
> 1) Size of the ES4 grammar relative to the ES3 grammar (say, by count
> of pro
> -Original Message-
> From: [EMAIL PROTECTED] On Behalf Of Maciej Stachowiak
> Sent: 30. oktober 2007 21:23
>
> By the way, I think the discussions about language size could
> benefit from some quantitative data. I think the following
> comparisons would be interesting:
...
> 2) Size
Maciej Stachowiak wrote:
>
> On Oct 30, 2007, at 1:01 PM, Chris Pine wrote:
>
>> Maciej Stachowiak wrote:
>>
>>> Can anyone address feasibility of a small full implementation
>>> (source code all the way to execution)?
>>
>> If we didn't think it was feasible, we wouldn't be here. :) While we
29 matches
Mail list logo
