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.

-Graydon

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.

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.