C. Scott Ananian wrote:
>
> On Feb 15, 2014 9:13 AM, "Brendan Eich" <brendan at mozilla.com 
> <mailto:brendan at mozilla.com>> wrote:
> > Aside: "ECMASpeak" is neither accurate (we don't work for Ecma, it's 
> JS not ES :-P), nor euphonious.
>
> I'm learning all sorts of things! I guess there are two names here; 
> what's your preferred phrase for "the language used to write 
> algorithms in the ES6 spec" (JS6?), and, if it differs, "the language 
> used by members of the TC39 committee among themselves when describing 
> language primitives in a very precise way"?
>

When I'm in a bad mood, I call it VisualCobol. It's painfully low-level 
and verbose, yet hard to verify. Let's hope that the JSCert work will 
help, and Allen has been common'ing subroutines. Whatever we call it, 
the spec language ain't great.

Using "-Speak" as a stem conjures Orwell. Not good.

The definition of array-like -- an informal bit of jargon, useful (e.g., 
"array-like vs. iterable" in context in larger discussions about 
Array.from) until it's time to get precise -- is a spec matter. I agree 
we need a common definition that we use consistently.

> >> new string object.
> >
> > "new string primitive", because "string object" (especially with 
> "new" in front) suggests new String('hi').
>
> I wrestled with the phrasing there. I think what I really mean is 
> "avoid allocating new backing storage", since there are "new string 
> primitives" returned regardless.  If there's a better phrase for 
> "string backing storage" I'd be glad to add that to my dictionary.
>

What does "backing storage" mean? There are no new String objects in any 
event. There may be ropes or dependent strings under the hood, but 
that's all unobservable (apart from performance) implementation-land.

/be

C. Scott Ananian wrote:

> I'm learning all sorts of things! I guess there are two names here; 
> what's your preferred phrase for "the language used to write 
> algorithms in the ES6 spec" (JS6?), and, if it differs, "the language 
> used by members of the TC39 committee among themselves when describing 
> language primitives in a very precise way"?
>

When I'm in a bad mood, I call it VisualCobol. It's painfully low-level 
and verbose, yet hard to verify. Let's hope that the JSCert work will 
help, and Allen has been common'ing subroutines. Whatever we call it, 
the spec language ain't great.

Using "-Speak" as a stem conjures Orwell. Not good.

The definition of array-like -- an informal bit of jargon, useful (e.g., 
"array-like vs. iterable" in context in larger discussions about 
Array.from) until it's time to get precise -- is a spec matter. I agree 
we need a common definition that we use consistently.

> I wrestled with the phrasing there. I think what I really mean is 
> "avoid allocating new backing storage", since there are "new string 
> primitives" returned regardless.  If there's a better phrase for 
> "string backing storage" I'd be glad to add that to my dictionary.

What does "backing storage" mean? There are no new String objects in any 
event. There may be ropes or dependent strings under the hood, but 
that's all unobservable (apart from performance) implementation-land.