RE: ES 3.1 implementations?
Yes, and of course SpiderMonkey. For no particularly good reason I simply have the other two positioned in my mind as perhaps being more (technically) approachable for somebody who wanted to plunge into such an effort. I may well be misguided in that perception. -Original Message- From: Brendan Eich [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2008 10:16 PM To: Allen Wirfs-Brock Cc: Robert Sayre; es4-discuss; [EMAIL PROTECTED] Subject: Re: ES 3.1 implementations? On Jun 25, 2008, at 8:53 PM, Allen Wirfs-Brock wrote: It would be great if somebody wanted to work on a proof of concept ES 3.1 implementation in a open code bases such as such as Webkit or Rhino. Don't forget SpiderMonkey. If anybody is interested in volunteering send a not to es3.x- [EMAIL PROTECTED] There's the ES4 RI as well -- did you have anyone already lined up to work on the 3.1 subset of it? /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES 3.1 implementations?
On Jun 25, 2008, at 11:46 PM, Allen Wirfs-Brock wrote: Yes, and of course SpiderMonkey. For no particularly good reason I simply have the other two positioned in my mind as perhaps being more (technically) approachable for somebody who wanted to plunge into such an effort. I may well be misguided in that perception. (Was that a cut? :-P) It's true, SpiderMonkey won't win any beauty pageants, but it gets the job done and people do hack on it. No mature and/or optimized engine is all that easy to hack on, and C or C++ is the wrong language for implementing interpreters and compilers, if the goal is clarity and extensibility. Java is better, SML is much better -- to pick non-random examples. Which reminds me, any thoughts on the RI subset? /be -Original Message- From: Brendan Eich [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2008 10:16 PM To: Allen Wirfs-Brock Cc: Robert Sayre; es4-discuss; [EMAIL PROTECTED] Subject: Re: ES 3.1 implementations? On Jun 25, 2008, at 8:53 PM, Allen Wirfs-Brock wrote: It would be great if somebody wanted to work on a proof of concept ES 3.1 implementation in a open code bases such as such as Webkit or Rhino. Don't forget SpiderMonkey. If anybody is interested in volunteering send a not to es3.x- [EMAIL PROTECTED] There's the ES4 RI as well -- did you have anyone already lined up to work on the 3.1 subset of it? /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES 3.1 implementations?
On Wed, Jun 25, 2008 at 10:43 PM, Douglas Crockford [EMAIL PROTECTED] wrote: There is an implementation in JavaScript at http://json.org/json2.js. This file has evolved since I last looked at it. We have an older copy in the Mozilla tree, http://mxr.mozilla.org/mozilla-central/source/dom/src/json/test/json2.js and Mozilla's native implementation matches its behavior in most cases, except where I intentionally diverged (our implementation always returns strict JSON, and thus won't return strings). A changelog would really speed my analysis of the new file, since I'm quite familiar with the old one. Happen to have one? -- Robert Sayre I would have written a shorter letter, but I did not have the time. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: dynamic attribute nomenclature
At today's ES 3.1 conference call (see http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jun_24_2008) we agreed to use the term Flexible for the property attribute that we recently had been calling Dynamic and which subsumes the DontDelete attribute. From: Allen Wirfs-Brock Sent: Wednesday, June 25, 2008 10:37 AM To: Lars Hansen; Mark S. Miller Cc: [EMAIL PROTECTED] x-discuss Subject: dynamic attribute nomenclature In Lars's feedback on the the June 11, ES3.1 draft he said: p26 8.6.1. (And throughout the spec) The meaning of dynamic in ES4 is something else (it means a non-fixture property). It would probably reduce confusion if the property name Deletable were used here, as I though we had agreed previously. Dynamic as currently used in ES3.1 means more than just Deletable, it also means that the property attributes (including the Dynamic attribute) can be modified and that it can be transformed between being a data and procedural property. Hence, the name Deletable seems to imply something too narrow. Playing around with the thesaurus, the best positive, active term that I could find that seems to be a reasonable description of this semantics is: Alterable (other, perhaps less satisfy or otherwise unacceptable alternatives include: changeable, mutable, modifiable, flexible, amendable) Note this would mean that data properties would expose properties named Writable and Alterable. My sense is that there is enough conceptual distance between those terms that there won't be too much confusion. Thoughts?? ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Off topic: teaching ES 4
Please forgive me for being off topic. To lessen the nuisance please answer me off-list. I have been assigned to work with DOM Scripting courses for higher education by the Web Standards Project EduTF. I am looking for three things: 1. Writings (and talks/slides/blog posts) about ES 4 from a pedagogic perspective. (The reason I am addressing this list.) 2. Writings about current and future ECMAScript (and the DOM) from a computer science perspective. (Quite hard to find actually.) 3. Opinions about a few books I have not read myself: a. Are they teaching best practice, unobtrusive DOM-scripting? b. Are they targeted at newbies, intermediate or advanced developers? Lars Gunther Going back to lurking... BTW if you want yto help me with question 3, the books are: * Learning JavaScript (Shelley Powers, O'Reilly, 2006) * Head First JavaScript (Michael Morrison, O'Reilly, 2008) * Beginning JavaScript (Programmer to Programmer) (Paul Wilton and Jeremy McPeak, Wrox, 2007) Smells dubious from its table of contents but - as I've said - comments are welcome * JavaScript(TM) Step by Step (Steve Suehring, Microsoft Press, 2008) Late publication date, but is the author really a web developer? * Sams Teach Yourself JavaScript in 24 Hours, 4th Edition (Michael Moncur, Sams, 2006) * Professional JavaScript for Web Developers (Wrox Professional Guides) (Nikolas Zakas, Wrox, 2005) * Practical JavaScript, DOM Scripting and Ajax Projects (Frank Zammetti, APress, 2007) AJAX specific books. * Adding Ajax (Shelley Powers, O'Reilly, 2007) * Unobtrusive Ajax (Short Cut series) (Jesse Skinner, O'Reilly, 2007) * Head First Ajax (Rebecca M. Riordan, O'Reilly, 2008) Will be published in July * Ajax Design Patterns (O'Reilly, 2006) Maybe better in DS 3 ? * Ajax: The Definitive Guide (Anthony T. Holdener III, O'Reilly, 2008) * Advanced Ajax: Architecture and Best Practices (Shawn M. Lauriat, Prentice Hall, 2007) * Enterprise AJAX: Strategies for Building High Performance Web Applications (David W. Johnson, Alexei White and Andre Charland, Prentice Hall, 2007) * Understanding AJAX: Using JavaScript to Create Rich Internet Applications (Joshua Eichorn, Prentice Hall, 2006) * Ajax for Web Application Developers (Kris Hadlock, Sams, 2006) ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: strict mode becomes use subset cautious
On Jun 26, 2008, at 1:34 PM, Allen Wirfs-Brock wrote: At today’s ES 3.1 conference call (see http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jun_24_2008) we agreed to adopt the essence of the proposal below and to use the subset name “cautious” to referred to the set of restrictions formerly known as “strict mode” Will ES4 also be making this change? If not, we need to add it to the list of subset rule violations. Is anyone keeping such a list? Does the ES3.1 committee intend to address all such issues by the July timeframe that ES3.1 is apparently targetting? Regards, Maciej _ From: Allen Wirfs-Brock Sent: Wednesday, June 25, 2008 12:38 PM To: Pratap Lakshman (VJ#SDK); Adam Peller; Sam Ruby; Mark S. Miller Cc: [EMAIL PROTECTED] x-discuss; es4-discuss@mozilla.org es4- discuss Subject: RE: Brief Minutes [RE: ES3.1 WG phone conference 24 June 08:00 PT] Following up on the “Strict Mode” discussion… As I advocated on the call, I think that by selecting “strict mode” a developer is really choosing to restrict themselves to using a subset of the complete language. The future-proofing issues of this relate to the possibility that there might be multiple such subsets that a developer might need to choose among. Should there be multiple named “strict modes” to choose among, how should they be named, can “strictness” of a mode increase in future versions, etc? I think some of the controversy could be eliminated if we simply eliminate the term “Strict Mode”. Instead I propose we have a “Use Subset” directive and that we name specific subsets in a meaningful and generally positive manner. For example, since the motivation of most of the proposed restrictions in ES3.1 strict mode is to provide a safer subset language I suggest that we call this subset “safety” (or perhaps “safety1” or “safetyA” or “safety2008” implying that in the future different safe subsets might be defined and we don’t want to give undo importance to this initial one). So, the first line of a “strict mode” compilation unit would now look like” “use subset safety” I would suggest that we actually define “use subset” such that a comma separated list of subsets is allowed. So, if somebody decided to define a subset that only contained the features of ES3 you might see something like this: “use subset safety,ES3” Since subsets are sets of restrictions, listing multiple subsets means to take the union of the restrictions imposed by all of the listed subsets. So “use subset safty,ES3” means that this compilation unit may only use those features defined by ECMA 262-3 and which are not excluded by the “safety” subset. So, assuming that “safety” excludes use of the with statement, such a compilation unit could not include use of the with statement nor could it include any use of a feature that is new in ES3.1 or ES4. Future versions of ECMAScript may add exclusions to a subset defined by an earlier version as long as the added exclusions only restrict capabilities that didn’t exist in the earlier version. For example, ES 4 in supporting the ES3.1 “safety” subset but add to it any features that are added in ES 4 but which are considered to be unsafe. A future version may not add exclusion to an pre-existing subset that restricts features that existed when the original subset was defined. For example if ES3.14 or ES5 decided that the for-in statement was unsafe, it could not add that restriction to the “safety” subset. However, it could define a new subset named perhaps “safety2010” that includes all the restrictions of the “safety” subset and in addition disallows use of the “for” statement. If a compilation unit specifies a subset that is not known to the implementation that is processing it, that subset restriction is simply ignored. The code in the unit is still either valid or invalid on its own merit just like is the case when no subset had been specified. _ From: Pratap Lakshman (VJ#SDK) Sent: Tuesday, June 24, 2008 11:43 AM To: Adam Peller; Sam Ruby; Mark S. Miller; Allen Wirfs-Brock; Pratap Lakshman (VJ#SDK) Subject: Brief Minutes [RE: ES3.1 WG phone conference 24 June 08:00 PT] Here are brief minutes from our call. Please take a look, and let me know if you want any changes by your EOD. I’ll upload it to the wiki and send a copy to Patrick Charollais (ECMA) for posting on the ECMA site tomorrow night (Redmond time). Attendees Adam Peller (IBM) Sam Ruby (IBM) Mark Miller (Google) Allen Wirfs-Brock (Microsoft) Pratap Lakshman (Microsoft) Agenda On posting the latest draft to the wiki Getters/Setters Decimal Setting up a review based on Lars' feedback on the 11 June draft Minutes Would like to add a couple more items to agenda that we can get to if we have the time (1) inconsistence
Re: ES 3.1 implementations?
On Jun 25, 2008, at 8:53 PM, Allen Wirfs-Brock wrote: It would be great if somebody wanted to work on a proof of concept ES 3.1 implementation in a open code bases such as such as Webkit or Rhino. If anybody is interested in volunteering send a not to [EMAIL PROTECTED] We would gladly accept SquirrelFish patches for any part of ES3.1 that is not in conflict with the corresponding part of ES4. Regards, Maciej -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Robert Sayre Sent: Wednesday, June 25, 2008 5:35 PM To: es4-discuss; [EMAIL PROTECTED] Subject: ES 3.1 implementations? I am putting together feedback on the JSON features proposed for ES 3.1, and I was wondering if there any ES 3.1 implementations available. Given the limited scope of the spec, I would expect to see at least one implementation completed soon if there isn't one. Maybe in Rhino or something? -- Robert Sayre I would have written a shorter letter, but I did not have the time. ___ Es3.x-discuss mailing list [EMAIL PROTECTED] https://mail.mozilla.org/listinfo/es3.x-discuss ___ Es3.x-discuss mailing list [EMAIL PROTECTED] https://mail.mozilla.org/listinfo/es3.x-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: strict mode becomes use subset cautious
There has been no discussion in the ES4 WG about adopting the ES3.1 convention in this matter. I don't think that a list of subset violations exists. The closest thing we have is probably my response to the 11 June draft of ES3.1, in which I pointed out all the problems I could see at the time. (A bit of a rant this, but speaking for myself, I object to the strongly ideological slant of some of the ideas that have gone into the current ES3.1 strict mode, such as disallowing semicolon insertion in strict mode, and I see the inclusions of features like that as another real problem with the subset relation. In the past the ES4 WG has tried to avoid cosmetic changes to the language, and we've also been skeptical of changes that increase the tax of moving to strict mode. We want strict mode to be used, which means striking a balance between safety and convenience. It is possible that 3 programs out there have bugs caused by optional semicolon insertion. But it also likely that 3 million programs will not be ported to (or written to) strict mode if semicolon insertion is disallowed.) --lars From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak Sent: 27. juni 2008 01:33 To: Allen Wirfs-Brock Cc: [EMAIL PROTECTED] x-discuss; es4-discuss@mozilla.org es4-discuss Subject: Re: strict mode becomes use subset cautious On Jun 26, 2008, at 1:34 PM, Allen Wirfs-Brock wrote: At today's ES 3.1 conference call (see http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jun_24_2008) we agreed to adopt the essence of the proposal below and to use the subset name cautious to referred to the set of restrictions formerly known as strict mode Will ES4 also be making this change? If not, we need to add it to the list of subset rule violations. Is anyone keeping such a list? Does the ES3.1 committee intend to address all such issues by the July timeframe that ES3.1 is apparently targetting? Regards, Maciej _ From: Allen Wirfs-Brock Sent: Wednesday, June 25, 2008 12:38 PM To: Pratap Lakshman (VJ#SDK); Adam Peller; Sam Ruby; Mark S. Miller Cc: [EMAIL PROTECTED] x-discuss; es4-discuss@mozilla.org es4-discuss Subject: RE: Brief Minutes [RE: ES3.1 WG phone conference 24 June 08:00 PT] Following up on the Strict Mode discussion... As I advocated on the call, I think that by selecting strict mode a developer is really choosing to restrict themselves to using a subset of the complete language. The future-proofing issues of this relate to the possibility that there might be multiple such subsets that a developer might need to choose among. Should there be multiple named strict modes to choose among, how should they be named, can strictness of a mode increase in future versions, etc? I think some of the controversy could be eliminated if we simply eliminate the term Strict Mode. Instead I propose we have a Use Subset directive and that we name specific subsets in a meaningful and generally positive manner. For example, since the motivation of most of the proposed restrictions in ES3.1 strict mode is to provide a safer subset language I suggest that we call this subset safety (or perhaps safety1 or safetyA or safety2008 implying that in the future different safe subsets might be defined and we don't want to give undo importance to this initial one). So, the first line of a strict mode compilation unit would now look like use subset safety I would suggest that we actually define use subset such that a comma separated list of subsets is allowed. So, if somebody decided to define a subset that only contained the features of ES3 you might see something like this: use subset safety,ES3 Since subsets are sets of restrictions, listing multiple subsets means to take the union of the restrictions imposed by all of the listed subsets. So use subset safty,ES3 means that this compilation unit may only use those features defined by ECMA 262-3 and which are not excluded by the safety subset. So, assuming that safety excludes use of the with statement, such a compilation unit could not include use of the with statement nor could it include any use of a feature that is new in ES3.1 or ES4. Future versions of ECMAScript may add exclusions to a subset defined by an earlier version as long as the added exclusions only restrict capabilities that didn't exist in the earlier version. For example, ES 4 in supporting the ES3.1 safety subset but add to it any features that are added in ES 4 but which are considered to be unsafe. A future version may not add exclusion to an pre-existing subset that restricts features that existed when the original subset was defined. For example if ES3.14 or ES5 decided that the for-in statement was unsafe, it could not add that restriction to the safety subset. However, it could define a new subset named perhaps safety2010 that includes all the
RE: ES3.1 Draft: 24 June 2008 version available
Is there a changelog between successive ES3.1 drafts? --lars From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pratap Lakshman (VJ#SDK) Sent: 26. juni 2008 22:23 To: [EMAIL PROTECTED] Cc: es4-discuss@mozilla.org Subject: ES3.1 Draft: 24 June 2008 version available I have uploaded to the wiki (link http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_dra ft , see under Draft Specification) the current draft of the specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification (specifically, on the 11 June draft). Revision history is at the end of the document. I have not yet incorporated the review comments you sent on the 11 June draft. For the moment I am focusing on incorporating normative content, but will certainly address all of your review comments in upcoming drafts. pratap ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
