Re: Reference implementation currently too hard to install in Windows

Dave Herman wrote: > Thanks for the feedback; I agree the Windows build is too hard to > install. Last I checked it wasn't possible to build Windows binaries > with SML/NJ. I will talk to my contacts who work on SML/NJ and see if > there's something we can do to make this more seamless. Thanks

What have we done about the mutable global object? (was Re: Es4-discuss Digest, Vol 8, Issue 44)

On Oct 30, 2007, at 6:14 PM, Brendan Eich wrote: > ES4 provides const, fixed typename bindings, lexical scope (let), > program units, and optional static type checking -- all of which > *do* make ES4 code easier to analyze and instrument to enforce > security properties. I left out the intr

Re: Es4-discuss Digest, Vol 8, Issue 44

On Oct 30, 2007, at 6:45 PM, Ric Johnson wrote: > Doug is correct: as a product manager, it is bad to add more > features: it > increases our risks with reduced ROI I sympathize with the concern behind this statement, but I would argue its analysis is incomplete on the following grounds: 1)

Re: Es4-discuss Digest, Vol 8, Issue 44

On Oct 30, 2007, at 7:02 PM, Ric Johnson wrote: > On 10/31/2007, "Brendan Eich" <[EMAIL PROTECTED]> wrote: > >> Sure, but you have now argued in a circle. If the script tag handler, >> upon seeing

Re: Es4-discuss Digest, Vol 8, Issue 44

On 10/31/2007, "Brendan Eich" <[EMAIL PROTECTED]> wrote: > >Sure, but you have now argued in a circle. If the script tag handler, >upon seeing

Re: Es4-discuss Digest, Vol 8, Issue 44

On Oct 30, 2007, at 5:36 PM, Ric Johnson wrote: > On 10/31/2007, "Brendan Eich" <[EMAIL PROTECTED]> wrote: > >> http://wiki.ecmascript.org/doku.php?id=proposals:versioning > > Brendan, > > I know that a version string may help us avoid incompatibilities, > however > I am also cognizant that this

Re: Es4-discuss Digest, Vol 8, Issue 44

On Oct 30, 2007, at 5:03 PM, Douglas Crockford wrote: Brenden is also correct: If the working group voted and the current proposal won - it is better to have a stronger, more secure language. Sure they can argue it is bloated, but SO WHAT? The proposal is not a more secure language. It does n

Re: Es4-discuss Digest, Vol 8, Issue 44

On 31/10/2007, Ric Johnson <[EMAIL PROTECTED]> wrote: > I still am missing something. If someone could somehow prove that ES4 is > flawed, do we have actually have a chance to fix it before it is burned > over my childhood memories? How do we do that? Do I need to draw up a > diagram comparing s

Re: Es4-discuss Digest, Vol 8, Issue 44

Douglas Crockford wrote: > The proposal is not a more secure language. It does nothing to address > ECMAScript's biggest design flaw: the insecurity caused its dependence on a > global object. XSS attacks are a direct consequence of this flaw. By making > the language more complex, this proble

Re: Es4-discuss Digest, Vol 8, Issue 44

On 10/31/2007, "Brendan Eich" <[EMAIL PROTECTED]> wrote: >On Oct 30, 2007, at 3:59 PM, Yehuda Katz wrote: > >> I would specifically like to hear a realistic technical scenario >> where the implementation of ES4 produces serious complications in >> the open web. > >Me too. Here's one analysis of ho

Re: Es4-discuss Digest, Vol 8, Issue 44

Douglas, Thank you! I asked for a clear message, and you gave me one! Don't we need the global object to be compatible? Can you point to a suggestion of what use mere mortals may do to influence the proposals? (Other than this on this list) We may all agree that 'bloat' is bad. We might not al

Re: Es4-discuss Digest, Vol 8, Issue 44

Doug, Yes, I think the time has come to table the ES3+ materials. It has been discussed on and off since April. Do you have something that describes this proposal in a material way? How can people evaluate ES4 vs ES3+ if ES3+ is unknown and unspecified? Michael Yehuda Katz wrote: Doug,

Re: Es4-discuss Digest, Vol 8, Issue 44

Doug, What specifically would you do in ES3+ to improve this situation? -- Yehuda On 10/30/07, Douglas Crockford <[EMAIL PROTECTED]> wrote: > > > Brenden is also correct: If the working group voted and > > the current > > proposal won - it is better to have a stronger, more secure > > language.

Re: Es4-discuss Digest, Vol 8, Issue 44

On Oct 30, 2007, at 3:59 PM, Yehuda Katz wrote: > I would specifically like to hear a realistic technical scenario > where the implementation of ES4 produces serious complications in > the open web. Me too. Here's one analysis of how ES4 might break existing scripts: * New keywords and synta

Re: Es4-discuss Digest, Vol 8, Issue 44

> Brenden is also correct: If the working group voted and > the current > proposal won - it is better to have a stronger, more secure > language. > Sure they can argue it is bloated, but SO WHAT? The proposal is not a more secure language. It does nothing to address ECMAScript's biggest design

Re: Es4-discuss Digest, Vol 8, Issue 44

