Re: Greedy triple-quoted string literals
On Feb 19, 2008 10:21 AM, liorean [EMAIL PROTECTED] wrote: On Feb 18, 2008 1:17 PM, liorean [EMAIL PROTECTED] wrote: On 19/02/2008, Garrett Smith [EMAIL PROTECTED] wrote (o.f)(); // =o This should be window. No it shouldn't. The grouping syntax specifically doesn't call GetValue in order to make delete and typeof operators able to use function-call-like syntax. Which makes up for this asymmetry. Right. Thank you. -- David liorean Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Greedy triple-quoted string literals
On Feb 18, 2008 1:17 PM, liorean [EMAIL PROTECTED] wrote:
Basically the idea was along the lines of investigating the effects of
removing GetValue usage from those productions whose semantics just
pass values through (such as all the shortcut evaluation operators,
parenthesised expressions, plain assignment, function arguments,
return statement etc.). The only semantics that would in effect be
changed are those for function calls. Function calls would always
remember the this-object of any member lookup since they are passed
around as a Reference object, while still not making that object
outside detectable. Of course if the function is referenced again
using member lookup, then a new Reference object would be created with
the new base object and the function object itself GetValue'd out of
the old Reference object.
On 20/02/2008, Garrett Smith [EMAIL PROTECTED] wrote:
a.f = function(){
return this;
}
s.f = a.f
print( f() ) // s
Well, you'd have to do f=s.f first, but you've got the principle right.
a.f ;
Just mentioning it doesn't change anything. The reference is created
by mentioning it, but since you're not storing it anywhere it just
gets garbage collected. You'd have to do f=a.f, jsut like you had to
do f=s.f above.
print( f() ) // a
Is this right?
With the changes above, then yes. The idea is that member lookups for
functions create a Reference (or rather a base:value tuple instead of
a base:slotname tuple), which is stored. This would be an intermediary
internal type that is never actually detectable from the script itself
other than in the form of retained this-values when passing function
objects around.
On 19/02/2008, Garrett Smith [EMAIL PROTECTED] wrote:
Is this like getValue with a hint for a thisArg?
On Feb 19, 2008 10:21 AM, liorean [EMAIL PROTECTED] wrote:
No, not really. And the way I described it is not quite what I want,
either. I'd want something similar to but not exactly like the
Reference type, such that a tuple with base and value is stored, not
base and name-of-property as is the case for Reference. A Reference
would allow replacing the value of the property between initialisation
and use, while I'd want something that stores the actual value at the
time of initialisation. Using a Reference also would require recursive
GetValue, which can be eliminated at initialisation time if it stored
the value instead of the name of the property.
If I'm understanding you correctly, you want a Reference type on a
function. Is this correct?
I want a base:value tuple returned from member lookups if the value of
the lookup is a function object. The Reference type is a base:slotname
tuple, meaning the actual value lookup would be delayed until use,
which is undesirable.
And that Reference has a value pointing to the object which will be
the this arg in Call. Right?
Yes.
If the event implementation is specified to extract
the function object, and calls fobj.[[Call]](EventTarget, arguments)
when the event is triggered, then it's not a problem at all. The specs
for DOM events do NOT specify how the this-object should be handled.
Nor do any other relevant spec from what I can tell. At the moment,
DOM0 and Saf/Op/Moz send the EventTarget as this-argument. Ie doesn't
send it for attachEvent et al, nor do some other DOM2Events
implementations (e.g. the one in Tasman).
I can't remember the last time I tried to use Mac IE. I remember that
it supported neither attachEvent nor addEventListener.
There's newer versions of Tasman. Tasman 0.9 was used in the MSN/OSX
browser, which contained DOM support much closer to that of Gecko,
Presto and Webkit than to that of Tasman 0.1 or Trident. Tasman 1.0 is
also used in Entourage in Office:Mac.
Instance methods would ignore any this-value sent, no? So this really
wouldn't change anything for them at all.
Can you explain more?
The way I understands the ES4 proposals, [[Call]] on instance methods
ignore the first argument (the this.value) and instead always set the
instance as the this-value. So whatever first argument is sent to
[[Call]], it will have exactly zero impact on the semantics of the
program. Or is this a misunderstanding?
--
David liorean Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Fwd: ES3.1 Proposal Working Draft
[Maciej's latest message is a continuation of the following thread. I have removed email addresses from the correspondence below to avoid helping spammers. This conversation took place on e-TC39 -at- ecma-international.org ] Forwarded conversation Subject: ES3.1 Proposal Working Draft From: *Kris Zyp* Date: Feb 20, 2008 9:22 AM I have been going through ES3.1 working draft and making some comments and additions. However, one of the issues is rather broad. From what I understand (and hope), ES3.1 is supposed to forward compatible with ES4, but it appears there are a large number of violations of this principle in the ES3.1 Proposal Working Draft. These include: - Secure Eval - (I commented on the page more specifics) - Targeted additions - (I commented on the page more specifics) - typeOf - Doesn't exist in ES4 - richer reflection - Doesn't exist in ES4 (that I am aware of) - arguments as Array - Simply needs to be corrected per Lars's comments. - Deprecation section - These don't cite any ES4 deprecations, so I am not sure if these are really deprecated in ES4 (which is a requirement for deprecation in ES3.1) I also added Getters and Setters and Destructuring Assignment sections as we believe these are very high priority additions for ES3.1. Thanks, Kris -- From: *Mark S. Miller* Date: Feb 20, 2008 9:30 AM I'm confused. Doesn't this violate the no new syntax in ES3.1 design rule? -- Cheers, --MarkM -- From: *Kris Zyp* Date: Feb 20, 2008 9:36 AM Indeed you are right. Is this really a core value of 3.1 to be preserved? It is quite possible for non-syntactical changes to have a larger impact than syntactical changes. Syntax seems like a very arbitrary rule for deciding on inclusion of additions. Kris -- From: *Mark S. Miller* Date: Feb 20, 2008 10:18 AM It is arbitrary. I would be happy to replace it with another non- or less-arbitrary rule if we can quickly agree on one. But if we rely only on our taste for minimalism, then how do we guard against the following dynamic that I call The Tragedy of the Common Lisp: Each of us has some pet addition we think would be a great addition to the language. const, decimal, getters and setters, destructing assignment -- all these have come up just this morning!. Each of these makes the language larger and more complex, imposing a general diffuse cost on everyone. When arguing about any one of these by itself in the absence of a rule, each of us individually cares more to see our pet feature adopted than to prevent someone else's particular pet feature from being adopted. This is one of the reasons design by committee often goes bad. Only by adopting some rule do we raise the stakes. We all know that to agree to a feature that would violate the rule is to set a bad precedent and let open the floodgates of featuritis. Language design should be more like writing a sonnet and less like writing a phone book. Again, shouldn't we be having this discussion on es4-discuss? -- Cheers, --MarkM -- From: *Kris Zyp* Date: Feb 20, 2008 10:35 AM I understand, although I think it is difficult to come up with a reasonable succint rule that can be applied effectively, when each feature addition is really an ROI decision. We probably come up with a myriad of useless features for any given rule. We may just need to be very stingy in our ROI evaluation. On the otherhand, one rule that I think may be very valuable, is limiting to prior implementation. Prior implementation precedence does provides a very finite, limited set of possible features to choose from, and these features are of extra value since they improve cross-browser interoperability and therefore have accelerated adoption opportunity. They also have benefitted from real-world testing. I am not insisting on a strict following of this rule, but I do think it could be a very useful rule and definitely keep the features to a small set. There are also a number of features in the current working draft that could be omitted on the basis of this rule (typeOf, reflection, tail recursion, etc). I will let someone else make that call, definitely a much larger mailing list :). Kris -- From: *Maciej Stachowiak* Date: Feb 20, 2008 10:41 AM No new syntax actually does create a meaningful benefit, which is ability to do graceful degradation in browsers that don't support the new language. New builtin types, properties and methods can be tested for from script before using it, but new syntax can't since the presence of it alone will cause a syntax error at parse time. So it is less arbitrary than some other possible rules. Regards, Maciej -- From: *Mark S. Miller* Date: Feb 20, 2008 10:54 AM Ok, would anyone here mind if I forward the conversation so far to es4-discuss? -- Cheers, --MarkM -- From: *Kris Zyp* Date: Feb 20, 2008 10:54 AM True in the immediate future, but there will be a reverse effect down the road. At
Numbers (was: Phone Conference)
[Another recent discussion on e-TC39 -at- ecma-international.org. This one started as an administrative discussion. I have removed the administrative bits and left those of potential general interest. Since the thread is here all gathered together, I have also removed the parts where one message quotes a previous. I don't believe any meaning has been lost.] Forwarded conversation Subject: ES3.1 WG Phone Conference From: *Mike Cowlishaw* Date: Feb 19, 2008 11:25 AM [...] perhaps you can include in that discussion a rough outline for the decimal support? Mike -- From: *Mark S. Miller* Date: Feb 19, 2008 2:26 PM Hi Mike, I am new to the EcmaScript standards group so my apologies if I'm confused about some distinctions. But as I understand it from looking at ES3.1 documents and talking to others interested in ES3.1 (all of whom are included in the addressee list), decimal is not part of ES3.1. Frankly, if it were, I would argue that it should be removed. - From: *Mike Cowlishaw* Date: Feb 20, 2008 12:28 AM Hi Mark, thanks for the note. It does seem to be missing from the documentation. However, I was under the impression that this was discussed by the ES3.1 informal group last year and they intended to include it. Perhaps you could explain why? It is especially necessary in languages designed for human interaction. See the FAQ at: http://www2.hursley.ibm.com/decimal/ for some of the reasons. It sounds as though, at some point in the future, I should attend a meeting of the group and go through the background of this, and also the state of decimal support in other standards and languages (IEEE 754r, ISO C, C#, Python, etc.). -- From: *Douglas Crockford* Date: Feb 20, 2008 8:28 AM I have no memory of any intention to include the decimal format in ES3.1. -- From: *Mike Cowlishaw* Date: Feb 20, 2008 8:51 AM Hi Doug, I'm somewhat confused, then -- the notes I have (from at least two sources) of the ES 3.1 breakout meeting last April (written by Pratap, I think) with Douglas Crockford, Allen Wirfs-Brock, Adam Peller, Pratap Lakshman participating has an extensive discussion on how to include decimal, in the list of the following general points of consensus among the participants. I have no memory of the discussion, because I was not there, but I certainly read it as an intent to include decimal -- or I would have raised the topic earlier. [And it would be odd, indeed, for a scripting language to not have support for the primitive types in C and C#, especially when the type is specifically designed for human-oriented and scripting applications :-).] Mike -- From: *Mark S. Miller* Date: Feb 20, 2008 8:52 AM C#, Python, All Lisps, Smalltalk, Java, and almost every other dynamic symbolic language that people use have unlimited precision integers. If I decided to agitate to add a numeric type to ES3.1, that would be my first choice. Btw, Java's BigDecimal, if I understand it, is unlimited precision, and so includes all the integers as well as all the numbers represented by your proposal. If you did manage to convince me of the need for decimal floating point, that might be my second choice, but I doubt it. However, I have held back from even advocating my first choice because the whole reason for the existence of ES3.1 is to hold the fort against featuritis. The ES3.1 WG has adopted a particular design rule to help enforce some design discipline: no syntactic changes. As some members of this working group knows, I have been a fan of adding const to ES3.1, since it is a big help to readability and reliability, and is already recognized in many widely deployed old JavaScript systems. I hereby withdraw that suggestion, in order to avoid setting a bad precedent. Given only the current syntax and compatibility needs, 3 is necessarily a double precision floating point literal. Since the language has already committed to a path making it impossible to write an integer literal simply, I think it is best to leave not-quite-well-enough alone and not introduce integers to the language. I am willing to sacrifice integers for the sake of simplicity+compatibility. Please consider sacrificing decimal for the same reason. -- From: *Allen Wirfs-Brock* Date: Feb 20, 2008 8:59 AM Decimal arithmetic has always been on the table as something that could be considered for ES3.1. We actually talked about it a bit with Adam Peller at the April 2007 meeting in Newton. We've never had what I would consider to be a final list of features for ES3.1 inclusions. We've only had various strawman lists, primarily put together my Douglas, Pratap, and myself. I've always assumed that it was up to IBM/Mike's to advocate for inclusion of decimal arithmetic and to show that it could be supported in a manner that is practical and consistent with the overall ES3.1 design goals. -- From: *Mark S. Miller* Date: Feb 20, 2008 9:06 AM I should explain
Re: ES3.1 Proposal Working Draft
Each of us has some pet addition we think would be a great addition to the language. const, decimal, getters and setters, destructing assignment -- all these have come up just this morning!. Each of these makes the language larger and more complex, imposing a general diffuse cost on everyone. Mark, as I recall, the discussion at the March meeting in Newton involved implementing decimal arithmetic in ES3.1 to *replace* the floating point implementation in ES3, thus no new syntax. Yes, this would have unexpected results for those who actually have code logic which expects a value of 46.19 pounds, in Mike's example (see Numbers thread) but the benefits here seemed to far outweigh this discrepancy. I can't speak to the technical level of detail that Mike can, but at a high level it's seen as a bug by the vast majority of users, and for all practical purposes, that's what it is.___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Proposal Working Draft
2008/2/20 Adam Peller [EMAIL PROTECTED]: Mark, as I recall, the discussion at the March meeting in Newton involved implementing decimal arithmetic in ES3.1 to *replace* the floating point implementation in ES3, thus no new syntax. Yes, this would have unexpected results for those who actually have code logic which expects a value of 46.19 pounds, in Mike's example (see Numbers thread) but the benefits here seemed to far outweigh this discrepancy. I can't speak to the technical level of detail that Mike can, but at a high level it's seen as a bug by the vast majority of users, and for all practical purposes, that's what it is. I was not at the March meeting. If decimal is sufficiently compatible with binary double precision floating point to keep old programs working, I might be willing to consider *replacing* double with decimal. How compatible are they? What numbers are representable as double but not decimal? Does decimal have NaN, Infinity, -Infinity, and -0.0? (Btw, I never liked -0.0. And I especially dislike ES3's behavior that 0.0 === -0.0. However, I would argue against making incompatible changes to this.) The other design constraint is that ES4 be a compatible superset of ES3.1. In light of your message, I checked the ES4 wiki pages. http://wiki.ecmascript.org/doku.php?id=proposals:numberss=decimal seems to imply that use of ES3 syntax for numbers is to be interpreted (approximately) according to ES3 rules. Are the ES4 folks willing to *replace* binary floating point with decimal and drop the decimal literal syntax? If not, then I don't see how we could allow decimal into ES3.1. -- Cheers, --MarkM ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: AOP Compatibility
On Feb 20, 2008, at 10:17 AM, Kris Zyp wrote:
Is there any way this compatibility can be mitigated? I am assuming
there is
no conceivable way to actually replace methods ad-hoc with arbitrary
functions and retain sane typing and class expectations.
I'm not sure why you assume this. Latest RI downloaded from http://
ecmascript.org/ :
$ ./es4
ECMAScript Edition 4 RI v0.0M2 (Fri Feb 15 13:37:13 2008)
save_getTime = Date.prototype.getTime
[function Function]
Date.prototype.getTime = function advice() { intrinsic::print
(before getTime); let t = save_getTime(); intrinsic::print(after
getTime); return t; }
[function Function]
d = new Date
Wed, 20 Feb 2008 22:15:18 GMT+
d.getTime()
before getTime
after getTime
1203545718235
save_Date_parse = Date.parse
[function Function]
Date.parse = function more_advice() { intrinsic::print(yay!);
return save_Date_parse.apply(this, arguments); }
[function Function]
Date.parse(Date())
yay!
1203545824000
The builtins are backward-compatible as to class object and prototype
mutation, including AOP hacks. The only proposed change for ES4,
dependent on opt-in versioning, is making the constructor (now type)
bindings immutable. Replacing Date in the global object is much less
commonly done (but not unknown: Joel Spolsky's fogbugz does this, we
learned via a crucial experiment in Firefox 3 beta 2).
/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Proposal Working Draft
On Feb 20, 2008, at 1:00 PM, Adam Peller wrote: Each of us has some pet addition we think would be a great addition to the language. const, decimal, getters and setters, destructing assignment -- all these have come up just this morning!. Each of these makes the language larger and more complex, imposing a general diffuse cost on everyone. Mark, as I recall, the discussion at the March meeting in Newton involved implementing decimal arithmetic in ES3.1 to *replace* the floating point implementation in ES3, thus no new syntax. Yes, this would have unexpected results for those who actually have code logic which expects a value of 46.19 pounds, in Mike's example (see Numbers thread) but the benefits here seemed to far outweigh this discrepancy. I can't speak to the technical level of detail that Mike can, but at a high level it's seen as a bug by the vast majority of users, and for all practical purposes, that's what it is Besides compatibility issues, this would be a significant performance regression for math-heavy code. I would consider this a showstopper to implementing such a change. I also agree with Mark's comment that arbitrary-precision integers and arbitrary-precision rationals seem like more generally useful types than decimal floating point, if any numeric types are to be added, but that seems like an issue more for ES4 than 3.1. - Maciej ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Proposal Working Draft
On Feb 20, 2008, at 1:00 PM, Adam Peller wrote: Each of us has some pet addition we think would be a great addition to the language. const, decimal, getters and setters, destructing assignment -- all these have come up just this morning!. Each of these makes the language larger and more complex, imposing a general diffuse cost on everyone. Mark, as I recall, the discussion at the March meeting in Newton involved implementing decimal arithmetic in ES3.1 to *replace* the floating point implementation in ES3, thus no new syntax. Yes, this would have unexpected results for those who actually have code logic which expects a value of 46.19 pounds, in Mike's example (see Numbers thread). Hi Adam, Mike: I'm not sure what was to blame for that Machester car-park example -- IEEE double can multiply 4.2 by 11 and round properly: js 11*4.2 46.2 js (11*4.2).toFixed(2) 46.20 Cc'ing Mike in case he knows the full story (it's a fun example and useful real-world evidence of something, I bet). but the benefits here seemed to far outweigh this discrepancy. No, sorry -- too much real-world code, not to mention synthetic benchmarks, depend on hardware-implemented floating point. There are also enough numerical and semi-numerical JS apps around that count on IEEE-754 double precision quirks that we cannot change the number type without opt-in versioning. Anyway, the idea of ES3.1 as I understand it (and at least Mark Miller agrees) is not to promulgate a new, incompatible version with a distinct MIME type (including version= parameter). ES3.1, everyone involved at the last Ecma TC39 meeting seemed to agree, could be done as an Ecma TR (Technical Report). I'm against it becoming the next (4th) edition and making its way to ISO, especially if it has few changes from ES3, and I believe others involved in TC39 are also opposed to that. Being vague about 3.1 possibly including ES4 features is a sure way to delay both any useful 3.1 TR and the full ES4, which is now entering a multiple-interoperating-implementations phase of standardization. If we have to keep monitoring and arguing about what's in 3.1 that might not be exactly the same in 4, to preserve the 3.1 4 subset relation, we all lose (by my definition of lose). I can't speak to the technical level of detail that Mike can, but at a high level it's seen as a bug by the vast majority of users, and for all practical purposes, that's what it is. Yes, I keep reciting its status as the most duplicated JavaScript Engine bug on file at https://bugzilla.mozilla.org/ (to wit, https:// bugzilla.mozilla.org/show_bug.cgi?id=5856). But that does not mean it can be fixed with an incompatible change. The thinking for ES4 was to support a 'use decimal' pragma, for block- or wider-scoped explicit opt in. This proposal, http://wiki.ecmascript.org/doku.php?id=proposals:decimal with this discussion page http://wiki.ecmascript.org/doku.php?id=discussion:decimal stood for a while, but was superseded by http://bugs.ecmascript.org/ticket/222 And I believe there was an email conversation or two in which Mike was included. At this point, I would find it helpful to summarize the thinking on usable alteratives for decimal in ES4, and try to reach a consensus in this list. But again, I do not believe we can change the number type incompatibly -- that ship sailed in 1995. :-( /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: AOP Compatibility
On 2008-02-20, at 17:20 EST, Brendan Eich wrote: On Feb 20, 2008, at 10:17 AM, Kris Zyp wrote: Is there any way this compatibility can be mitigated? I am assuming there is no conceivable way to actually replace methods ad-hoc with arbitrary functions and retain sane typing and class expectations. I'm not sure why you assume this. Latest RI downloaded from http:// ecmascript.org/ : I thought the question was about annotating class fixtures? But your reply made me think: So, built-ins cannot be classes, because they require backward compatibility? Or maybe I missed that there are sealed/class versions of built-ins (in some other namespace?) with just a thin veneer of prototype around them for back compatibility? ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: AOP Compatibility
On Feb 20, 2008, at 3:42 PM, Kris Zyp wrote: I thought the question was about annotating class fixtures? Yes, that was my intent, sorry I wasn't clearer. No problem, sorry for assuming you meant ES3-compatible code. I knew that built-ins were designed to be backwards compatible. I don't have the RI in front of me at the moment, but I assume you can't do replace a method on a user class with another ad-hoc function. Absolutely not with fixtures, but you can put the prototype qualifier in front of function definitions in classes to create prototype methods just like the ones in ES3's builtins, and you can make your class dynamic (although IIRC, all class objects where static properties live are mutable; class *instances* are fixed unless the class is dynamic -- Graydon or Jeff should correct me if I'm wrong). If you want to allow AOP, which is pretty much an integrity violation, you have to lower your shields. Formalizing AOP further, somehow supporting it without losing the integrity guarantees needed for early binding and strict mode, is out of scope for ES4. But you can do a lot with ES4's function types. If the guarantee is not about function object identity (e.g. for analysis of effects, or for inlining), rather only about function type, it's fine to use a non-fixture that has a type annotation. | prototype function AOPmeHarder(this:Widget, a:int, b:string):boolean| can be overwritten by advice, but the advice can't subvert type judgments. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: AOP Compatibility
I thought the question was about annotating class fixtures? Yes, that was my intent, sorry I wasn't clearer. I knew that built-ins were designed to be backwards compatible. I don't have the RI in front of me at the moment, but I assume you can't do replace a method on a user class with another ad-hoc function. Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: AOP Compatibility
Absolutely not with fixtures, but you can put the prototype qualifier in front of function definitions in classes to create prototype methods just like the ones in ES3's builtins, and you can make your class dynamic (although IIRC, all class objects where static properties live are mutable; class *instances* are fixed unless the class is dynamic -- Graydon or Jeff should correct me if I'm wrong). Of course a library function (like dojo.connect) that is called to advise a method on an object doesn't have control of how the object was created. If it is an instance of user class (and not dynamic), this function will this fail. This functionality is pretty core and heavily used by Dojo and I believe is used by other libraries as well. Of course existing code will continue to work, but it will be disappointing to find this function fail for new objects created with ES4 functionality. I don't know an easier solution, other than real AOP support. Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
proposed relationships of Secure EcmaScript, ES3.1, and ES4.
At http://wiki.ecmascript.org/doku.php?id=ses:ses Doug Crockford explains a rationale for a secure variant of EcmaScript, hereafter ses. I am part of a team working on two such variants, Cajita and Caja (Caja is mentioned on Crock's page. Cajita is a small ADsafe-like subset of Caja). On the first day of the January EcmaScript meeting, Crock gave a presentation http://javascript.crockford.com/ses.ppt on the goals for an official ses. By Crock's criteria (which I like), Cajita and ADsafe would be candidates, but Caja would not due to its lack of minimalism. Caja and Cajita are currently defined by http://groups.google.com/group/google-caja-discuss/web/caja-spec.pdf As we discussed it, the general sense was that the creation an ses seems like a valuable idea. But on the first day, the process of deciding on an ses did not seem to be a natural extension of the work of the EcmaScript committee. Perhaps this would be a topic for a different committee on another day. Due to a suggestion of Kris Zyp, the ses discussion revived on the second day. Kris' suggestion (Kris - please correct any inaccuracies) is that ES4 include an sesEval operation (name tbd) that would evaluate its first argument as an ses program in a lexical scope provided by its second argument. The rules of ses would be chosen so that a containing page running ES4 could safely sesEval a script from an untrusted third party, safe in the knowledge that the only effect this sesScript could have on the containing page is according to the objects that the containing page explicitly provides to the script. (The only entry points into those ES4 objects accessible from ses would be according to some whitelisting mechanism, such as Caja and Cajita currently implement.) At http://wiki.ecmascript.org/doku.php?id=es3.1:secure_eval I see the intention to include a secure eval() in ES3.1 while (elsewhere) deprecating the ES3 global eval() function. (Note that, regardless of what language the secure eval() evals, I disagree with the proposal on that page to make eval() be a method of strings. But we can argue about the packaging of sesEval() separately.) Crock and I met last Monday. Crock began the meeting by writing the provocative statement JSON ADsafe Cajita Caja ES3 ES4 on the whiteboard. To a first approximation each language is a proper subset of the languages to its right. However, currently, each of these subset relationships is broken in various ways. While I don't think these subset relationships can ever be fully repaired, I believe they can be made accurate enough for practical purposes. On Monday, Crock and I made good progress reconciling differences between ADsafe and Cajita. 1) To the degree that we can accommodate it within our other design goals, I propose that ES3.1 evolve to replace ES3 in this inequality, so as to help repair this inequality. I am certainly willing to evolve Caja and Cajita in coordination with any such effort. 2) I propose that Cajita be considered a candidate for ses. 3) I propose that ES3.1 and therefore ES4 include an sesEval() (name tbd) that evaluates its first argument as an ses program in a lexical scope provided by its second argument. 4) To facilitate the safe interaction between ses objects and ES3.1/ES4 objects: 4a) I notice that ES4 already has a notion of a strict mode flag. I propose that both ES3.1 and ES4 have behavior conditioned on a strict mode flag. 4b) At http://bugs.ecmascript.org/ticket/276#comment:11 I propose that, in strict mode, if a function is called as a function (as opposed to calling it as a method, constructor, or reflectively), then its this is bound to undefined. In the absence of strict mode, this should be bound to the global object for ES3 compatibility. 4c) At the EcmaScript meeting, I proposed that a function called by call, apply, or bind should have this bound to the first argument of that call, bind, or apply -- no matter what value that is. In ES3, if the first argument of call or apply is null or undefined, the function's this is bound to the global object. (If I recall correctly, there was general agreement with this proposal by itself. If I'm remembering this inaccurately, please correct me.) Although we could also make this difference of behavior conditional on strict mode, I propose that it be unconditional. Under these proposals, f.apply(undefined, [a,b]) f(a,b) f.call(undefined, a,b) so we have the ability to reflectively call functions either as functions (as above) or as methods. This reflective ability would be present in ses as well. However, considering Cajita as a candidate ses reveals a functionality hole: Because Cajita contains new but does not allow manipulation of the prototype chain, Cajita has no ability to reflectively call constructors. So... 5) I propose the addition of Function.prototype.newInstance(argList) such that f.newInstance([a,b]) new f(a,b) 5a) I separately propose that new f(a,b) be considered
Re: AOP Compatibility
On Feb 20, 2008, at 4:21 PM, Kris Zyp wrote: Of course a library function (like dojo.connect) that is called to advise a method on an object doesn't have control of how the object was created. If it is an instance of user class (and not dynamic), this function will this fail. This functionality is pretty core and heavily used by Dojo and I believe is used by other libraries as well. Of course existing code will continue to work, but it will be disappointing to find this function fail for new objects created with ES4 functionality. I don't know an easier solution, other than real AOP support. I think you're assuming a problem of the Doctor, it hurts when I do this variety. Non-dynamic classes are not for everything. Where you need them as integrity devices, you do not want Dojo's AOP, no way no how. Most objects will continue to be plain old Object instances. But note that even in today's world, DOM types are nominal -- there are non-dynamic classes under the hood. Not all DOM or similar browser embedding objects can be mutated freely. Dojo survives these hazards, as far as I know. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Fwd: proposed relationships of Secure EcmaScript, ES3.1, and ES4.
Resending after adding myself to es4-discuss.
On 20/02/2008, Mark Miller [EMAIL PROTECTED] wrote:
[+es4-discuss]
On Wed, Feb 20, 2008 at 4:59 PM, Mike Samuel wrote:
On 20/02/2008, Mark Miller wrote:
Since a language is commonly defined as the set of strings produced by a
particular grammar, is this equivalent to
JSON ⊂ ADsafe ⊂ Cajita ⊂ Caja ⊂ ES3 ⊂ ES4
People who know Unicode are dangerous ;). How did you type that?
Syntactic subsetting is implied but is not the main intent.
or does your inequality imply some semantic relationship such as:
The same string evaluated in an expression context produces an
equivalent result assuming no exceptions thrown.
The same string evaluated in a statement context has equivalent
side-effects assuming no exceptions thrown.
?
We need to consider each individually. Ideally, once relationships are
repaired
1) Any legal JSON text can be evaluated as a program in any of the
languages to its right.
* This had not been the case for JSON / ADsafe because of the severity
of the ADsafe blacklist, which Crock has now repaired.
* This is not the case for JSON / (Cajita or Caja) because of Caja's
current prohibition on names ending in double underbar. However,
Caja's restriction is an implementation artifact of the need to
translate Caja to ES3. Given appropriate changes in ES3.1, we may be
able to remove that restriction from Caja/Cajita-on-ES3.1/ES4.
* Could you explain the difference in Unicode newline rules that
prevents JSON from being syntactically a subset of ES*? Thanks.
There's three problems according to my reading of
http://www.ietf.org/rfc/rfc4627.txt but only the first is directly related
to syntax:
(1) There are JSON programs that are not valid ES programs.
The JSON program [ \u2028 ] where the unicode escape is replaced with its
literal equivalent is valid according to JSON since the set of characters
that can appear in a string unescaped is
unescaped = %x20-21 / %x23-5B / %x5D-10
but ES does not allow codepoint 0x2028 or 0x2029 to appear unescaped in a
string since they are newline characters.
(2) There are JSON programs that have the same text as ES programs but
different meaning.
ES262 says that all format control codepoints, such as 0x200C, should be
stripped out of the program in a pre-lex phase. This is not consistently
implemented:
eval('\u200c'.length) == 0 on SpiderMonkey, and 1 on most other
interpreters
JSON does not strip these characters out, so they are treated as
significant.
(3) There are JSON programs that can be parsed to ES but that cannot be
serialized back to JSON without losing track of where info was lost.
JSON does not put any limits on numbers, but ES does. ES will treat 1e1000
as Infinity. Since JSON does not have a value Infinity, it is unclear how
to implement toJSON(fromJSON([1e1000])).
cheers,
mike
* There is currently a conflict between JSON and ES3 regarding Unicode
Cf characters. I believe this is repaired by ES4. I do not know, but I
hope that this is repaired in ES3.1 as well. If so, then Caja and
Cajita will inherit this repair.
* The legal JSON string '{__proto__: 3}' cannot be correctly
evaluated as a JavaScript program on Firefox. In fact, it cannot even
be correctly unserialized by a JSON library. I don't think this can be
repaired. This is an example of a subset gotcha in theory that
probably makes no practical difference to anyone.
2) The relationship between ADsafe and Cajita is complex and evolving,
and should be discussed in a separate thread.
3) Cajita is, and should remain, a statically checkable subset of
Caja. Given a Caja program, one can statically determine whether it is
a Cajita program. Any valid Cajita program is a valid Caja program of
the same meaning. Cajita uses the Caja runtime.
4) Caja is (ideally) a fail-stop subset of ES3. The ideally is
modulo the gotchas listed in the Caja spec, some of which will
hopefully be repaired as Caja and ES3.1 evolve. As the Caja spec
explains, fail-stop is a bit broader than assuming no exceptions
thrown. It is assuming no failures are reported. The difference is
exactly that, in order to support the JavaScript feature-test pattern,
reading an absent property reports failure by returning undefined
rather than throwing an exception. Properties not enabled by the Caja
whitelist can thus be considered absent to Caja without violating
either the fail-stop notion or normal JavaScript expectations.
As for the subsetting relationship between ES3.1 and ES4, I believe
that everyone involved in both efforts intends this relationship to
hold. I hope they succeed. Hmmm. I suppose they is now we ;).
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
http://groups.google.com/group/google-caja-discuss
To unsubscribe, email
Re: proposed relationships of Secure EcmaScript, ES3.1, and ES4.
There's a lot of implicit context here, some of which may be new to es4-discuss readers. Also, not everything here is bound to become an Ecma standard, as noted in mail I sent earlier today (3.1 could be a TR and should be in the view of some on the TC39 committee). Comments inline below, but I wanted to clarify, since es4-discuss has mainly been about es4, not Caja*/SES/etc. On Feb 20, 2008, at 4:27 PM, Mark S. Miller wrote: At http://wiki.ecmascript.org/doku.php?id=ses:ses Doug Crockford explains a rationale for a secure variant of EcmaScript, hereafter ses. I am part of a team working on two such variants, Cajita and Caja (Caja is mentioned on Crock's page. Cajita is a small ADsafe-like subset of Caja). On the first day of the January EcmaScript meeting, Crock gave a presentation http://javascript.crockford.com/ses.ppt on the goals for an official ses. By Crock's criteria (which I like), Cajita and ADsafe would be candidates, but Caja would not due to its lack of minimalism. Caja and Cajita are currently defined by http://groups.google.com/group/google-caja-discuss/web/caja-spec.pdf One piece of missing context: the TC39 committee generally seemed to agree that developing and judging the winner among candidate secure dialects was both a multi-year mission and beyond the capabilities of TC39. Academics and others not willing or able to join Ecma would be needed. We wouldn't be able to judge soundness based only on formal methods -- we would need to see fairly broad real-world usage and evaluate successes and failures. And so on. I'm not saying SES is pie in the sky or out of bounds for es4-discuss -- far from it. I have hopes for your work, which I said at the last face to face was in front-runner position, if that can be said at this early stage -- I think it can, based on bird-nearly-in-hand simple-minded reasoning -- but I'd like to have other candidates to evaluate. I am saying that es4-discuss readers need to have expectations set about development, deployment, judging, and *then* standardization, if we are to follow Doug's beauty contest approach (which I like). As we discussed it, the general sense was that the creation an ses seems like a valuable idea. But on the first day, the process of deciding on an ses did not seem to be a natural extension of the work of the EcmaScript committee. Perhaps this would be a topic for a different committee on another day. I said something stronger: it's not the proper job for a committee in the closed-room, pay-to-play sense, to decide. Parliament hath not the competence, to borrow from Robert Bolt's play. I suggested a prize system with mechanized tests and proofs or other ways of objective judging, plus white/gray hat open-source hack attacks over a period of time. Just the thought of reps from Adobe, Apple, Google, Microsoft, Mozilla, Opera, Yahoo! and other fine organizations meeting to decide the winner leaves me cold. Due to a suggestion of Kris Zyp, the ses discussion revived on the second day. Kris' suggestion (Kris - please correct any inaccuracies) is that ES4 include an sesEval operation (name tbd) that would evaluate its first argument as an ses program in a lexical scope provided by its second argument. The rules of ses would be chosen so that a containing page running ES4 could safely sesEval a script from an untrusted third party, safe in the knowledge that the only effect this sesScript could have on the containing page is according to the objects that the containing page explicitly provides to the script. (The only entry points into those ES4 objects accessible from ses would be according to some whitelisting mechanism, such as Caja and Cajita currently implement.) We have experience in Mozilla with GreaseMonkey's injection of privileged methods into secure eval sandboxes. Frankly, it has been a trail of tears. The hazards are many and hard to see if the outer language has things like .call/.apply per ES3, extensions such as getters and setters, etc. A whitelist is obviously better than a blacklist, but I'm concerned that there are so many hazards, so hard to see, that you are creating what I called at the meeting a honey- pot for unwary programmers. In that light, Geoff Garen of Apple suggested the method should be called unsafeEval -- and I agreed! 1) To the degree that we can accommodate it within our other design goals, I propose that ES3.1 evolve to replace ES3 in this inequality, so as to help repair this inequality. I am certainly willing to evolve Caja and Cajita in coordination with any such effort. That's great to hear. 2) I propose that Cajita be considered a candidate for ses. By whom? We need a better way to judge, not merely good judges; we need other candidates. There should be no near-term Ecma stamp of approval that we rush to apply to some candidate, if I'm right about the need for other people and extensive
Re: proposed relationships of Secure EcmaScript, ES3.1, and ES4.
Hi Brendan, thanks for the long and thoughtful answer. I think we have
many points of agreement.
I'll be responding to your message point by point soon. Tonight I'll
just mention a few that jumped out at me.
On Wed, Feb 20, 2008 at 7:35 PM, Brendan Eich [EMAIL PROTECTED] wrote:
Now we could say something about the outer language and the kinds of
objects that could be injected. But now the secure dialect in the
sandbox is spreading its reference monitor or capability system into
the outer language, and that outer language can't be ES3, therefore
it can't be ES4-in-full (which is a superset of ES3, modulo de-facto
standards fixes).
I do not understand this comment, and it seems crucial that I do. Can
you please expand? Thanks.
4c) At the EcmaScript meeting, I proposed that a function called by
call, apply, or bind should have this bound to the first argument of
that call, bind, or apply -- no matter what value that is. In ES3, if
the first argument of call or apply is null or undefined, the
function's this is bound to the global object. (If I recall
correctly, there was general agreement with this proposal by itself.
If I'm remembering this inaccurately, please correct me.)
The minutes and trac should tell the truth, but I remember general
agreement on the global substitution for null and undefined being
considered a design flaw in ES3, which introduced call and apply.
That's great. The current behavior created, for Caja, a terrible
privilege escalation vulnerability that we have figured out how to
plug by unpleasant means we have yet to document or implement.
Repairing this behavior will make a future Caja a more tractable and
safer piece of engineering. Thanks!
5) I propose the addition of Function.prototype.newInstance
(argList) such that
f.newInstance([a,b]) new f(a,b)
The proposal I like is ... as a unary prefix splat operator that
mimics ...'s usage in rest parameters:
function f(...rest) { return new g(...rest); }
When I first saw splat at
http://bugs.ecmascript.org/ticket/276#comment:9 I immediately liked
it. I was enthusiastic about using it in exactly the way you suggest.
It's a nice idea -- my compliments. However, it fails the no new
syntax in ES3.1 rule, which I care about even more. Without splat or
newInstance, ES3.1 is otherwise reflectively complete re invocation.
There's no reason that reflective construction needs new syntax, so it
would be a shame to keep it out of ES3.1 only for that reason.
5a) I separately propose that new f(a,b) be considered sugar for
f.newInstance([a,b]), so that f can override newInstance to
distinguish being invoked as a constructor from being invoked by other
means.
This is a nice idea in the abstract, and any middle-aged language
that doesn't already follow the Zen of Python's There should be
one-- and preferably only one --obvious way to do it line could
perhaps afford to be expansive, and support both ... as splat and
newInstance.
However, desugaring new into a call to a metaprogramming function
without further security mechanism scares me. Right now a host-
provided function object [...]
Ok, you succeeded in scaring me too. I withdraw the suggestion until I
come up with something better thought out. Thanks for catching this
issue.
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 work
Graydon, Thanks -- that helps to understand the status. You are in a somewhat unique position having implemented more than any other. Given Jeff's roadmap outline and the goal of weighing the features against implementation experience -- which of the features that you have implemented do you feel were difficult, costly or problematic? In our implementation (Ejscript), we have implemented (with bugs): - classes - namespaces, including use pragmas - block scope - packages - units - pragmas - let, const, let-const - type expressions / definitions / annotations - runtime type checks (standard mode) - destructuring assignment - hashcode - meta objects - strict mode (incomplete checking) - type parameters - numbers decimal - getters setters Namespaces was a much bigger and more intrusive change that I first anticipated. Difficult to get it to perform well, but we're still working on it. However, once byte-code is generated for bound code, there is no cost. Similarly, block scope added considerable complexity. Program units were fairly straight forward as is strict mode and pragmas. Structural types and type checking is next on our high priority list. Michael Graydon Hoare wrote: Michael O'Brien wrote: Could Graydon give a snapshot of what is not implemented in the RI in terms of the proposals / features? I know the trac database lists all, but a punch list of the high priority deficits would be helpful. Sure. I can describe the state of most issues as named by the proposals page, I think. Some of the proposals have sort of no-longer-sensible names so I'm going to use the proposals page as a rough guide and name the things that have seemed, in my work, to be separate features of the RI. Implemented, may have bugs: - classes and interfaces - namespaces - pragmas - let, const, let-const - iterators - enumerability control - type expressions / definitions / annotations - runtime type checks (standard mode) - nullability - destructuring assignment - slice syntax - hashcode - catchalls - map vector - date time improvements - meta objects - static generics - string trim - typeof - globals - expression closures - name objects - type operators (is / to / cast / wrap) Implemented and partly working, but still in flux / work to do: - inheritance checking - strict mode - type parameters - structural types - numbers decimal - getters setters (structural part is incomplete) - packages Partially implemented / not yet working: - program units - generic function - updates to unicode - updates to regexps Unimplemented: - generators - tail calls - triple quotes - stack inspection - reformed with - resurrected eval (eval exists but may be wrong) - help for the argument object - this function / this generator In my mind the high priority deficits where I actually know what to do are: - extending strict mode - extending the part of the definer that checks inheritance The remaining issues on my list all involve some spec/discussion work (units and packages, type parameters, structural typechecks, tail calls, reformed rules for with/this/eval/arguments) -Graydon ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: implementation dependencies (was Re: ES4 work)
Comments below: Going further, I have mentally considered the language as providing 3 big categories of enhancement: fixtures, types, and namespaces. I think that within -- and possibly between -- these groups there are dependencies. For example, we can consider these levels of type-implementation: TY-VAL: a runtime representation of types exists, and values have a pointer to their type TY-PROP: properties can be annotated with types, and a dynamic check is made when an assignment is made TY-DEF: type-aliases (type T = ...) can be defined TY-STRUCT: the full structural type grammar exists (object types, array types, function types) TY-NULL: the nullability extension to the type grammar exists TY-NOMINAL: class and interface types exist, with a hard-coded subtype lattice TY-PARAM: the parametric type system exists TY-LIKE: the 'like' types exist TY-STRICT: approximate static checking of types TY-REFLECT: meta-objects exist and can be acquired with typeof This is a partial dependency list. You need at least TY-VAL to do TY-PROP, but it's probably possible to implement any combination of the remainder once you're at TY-PROP. You could also stop *at* TY-PROP, only permitting users to denote the ES3 types (prims and objs). Though IMO this would be silly. We began and have a fairly complete TY_VAL and TY_PROP. Next we did TY_NOMINAL and TY_REFLECT. We are missing DEF, STRUCT, NULL, PARAM and LIKE. We have partial STRICT. We can also consider levels of namespace-implementation: NS-VAL: a runtime type namespace exists, and has some nonempty population NS-PROP: every property has a namespace and namespace references can be used in reference expressions like obj.ns::prop and ns::lexref NS-USE: the use namespace and use default namespace pragmas automatically qualify definitions or references NS-DEF: namespace declarations are accepted and new namespaces can be defined through them, either anonymous or with strings NS-CLS: classes (and interfaces?) define their own namespaces for conventional OO visibility control NS-PKG: the package construct exists for automatically defining namespaces Similarly, this list is more linear at the top than the bottom: NS-PROP and NS-USE require NS-VAL, though one could stop there with (perhaps) a fixed population of namespaces. The remaining 3 are mostly orthogonal: you could for example stop implementing with NS-DEF and ignore classes and packages, and still have a useful system. Or do NS-CLS alone and ignore NS-DEF, using namespaces only to model class-visibility issues. I think this is very much an all or nothing. It is hard to separate out these from each other. We started with NS_DEF, NS_VAL and NS_PROP. NS_USE was easy NS_USE is pretty easy once you have NS_VAL and NS_PROP. NS_PKG is essential if you are going to handle package qualified variables and avoid name collisions. So I'd imagine it would be hard to have a cohesive whole without doing all these items. All the type and namespace issues depend, however, on fixtures. We are some ways towards proving that fixtures-in-absence-of-namespaces are equivalent to the dontdelete property attribute (see ticket #233, http://bugs.ecmascript.org/ticket/233) but if you have namespaces there appears to be a requirement to be modeling fixtures, to run the multiname algorithm properly. Fixtures are sort of super-dontdelete properties -- those that can safely be early bound, in addition to not being deletable -- and it's hard to make much use of the namespace or type systems without them. Agree. We had fixtures first and retrofitted namespace (which I would not recommend). Namespaces are so foundational, you need to design them in at the start. Otherwise, there is a lot of rework. Re-encoding the ES3 primitives as classes, and the new classes like map, vector and the meta objects, all require a fair amount of the TY and NS work: at least TY-NOMINAL, TY-PARAM and NS-CLS (I think). Looking at the builtins, I can't imagine how you could do them without namespaces. They are a vital solution to various name lookup and collision problems. Finally there is a category I left off the above elaboration, mostly because it is under-developed in the RI: control mechanisms. There are dependencies between tail calls, generators and stack inspection, and I can't say I fully understand the dependencies nor the impact they have on the rest of the implementation. There are a whole raft of implementation toughies that will vary a bit from implementation to implementation. We have spent a lot of time trying to get ES4 to be small and fast. But there is a long, long way to go. Michael -Graydon ___
Re: ES4 work
Michael O'Brien wrote: Graydon, Thanks -- that helps to understand the status. You are in a somewhat unique position having implemented more than any other. Given Jeff's roadmap outline and the goal of weighing the features against implementation experience -- which of the features that you have implemented do you feel were difficult, costly or problematic? Actually, despite my having acquired some sort of RI maintainer moniker, I did not write the majority of it. By volume I think the largest parts have come from Adobe and Opera people. The builtins and frontend each weigh about as much as the remainder (machine model, evaluator, type system). My sense was that I had the most difficulty with the type and scope rules, but not so much because they were problematic as much as that we kept changing the rules. Also that even a minor bug in the rules typically produces a non-booting system, as the builtins stop working. There was also (and continues to be) considerable subtlety in wiring up convincing builtin classes that behave the same as the ES3 primitives and ad-hoc host objects. I can certainly imagine your experience though: if one doesn't have namespaces or the proper block scope forms in the system to start with, retrofitting them will likely be annoying. Likewise types. But the RI had some portion of these from the get-go (we retrofitted a unified scope-initialization primitive into it once the rules became clear half way in, and this was costly). Structural types will probably pose a bit of pain because they require a type-term normalizer with some subtle parts. There is an example in type.sml but it's certainly not the sort that illuminates the subtle points! It should be cleaned up during spec'ing. That normalizer also gets significantly weirder once you introduce type parameters (it turns into a sort of partial evaluator). -Graydon ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
