Graydon Hoare (2008-05-26T18:57:26.000Z)
forbes at lindesay.co.uk (2019-04-24T11:08:53.147Z)
Mark S. Miller wrote: > In going over the ES4 draft spec docs, I found the following things surprising: I can't answer all of these, but can a few. Most of the grammar questions are outside of things I know. > * I thought `like` was dead. How did it get revived? As a (`value * type`) binary operator, rather than as a type. It also (presently) has a form in which it can annotate a function parameter, which implicitly causes the an assertion of the operator against the provided type when the function is entered. This annotation behavior on function parameter lists is something I'm not terribly pleased with, but then, the most natural boundary between annotated and unannotated code appears to be that of a function call, so it's possibly sensible to leave extra conveniences there. > * What is > > "super" "(" Arguments ")" > > Last I heard, ES4 only has single implementation inheritance, so why > allow "super" to be qualified? I don't know what you mean by qualified. That's a form for either constructor-chaining or dispatching to a parent method with the same name as the current method. > * I'm pleasantly surprised to see that the prototype reference (which > I take to be the same as the ES3 internal [[Prototype]] property) is > said to be immutable. Does this mean that we will be able to consider > the following behavior buggy (I hope so): Yes. > * What namespace is `__ES4__` defined in? The text "The namespace > `__ES4__` is predefined. It is used to tag global names that have been > introduced in the 4th edition" would seem to indicate that `__ES4__` is > itself defined in the namespace `__ES4__`. I'm probably missing or > confused about something. Sorry about this. There was text in the section on names that clarified the root namespace bindings but it appears to have been cut during some rewriting. I'll try to ensure it shows up again. At the moment the ES4 namespace is visible as the global property `__ES4__` to 3rd edition code, because it is bound to the global name `""::__ES4__` and 3rd edition code has the transparent public namespace "" open in its root scope. This is the "backwards compatibility hazard" if some 3rd edition code happens to accidentally wish to reuse the global variable `__ES4__`. All other names introduced are qualified by the ES4 namespace, or by namespaces that are themselves qualified by the ES4 namespace (including things like the "public" synonym for the transparent public namespace; that's actually bound to `__ES4__::public`). So 3rd edition code is not going to collide with such names, since 3rd edition code is never going to contain a name expression `__ES4__::foo` that would be necessary to start digging around in that namespace. The ES4 namespace is open in the root scope of any 4th edition code. You're right that we could possibly get away with only binding the ES4 namespace to, essentially, `<ES4>::__ES4__`, where `<ES4>` is the opaque namespace object itself. We don't do that at present, but we've tried to keep any name pollution to a minimum so this might be a desirable final touch if we can make it work. > * Unicode only has 21 bits of significance. That's enough headroom > that we should expect Unicode to live within these limits until the > United Federation of Planets makes peace with the Romulans and the > Klingons. So why is a string value defined as "a finite ordered > sequence of zero or more 32 bit unsigned integer values"? Because a string value in the 3rd edition is defined as "a finite ordered sequence of zero or more 16 bit unsigned integer values". Emphatically *not* as a unicode string. Unicode strings are a useful subset of what a 3rd edition string value can hold, but they're not defined that way. In particular, the private surrogate range is totally fair game in 3rd edition implementations. The expansion to 32 bits is simply a matter of utility: it's much more useful in general to have a dense u32 sequence than a dense u21 sequence. > * What does "Rib" mean? Is it an acronym? Not an acronym. A rib is a (name -> fixture) binding map. It defines the set of fixed properties that will exist in a scope or an instance. There is some redundancy between ribs and non-value property states, in the present RI. I'm in the process of eliminating this redundancy in favour of relying on ribs directly, and using properties only to model what's now called the value state.
forbes at lindesay.co.uk (2019-04-24T11:06:41.432Z)
Mark S. Miller wrote: > In going over the ES4 draft spec docs, I found the following things surprising: I can't answer all of these, but can a few. Most of the grammar questions are outside of things I know. > * I thought "like" was dead. How did it get revived? As a (value * type) binary operator, rather than as a type. It also (presently) has a form in which it can annotate a function parameter, which implicitly causes the an assertion of the operator against the provided type when the function is entered. This annotation behavior on function parameter lists is something I'm not terribly pleased with, but then, the most natural boundary between annotated and unannotated code appears to be that of a function call, so it's possibly sensible to leave extra conveniences there. > * What is > > "super" "(" Arguments ")" > > Last I heard, ES4 only has single implementation inheritance, so why > allow "super" to be qualified? I don't know what you mean by qualified. That's a form for either constructor-chaining or dispatching to a parent method with the same name as the current method. > * I'm pleasantly surprised to see that the prototype reference (which > I take to be the same as the ES3 internal [[Prototype]] property) is > said to be immutable. Does this mean that we will be able to consider > the following behavior buggy (I hope so): Yes. > * What namespace is `__ES4__` defined in? The text "The namespace > `__ES4__` is predefined. It is used to tag global names that have been > introduced in the 4th edition" would seem to indicate that `__ES4__` is > itself defined in the namespace `__ES4__`. I'm probably missing or > confused about something. Sorry about this. There was text in the section on names that clarified the root namespace bindings but it appears to have been cut during some rewriting. I'll try to ensure it shows up again. At the moment the ES4 namespace is visible as the global property `__ES4__` to 3rd edition code, because it is bound to the global name `""::__ES4__` and 3rd edition code has the transparent public namespace "" open in its root scope. This is the "backwards compatibility hazard" if some 3rd edition code happens to accidentally wish to reuse the global variable `__ES4__`. All other names introduced are qualified by the ES4 namespace, or by namespaces that are themselves qualified by the ES4 namespace (including things like the "public" synonym for the transparent public namespace; that's actually bound to `__ES4__::public`). So 3rd edition code is not going to collide with such names, since 3rd edition code is never going to contain a name expression `__ES4__::foo` that would be necessary to start digging around in that namespace. The ES4 namespace is open in the root scope of any 4th edition code. You're right that we could possibly get away with only binding the ES4 namespace to, essentially, `<ES4>::__ES4__`, where `<ES4>` is the opaque namespace object itself. We don't do that at present, but we've tried to keep any name pollution to a minimum so this might be a desirable final touch if we can make it work. > * Unicode only has 21 bits of significance. That's enough headroom > that we should expect Unicode to live within these limits until the > United Federation of Planets makes peace with the Romulans and the > Klingons. So why is a string value defined as "a finite ordered > sequence of zero or more 32 bit unsigned integer values"? Because a string value in the 3rd edition is defined as "a finite ordered sequence of zero or more 16 bit unsigned integer values". Emphatically *not* as a unicode string. Unicode strings are a useful subset of what a 3rd edition string value can hold, but they're not defined that way. In particular, the private surrogate range is totally fair game in 3rd edition implementations. The expansion to 32 bits is simply a matter of utility: it's much more useful in general to have a dense u32 sequence than a dense u21 sequence. > * What does "Rib" mean? Is it an acronym? Not an acronym. A rib is a (name -> fixture) binding map. It defines the set of fixed properties that will exist in a scope or an instance. There is some redundancy between ribs and non-value property states, in the present RI. I'm in the process of eliminating this redundancy in favour of relying on ribs directly, and using properties only to model what's now called the value state.