>* Ric Johnson: "However, Doug did strike a chord when he said 'the >ghost of Netscape'". > >Was Ric quoting you accurately, and if so, what did you mean? I stand by this one. > >* Ric Johnson again: "There are A LOT of accusations of backroom >deals being made" However, it was NOT Doug that cla

Re: Es4-discuss Digest, Vol 8, Issue 44

Thank you all for keeping this thread alive, despite all the flamz, I still am missing something. If someone could somehow prove that ES4 is flawed, do we have actually have a chance to fix it before it is burned over my childhood memories? How do we do that? Do I need to draw up a diagram comp

Re: Es4-discuss Digest, Vol 8, Issue 44

On Oct 30, 2007, at 3:09 PM, Douglas Crockford wrote: Doug Crockford made some statements about TG1 members and motives. The speculations about motives were made by others on this list, not by me. Yeah, you have said little on this list, but somewhat more at that panel at TAE Boston. I w

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

On Oct 30, 2007 2:38 PM, Brendan Eich <[EMAIL PROTECTED]> wrote: > > Experiments such as Google > Cajaare > interesting ( > discussionhere

Re: Es4-discuss Digest, Vol 8, Issue 44

There's a difference between meeting minutes of the WG and the discussions that need to occur now in the development community. If ES4 is to succeed, a chunk of the development community needs to get behind it (and at least not be actively opposed to it). The insider baseball that's been occurring

Re: Es4-discuss Digest, Vol 8, Issue 44

On 10/30/07, Douglas Crockford <[EMAIL PROTECTED]> wrote: > > It has serious consequences that should be discussed. Well, it looks like there are two years of meeting minutes on the wiki. Do the details of these consequences appear anywhere in the minutes? If not, now is the time to get very speci

RE: Language Size (was: RE: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM)

I'm sure! I wasn't being completely serious. We've learned that when you design something for the desktop its really hard to retrofit it for smaller devices, much better to start out small and tweak it to take advantage of the desktop's resource largesse. We also find that it almost never happe

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

Brendan, Thank you for the thorough and even somewhat inspiring response, that certainly helps me (and hopefully others) to understand the situation better. I may a have few other questions later, but for now, Thank you! Kris On 10/30/07, Brendan Eich <[EMAIL PROTECTED]> wrote: > > [Kris asks le

Re: Es4-discuss Digest, Vol 8, Issue 44

Doug, I appreciated your comments at the end of the debate about people reading the white-paper. It was very courteous. That said, you did imply that the WG was split, by mentioning two members in support and two opposed. Your comments to me after the presentation about back-compatibility were int

Re: Es4-discuss Digest, Vol 8, Issue 44

> Doug Crockford made some statements about TG1 members and motives. The speculations about motives were made by others on this list, not by me. In answer to a question from Brent Ashley, I said that the working group was not in consensus, a fact which would have been apparent to any keen obse

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Kris asks legitimate questions, to be answered by more than a Microsoft spokesperson. I'm going to reply cc'ing the list, even though there are political points here along with technical content. The list is for discussion of ES4, and that category looks like it must include some political

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

Fixed url of grammar. On 10/30/07 1:46 PM, Jeff Dyer wrote: > > > > On 10/30/07 1:23 PM, 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 cod

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

On Oct 30, 2007, at 1:45 PM, Thomas Reilly wrote: > > http://www.engadget.com/2007/07/01/iphone-processor-found-620mhz-arm/ > > I've heard its got 128MB with 11mb of memory reserved for the display, > add 620 mghz processor, 8 GB disk, fp and integer SIMD units. Does > this > still qualify as

RE: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

http://www.engadget.com/2007/07/01/iphone-processor-found-620mhz-arm/ I've heard its got 128MB with 11mb of memory reserved for the display, add 620 mghz processor, 8 GB disk, fp and integer SIMD units. Does this still qualify as an embedded device? It probably sports virtual memory for cying o

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

On 10/30/07 1:23 PM, 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 would

Re: Reference implementation currently too hard to install in Windows

Hi Jonathan, Thanks for the feedback; I agree the Windows build is too hard to install. Last I checked it wasn't possible to build Windows binaries with SML/NJ. I will talk to my contacts who work on SML/NJ and see if there's something we can do to make this more seamless. Thanks again for the

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

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 don't have a full implementatio

RE: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

Its the es4 "discuss" list, I think the "technical discussion only" is probably overly restrictive, there's lots of subjective judgements involved in evaluating languages. We just want to hear workable feedback and "it has too many features" or it has many good features that won't work well toge

Re: Number handling

On Oct 30, 2007, at 12:55 PM, Yehuda Katz wrote: > After playing with the ES4 RI yesterday, my biggest concern comes > from the handling of various number types as compared to other types: > > * Literal numbers become ints, rather than Numbers. While ES4 is > still compatible with ES3 via some

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

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 don't have a full implementation yet (no one does), progress is looking good. Our latest e

Number handling

After playing with the ES4 RI yesterday, my biggest concern comes from the handling of various number types as compared to other types: * Literal numbers become ints, rather than Numbers. While ES4 is still compatible with ES3 via some very strange use of the constructor property, doing something l

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

On Oct 30, 2007, at 11:37 AM, Yehuda Katz wrote: Sent from my iPhone Twice :-/. Begin forwarded message: From: Yehuda Katz <[EMAIL PROTECTED]> Date: October 30, 2007 11:26:58 AM PDT To: Michael O'Brien <[EMAIL PROTECTED]> Cc: es4-discuss Subject: Re: [TLUG]: ECMAScript ("Javascript") Vers

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

On Oct 30, 2007, at 10:49 AM, Mark Miller wrote: On Oct 30, 2007 10:13 AM, Chris Pine <[EMAIL PROTECTED]> wrote: Yes, I read that. I am extremely doubtful that Microsoft is suddenly so concerned about browser compatibility for the benefit of the web. (When IE passes the Acid 2 test, let's

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

On Oct 30, 2007, at 10:45 AM, Steven Johnson wrote: > The suggestions of bloat and instability from some corners are rather > disingenuous when you consider that > > (1) at least one high-quality ES4 engine (Tamarin) will be available > with a > source license compatible with both open-source a

Fwd: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

Sent from my iPhone Begin forwarded message: From: Yehuda Katz <[EMAIL PROTECTED]> Date: October 30, 2007 11:26:58 AM PDT To: Michael O'Brien <[EMAIL PROTECTED]> Cc: es4-discuss Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM I spent all of yesterday writing code in

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

Sent from my iPhone On Oct 30, 2007, at 11:15 AM, Michael O'Brien <[EMAIL PROTECTED]> wrote: > Totally agree that ES4 can be implemented without undue bloat. ES4 VMs > should remain small with modest growth despite the features being > considered for ES4. > > We too are creating a compliant ES4

Re: Implementor Question

Brendan Eich wrote: > But again, two engines don't cut it, for footprint and memory > reasons. And two engines are intentionally unnecessary by the design > of ES4. (Catching up on this thread...) An additional technical aspect of the language, for newcomers who may not have noticed it: It

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

Totally agree that ES4 can be implemented without undue bloat. ES4 VMs should remain small with modest growth despite the features being considered for ES4. We too are creating a compliant ES4 implementation to serve embedded devices. So our target is not so much browsers, but small embedded d

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

Ooo... busted! (And right after I send out a non-technical-related email.) But yes, you are quite correct: we should probably go back to the original charter of this list (technical discussion only) and move the political issues to another venue. > When I raised non-technical points critical of

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

On Oct 30, 2007 10:13 AM, Chris Pine <[EMAIL PROTECTED]> wrote: > Yes, I read that. I am extremely doubtful that Microsoft is suddenly so > concerned about browser compatibility for the benefit of the web. (When > IE passes the Acid 2 test, let's talk again.) > > It's nice that MS has constructed

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

The suggestions of bloat and instability from some corners are rather disingenuous when you consider that (1) at least one high-quality ES4 engine (Tamarin) will be available with a source license compatible with both open-source and commercial vendors, so the claim that it will be hard for browse

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

Ric Johnson wrote: > Please note that Microsoft HAS responded on my blog (with a reply from > Brendon and myself) > > http://openajax.com/blog/ Yes, I read that. I am extremely doubtful that Microsoft is suddenly so concerned about browser compatibility for the benefit of the web. (When IE pa

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

Please note that Microsoft HAS responded on my blog (with a reply from Brendon and myself) http://openajax.com/blog/ PLEASE note: Although the domain is OpenAjax.Com, we are NOT part of the Open Ajax Alliance (although I am the contributor or Openajax.Org to Jon Ferraiolo ) I do not have any ad

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

>From a pragmatic perspective, it seems to that the critical goal behind all of this, is what will bring a better development environment for the future of the web, and the key to this is what will be broadly implemented. The choice of the name is of course around this central issue since the ES ti

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

zwetan wrote: > so sorry I don't buy the "ECMAScript must change its name" No, of course not. Nevermind that the scope of TG1 is "to standardize the syntax and semantics of a general purpose, cross platform, vendor-neutral dynamic scripting language called ECMAScript": http://www.ecma-inter

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

Ric Johnson wrote: > I think the MAIN problem is not technical, but rather political: Clearly. Hence the lack of substantive argument against the proposal and the recurring issue of the *name* of the language. > When I went to the Ajax Expereince, several people commented that > 1) There was

RE: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

Okay, good to air things out I suppose. If we wanted to use Tamarin as leverage to keep ES4 as close to AS3 as possible we're extremely incompetent (as evidenced by ES4's progress beyond AS3). Luckily, we have some competencies. Tamarin was well designed and shouldn't have to change too much

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

Ric Johnson wrote: > I did read it. However, I do beleive Doug's quote was "half of the of > the working group did NOT agree, but it is being pushed through > anyway". I wrote this down word for word at the time, but may have > attributed incorrectly. I'm not sure how Doug could have honestly sa

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

Brendan Eich wrote: > I'll also testify, as an outsider with no interest in Adobe, that the > Adobe (originally Macromedia) employees on TG1 have always worked from > shared principles and evidence to reach better design decisions, without > regard for a corporate agenda. I would like to confi