Ecmaspeak (was: `String.prototype.symbolAt()`)

[C. Scott Ananian]

On Feb 15, 2014 9:47 AM, "Brendan Eich"  wrote:
> 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.

Tooling could help. I've filed a number of minor bugs against the draft
spec about undefined identifiers, unused variables, etc.  In theory at
least those issues could be automatically linted.

It's tempting to say that at some point JS should be defined in terms of
"core JS", a strongly typed (!) subset of the language. (Strongly typed
because verification is the point. Alternatively you could just make an
executable test suite normative...)

FWIW I did a decent amount of work writing a JS runtime in "TurtleScript",
a differently-minded JS subset. One could also write specs in/compile to
asm.js but that's probably swinging the pendulum too far (and exposing a
lot of unnecessary implementation). Ian Piumarta has done a lot of good
work on self-hosting languages which look very similar to a proto-JS.

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

I'm sure you mean ungood, which is plusgood goodthinkful.

>> 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.

The original text under review here was discussing an optimization of the
String.at polyfill, so performance was indeed the point.
  --scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

[Allen Wirfs-Brock]

On Feb 15, 2014, at 11:47 AM, Brendan Eich wrote:

> C. Scott Ananian wrote:
>> 
>> On Feb 15, 2014 9:13 AM, "Brendan Eich" > > 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.

But remember, prior to ES5, it was closer to Cobolish machine language.  No 
structured control, goto's targeting numeric step numbers, intermediate results 
referenced by step number (sorta  SSA with numeric ids), etc.

There has never been a complete redo, just incremental improvements and 
refactorings. But we've definitely advanced from the early 1950s to the late 
1970s.  

Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

[Brendan Eich]

C. Scott Ananian wrote:


On Feb 15, 2014 9:13 AM, "Brendan Eich" > 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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

[C. Scott Ananian]

On Feb 15, 2014 9:13 AM, "Brendan Eich"  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"?

>> 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.
  --scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

[Mathias Bynens]

On 14 Feb 2014, at 19:59, Allen Wirfs-Brock  wrote:

> It's a really high bar to get over that closed gate.  Unless the exclusion of 
> a feature was a mistake […] I don't think we should be talking about adding 
> it to ES6.

It does feel like a mistake to me to introduce `String.prototype.codePointAt`, 
but no similar function that returns the symbol instead.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

[Brendan Eich]

Aside: "ECMASpeak" is neither accurate (we don't work for Ecma, it's JS 
not ES :-P), nor euphonious. But here's a pointer:



C. Scott Ananian wrote:

new string object.


"new string primitive", because "string object" (especially with "new" 
in front) suggests new String('hi').


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promise.cast and Promise.resolve

[Anne van Kesteren]

On Fri, Feb 14, 2014 at 10:50 PM, C. Scott Ananian
 wrote:
> Since both Chrome and FIrefox have plans to support Promises, feel
> free to suggest any changes to `es6-shim` which would improve
> compatibility.  It looks like that at the moment the `es6-shim`
> implementation is more spec-compliant than either of the shipping
> implementations?  In particular, we support subclasses.

It will take a long time before browsers support subclassing in
general as far as I can tell.


-- 
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss