Kona notes

Tobie Langel tobie.langel at gmail.com
Thu Nov 20 23:15:27 PST 2008

Thank you Waldemar, this was extremely useful.



On Nov 21, 2008, at 08:07 , Waldemar Horwat wrote:

> It's the first time in a week that I'm able to access the internet  
> (the hotel's network is far too weak for my laptop, so I'm at Lava  
> Java now).  Here are my somewhat scattered notes from this  
> meeting.  I know I missed some items.
>    Waldemar
> Tuesday notes:
> SES meeting:  Work it out in committee instead of doing a competition?
> Cajita and Valija levels:  simple vs. current web-compatible.
> valija Å Microsoft web sandbox
> They differ in that web sandbox passes out real references to  
> objects but uses the current context to limit what you can access  
> on them (an ACL paradigm).   Valija restricts reference passing (a  
> capability paradigm).  In web sandbox the host can create channels  
> between two sandboxes, but only primitive values can be passed over  
> a channel.
> Valija:  all contexts see the own properties of an object in the  
> same way.  They see the basic protype properties in the same way  
> but differ if one monkey-patches a prototype; only that context  
> sees that patch.
> Jacaranda:  pure object capability
> Recent web sandbox discovered and fixed security bugs:   
> arguments.prototype.caller.caller to get at the Function  
> constructor; Function() to execute arbitrary code (didn't realize  
> that it did the same as new Function()).
> Mozilla monitors greater than cubic complexity in regular  
> expresssions.
> Doug Crockford:  Get rid of all native prototypes, constructor  
> fields, etc.
> Problem with catch-alls/interceptors.  Assertion was made that an  
> interceptor is just like putting a getter and a setter on every  
> property.  However, this behaves materially differently for  
> prototype objects:  just the mere presence of a getter or a setter  
> on a prototype prevents one from writing to create expandos in the  
> derived object.
> How do multiple contexts, as implemented by prototype inheritance  
> on the built-in objects, interact with getters/setters and  
> introspection?
> other issues with interceptors are the ability to masquerade as  
> other objects and run arbitrary user code for tests such as  
> HasProperty.  Also, the current spec assumes that the internal  
> operations such as HasProperty, Put, etc. are consistent with each  
> other.
> How would iteration work with interceptors?
> Relying on an initial script to lock down/delete nasty properties  
> from the global object + having eval do the evaluation in a virgin  
> copy of the global object = oops!
> More support for a stratified virtualization system where the outer  
> program can do an "eval" in a virtual and separate inner universe  
> with hooks for what happens on various property lookups, calls, etc.
> Brendan:  Catch-all introspection is extraordinarily difficult due  
> to recursion suppresion (a simple flag won't work because the  
> handlers may need to look up other things) and related  
> complexities.  Wouldn't want to go through that again.
> New name:  "webfoot" for the concept of providing hooks for  
> sandboxing.
> Some folks want to vastly reduce the scope of or delay HTML 5 to  
> make securing it easier.
> Wednesday notes:
> Turf war if we take over all aspects of sanitization (HTML, CSS,  
> etc.)?
> Decimal is out because the spec isn't ready and there are some  
> problems that are not small spec errors -- generic behavior of  
> functions, etc.
> Argued about reflection:
> - Not clear if it's compatible with const/let.  Discussed this for  
> a while with no resolution.
> - Extracting getters and setters exposes too much information --  
> we'll need to either spec which ones are == to each other or live  
> with undefined behavior.
> - Name conflicts with Prototype and other libraries.
> List of strict mode restrictions from ES4 discussions of a few  
> months ago:
> - No null-to-global-object this propagation (if non-strict mode  
> doesn't already do this)
> - Throw on writes to read-only properties
> - Throw on deletes of dontdelete properties
> - delete o.x when x is not in o but in the proto should throw
> - Reference before definition causes static errors (in what contexts?)
> - Arity checking  (conflict with 3.1?)
> - Global variable auto-creation
> - Duplicate formal parameters, parameters with same name as var or  
> local functions, etc.
> - Duplicate names in object initializers
> - FunctionObject.arguments (not in ES3 but woefully used in practice)
> - Use of arguments object (maybe?)  (conflict with 3.1?)
> - Useless expressions (maybe?)
> - Prohibit with and eval (if non-strict mode doesn't already do this)
> 11.4.1:  Agreed to change this to always throw if step 5 is reached  
> in strict mode.  This prevents "delete x" from deleting a global  
> variable.
> delete a.b
> (x+y)
> would cause inappropriate semicolon insertion in strict mode.   
> Also, MemberExpression doesn't accomplish much here, since you can  
> still write delete (4).
> Fix:  Remove grammar restriction altogether.
> Debate about whether to change the spec to require implementations  
> to ignore extra arguments passed to built-in methods (5th paragraph  
> of chapter 15).  This would interfere with arity checking in future  
> variants of strict-arity mode because currently programs that pass  
> extra arguments are non-portable, while they would become portable  
> if the spec mandates that extra arguments are ignored.  Also, there  
> are some methods on which we have a placeholder for locale  
> objects.  Mozilla makes use of an extra argument in its string  
> replace function.  Agreed to revert to ES3 text.
> 7.8.5:  Allowing /[/]/:  This would be a change in this section.   
> It's already allowed by the chapter 15 grammar.
> /(.(/ is a syntax error in Mozilla and ES3.  We'll leave it that way.
> Debate on setting properties and SameValue check:  Is NaN a single  
> value or possibly many, distinguishable via implementation-defined  
> means.  Choices:
> - Require that NaNs be indistinguishable even if we adopt IEEE  
> 754-2008.
> - Allow read-only NaNs to be "replaced" with other NaNs, with the  
> result being that the original NaN stays.
> - Never do SameValue tests.  Replacing a read-only value is always  
> an error even if it's being replaced by the same value.
> Resolution:  Third choice.  We'll get rid of SameValue checks.
> Discussion on what it means to be an Array, a RegExp, a Function,  
> etc.  Host objects can have any Class value.  Some places in the  
> spec distinguish on "x is an Array object", others distinguish on  
> [[Class]].  Relevant for things like bind which must distinguish  
> between length indicating the preferred number of arguments and  
> length being an unrelated size of something.
> Thursday notes:
> Concerns about ES3.1:
> Object.keys(fast):  need second argument?
> Object constructor method name conflicts
> ES3.1 opt-in
> Compatibility with future const
> Reflection leakage
> Chapter 16
> this binding for callbacks (array comparator etc.)
> Object.getPrototypeOf
> Exposition of chapters 8 and 10
> Arguments array in strict mode
> Strict mode ambiguities
> isArray(arguments)
> Statement grammar
> Webfoot
> [[class]] "function" bind
> Some of the "Strict Mode Restrictions" paragraphs are normative  
> (  Some are informative (  We need to  
> clearly distinguish the two.
> The Kona draft doesn't match Allen's draft for the statement  
> grammar and the strict mode restrictions on var.
> Agreed that 12.1.1 is gone.  Agreed that there are no strict mode  
> restrictions on var placement.
> Agreed to allow redundant var x declarations.
> Agreed that in strict mode we disallow name conflicts within the  
> same (hoisted) scope of:
> parameter vs. parameter
> parameter vs. var
> parameter vs. function
> function vs. var
> function vs. function
> These may be reported early, at the same time as syntax errors.   
> This will require adding cases to chapter 16.
> Agreed to lose the "fast" parameter of Object.keys and take out the  
> sort.  If an implementation defines a specific order for for-in  
> then Object.keys must return the same order.
>  sort is broken by getters that return inconsistent  
> values, setters, read-only properties, non-configurable properties  
> if there are holes, non-extensible objects, etc.  Agreed to fix  
> this somehow; it won't necessarily be easy.  Will also need to  
> verify that all of the other algorithms in chapter 15 still work in  
> the presence of getters, setters, read-only properties, non- 
> configurable properties, and non-extensible objects.
> Allen says that there is no conflict between the reflection API and  
> const.  We'll likely approach it in Harmony by not creating any  
> properties in the global object until the const is initialized.   
> All agreed to verify that const (as planned for Harmony) is not  
> broken by ES3.1.
> Reflection leakage:  For Harmony we'll look at ways to seal  
> abstraction leaks (interposing hidden levels in prototype  
> hierarchies of user-defined classes, etc.).
> Chapter 16: Extend list of errors that can be signalled early to  
> include some strict mode violations (duplicate parameter names, etc.).
> Chapter 8 and 10:  Get rid of hidden state that's implicit in the  
> algorithms but not exposed in the data structure.
> Introduce concepts before using them.
> Go through Waldemar's list of comments from before the meeting.
> bind behavior:  Should bind create only a call or both a call and a  
> construct bound property?  We decided to stick to last meeting's  
> decision of creating both a call and a construct bound property.   
> (If it were just call, then the argument for adding bind to the  
> language at all weakens since it would do duplicate what the  
> frameworks already do but perhaps slightly less compatibly.)
> Harmony hour:
> wiki:strawman:strawman
> - classes
> - const / let
> - decimal
> - lambda
> - lexical scope mode (pragma) vs. module {}
> - names
> - return to label
> - types
> - webfoot
> What is webfoot?  Performance optimization for Valija-like things.   
> Whitelisting flag, interceptors, catchalls?
> Repetitive discussion of names as an encapsulation mechanism.   
> Nothing that we hadn't resolved before.
> How is lambda useful except for code gemerators?  It's hazardous  
> because it's too easy to leak completion values that were not  
> intended to be returned.  Also it's hard to refactor lambdas if  
> it's not clear whether their return values are intentional or  
> accidental.
> classes:
> (class and instance) * (const and mutable variables, methods, and  
> getters/setters) * (public and private) + constructor?
> instance private vs. class private
> class private would require a different syntax for accessing the  
> private value "length" vs. the length of some unrelated object that  
> was passed in in an argument.
> March meeting moved from Washington DC to the bay area.
> Pre-meeting comments (amended):
> Overall:  With "const" missing, the changes to chapter 8 for  
> attribute description become premature standardization and should  
> be cut.  The problem is that these changes are likely to be  
> incompatible with ES-Harmony due to the same logic that cut  
> "const".  Without "const" we have no way of testing this, and I  
> would not support issuing a standard only to have to say "oops" a  
> few months later.  [rescinded after receiving assurances of const  
> compatibility at meeting]
> 5.2:  "step my specify"
> 7.1:  "format control characters may be used in identifiers, ...":   
> No they can't, according to section 7.6.
> 7.3:  "except that line terminators that are preceded by an escape  
> sequence may occur":  "preceded" is not thw right meaning here.   
> "part of"?
> 7.3:  The production
>  LineTerminator :: ... | <CR> | <CR><LF>
> is ambiguous.  Probably the simplest fix is to change it to:
>  LineTerminator :: ... | <CR> [lookahead isn't <LF>] | <CR><LF>
> Even then having <CR><LF> there causes trouble for things like its  
> use in,, and  It's not clear what  
> we want there.
> 7.5:  Token :: ReservedWord | Identifier | IdentifierName doesn't  
> make sense
> 7.8.3:  The MV of NumericLiteral :: DecimalLiteral m is not defined.
> 7.8.3:  This states that decimal literals may be rounded to 20  
> significant digits.  Is that what we want?
> 7.8.4:  "All Unicode characters may appear literally in a string  
> literal except for the closing quote character, backslash, carriage  
> return, and line feed. Any character may appear in the form of an  
> escape sequence.":  This is wrong about the other line terminators.
> 8:  Can Property Descriptors and Property Identifiers be stored as  
> user-visible properties of objects?  The last sentence seems to  
> imply that they can.
> 8.5:  "The Decimal type has exactly 10^34*12288+3 values".  I don't  
> think this is correct.  How did you arrive at this figure?
> There are not ten times as many denormalized Decimal values as  
> there are normalized Decimal values.  All of the Decimal number  
> counts in this section appear suspect.
> Why do we need to distinguish Decimal denorms anyway?  The concept  
> is not used anywhere in the document.
> Fix grammar and spelling errors.
> 8.6.1:  "change the property to being an" => "change the property  
> to be an"
> "operator in section 11.4.1, and the":  remove comma.
> 8.6.2:  ThrowablePut is optional?
> "The value of the [[Class]] property of a host object may be any  
> value":  Do you mean any string?
>  "explicit control over the handling of invalid property  
> store":  Do you really mean "store" here?  I think "stores" makes  
> more sense.
>  "if O is a String object it has":  add "then" before "it".
>  Add comma before "the following steps".
> 8.10:  The nomenclature is too inconsistent for me to be able to  
> readily make sense out of this at this time.  Sometimes you refer  
> to property descriptor properties as "writable" (as in "{value: 42,  
> writable: false, configurable: true}", and sometimes as  
> "[[Writable]]" (as in "Desc.[[Writable]]" in 8.10.2).  Therefore  
> these are two different things just as x.prototype and x. 
> [[Prototype]] are different?
> Also, Desc.[[Writable]] doesn't make sense because there is no such  
> internal property listed in the table of all internal properties  
> used in this specification in 8.6.2.
> The big problem that must be addressed and which I've mentioned  
> several times before is that the data types from 8.10 are used in  
> earlier sections of chapter 8 before they are defined here.  I  
> can't figure out which order to read this chapter in, as text from  
> 8.10 subtly modifies the interpretation of 8.6.2.  Solving this  
> problem by moving this content to or near 8.6.2 would help solve  
> the others as well.
> Can a Property Descriptor include both [[setter]] and [[value]]  
> fields?  8.10 is ambiguous on that.
> "(name, descriptor), where name is a string and descriptor ":   
> italicize "name" and "descriptor".
> 8.10.4:  "the following steps are taken:, the following steps are  
> taken:"
> The Note here should be a normative part of the preamble.   
> Otherwise step 4 doesn't make sense.
> Be consistent about italicization of Desc.
> 8.10.5:  Call the formal parameter something other than "Desc"  
> here.  It's confusing to use the same name for both objects and  
> property descriptors.
> 9:  Decimal support broken in most of the tables.
> 9.3:  ToDecimal on a Number gives the Number unchanged?
> ToNumber on a Decimal is not defined.
> 9.8:  ToString on a Decimal is not defined in the table.
> The algorithm only works on Number values.  +0, -0, etc. are Number  
> values, not Decimal values.  Also, it internally references  
> conversions to Numbers.
> 9.3.1:  ToDecimal on a string results in a Number.  Also, it  
> optionally drops significant digits after the 20th.
> 10.2:  "functrions"
> 10.2.1:  "binding can not be set throw a TypeError exception":   
> Missing comma.
>  "a ECMAScrpt":  a -> an and fix spelling error
> "A declarative environment record binding the set of identifiers  
> defined by the declarations contained within its scope.":  Not a  
> sentence.
>  Be consistent about spaces before the opening  
> parenthesis of formal parameters.
>  "The S argument is ignored because stict mode deoes  
> not change the meaning of setting bindings in declarative  
> environment records have .":  Ah, that's what "S" is for?  You  
> didn't explain this earlier when S was first mentioned in the other  
> methods.  Also, fix grammar errors.
>  Same comments as above.  Also lots of typos in various  
> places.
>  This will mean that having bindings in the prototype  
> will prevent one from building ones in the leaf object.
>  "of itÕs associated ":  it's -> its
> "4. If Result(3) is false or the binding for N in Result(1) is an  
> uninitialized immutable binding, then":  What's an uninitialized  
> immutable binding here?  Result(3) is an object, not an  
> environment.  Objects have properties, not bindings.
>  This will always error out in DefineOwnProperty.
>  "3. If the binding for N in Result(1) is a mutable  
> binding, then":  What is a mutable binding?  Result(1) is an  
> object, not an environment.
> "4. Else this must be an attempt to change the value of an  
> immutable binding so throw a TypeError exception.":  This doesn't  
> follow.  For example, just because Result(1) has no binding doesn't  
> mean that its prototype doesn't.
>  "called with a lexical environment lex, identifier  
> string, name, and boolan flag strict the following steps are  
> performed":  Due to several grammar errors (an extra comma and a  
> missing one) this doesn't mean what it's supposed to.
> 10.2.2.x:  "is call" -> "is called".  Lots of other typos as well.
>  There is no current lexical environment bound around the  
> declaration of PopEnvironnmentRecord.
> 10.3:  "to tract the execution"
> What is VariableEnvironment for?  It's never used in the spec,  
> except for a mention in 12.2 which is a bug and shouldn't be there.
> 10.3.2:  Can't do the arguments object this way.  It's incompatible  
> with ES3 for multiple arguments sharing the same name.  You also  
> don't want users extracting the getters and setters out of the  
> arguments array, etc.  Also, the notion of scope in which the  
> getters and setters are eval'd is fuzzy at best and can cause  
> problems if other definitions ever shadow the parameter names.
> 10.3.3:  "Variables and functions declared in ECMAScript code  
> evaluate in the execution context are added as bindings in the that  
> environment record."  Huh?
> "1. Let env be the running execution contextÕs  
> VariableEnvironment."  How do those get created?  Section 10.4  
> should come first.
> 10.4:  This is still confusing.  What creates execution contexts?   
> There is no such step in the algorithms here.
> 11.1.5:  This means that I can override a getter with a value  
> property or specify two getters for the same property even in  
> strict mode.  We had agreed that strict mode disallowed such things.
> 11.2.1:  "where <identifier-name-string> is a string literal  
> containing the same sequence of characters as the  
> IdentifierName.":  The meaning is ambiguous in the presence of  
> escape codes.
> 11.3.1, 11.3.2:  All four of the return statemets are wrong in  
> different ways.  Some return the preincremented value.  Some return  
> an lvalue instead of an rvalue.
> 11.5:  What's the corresponding Decimal operation?  There are a  
> bunch of different remainder options.
> 11.8.5:  You're treating Unicode character codes as Decimal  
> numbers.  Which characters have Unicode numbers that are Numbers,  
> and which ones have Unicode numbers that are Decimals?
> If you fix this and apply the same contagion rules as for +, -, *,  
> etc., then you'll have the issue that 1e-400m > 0m but 1e-400m > 0  
> is false.  The contagion rules need rethinking.
> 11.9.3:  The contagion here is from Number to Decimal.  This is  
> inconsistent with +, -, *, etc., where the contagion is from  
> Decimal to Number.  It should be the same for all arithmetic  
> operations.
> 11.9.6:  Don't need to call ToDecimal on values that are already  
> Decimals.
>  The strict mode restrictions are ambiguous.  What  
> happens in this case, where g does not exist?
> g = (function(){throw "foo"})();
> What about this?
> g = eval("var g = 5; 2");
> 12:  We agreed that functions defined within blocks are scoped  
> locally.
> 12:  Not allowing 12.2:  This breaks ES3 and existing practice.   
> Consider with(o) {var x = 3} if o.x exists and has the value 7.   
> This code currently sets o.x to 3; the proposed change would leave  
> it at 7.
> 13:  "code code"
> 14:  The syntax of the use strict directive is incompatible with  
> the lexer grammar.  There is no such separate token.  What happens  
> if someone escapes a character within the use strict directive  
> token?  The spaces before "use" and at the end are mandatory?  Is  
> it mandatory that the semicolon follow without an intervening  
> space?  How does the semicolon interact with semicolon insertion?
> Strict directives are ambiguous with statements.
> There should be no "opt" after UseStrictDirective's definition.
>  sort is broken by getters that return , setters, read- 
> only properties, non-configurable properties if there are holes,  
> non-extensible objects, etc.
> _______________________________________________
> Es-discuss mailing list
> Es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

More information about the Es-discuss mailing list