Hi,
I've read pretty thoroughly through rev 6 of the spec (offline, with a
pen and a printed spec) and seem to have written down at least
something on pretty much every page.
It'll take me some time to put it all together digitally, but here are
some high level comments (in no particular order):
- String as code point values is not consistently propagated yet
- Would suggest to go a step beyond the code point value and leave out
unicode where not absolutely required (will explain in followup mail)
- The double point unicode characters (and the \u{x*} extension) smell
a lot like the "mb_" mess php left when moving to utf (not sure
whether this could be solved easily though)
- Completion reform has the same problem of inconsistently being
propagated in "old" parts of the spec, i dont think all return values
are properly handled yet
- typeof null still object (personal disappointment :)
- Make undefined, NaN, and Infinity a literal (I don't see what issues
that might cause, please tell me if any); they're locked down anyways
- Many inconsistencies (different ways of doing the same thing in
algorithms, explaining things, and even the grammar)
- Quite a bit of duplication that could be prevented
- The term "exotic" does not seem fitting to this spec, but even if
that bikeshed is not reverted; "host" and "native" have still _many_
occurrences
- Likewise for "character" (also inconsistently replaced with one of
"code point", "code point value", "element", and "code unit")
- Missing some of the interesting parts I was looking forward to
reading specced (WeakMaps, Proxies, etc)
- I think many of the built-in functions and methods could do with a
short description (more than "<func>, when called, does this algo:")
- Many, many of the algorithms, notes, and rules could do with one or
more examples and the rationale behind them.
- The new way of doing "static semantics" are really annoying to read
(especially offline) when split up like this
- When referring to certain abstract (-like) functions, like static
semantics, it's really hard to detect this while reading (example:
contains), style issue
- Large chunk of the parsing theory seems to be irrelevant (spec would
be useful even without it)
- The new additions seem to take a few shortcuts wrt the grammar.
Especially "re-parsing" rules look a bit weird over just one grammar
- Making new parts of the spec (modules, using let, using const, etc)
"auto strict mode" is really disappointing and will confuse users, new
and experienced
I'm sure there's one or two more. So I've got two questions before I
start digitization of my notes...
1: For what kind of audience does the TC39/ECMA target this spec? To name a few:
- Academics (proofs, formalization, background theory)
- Implementors (edge casing, exact algorithms, no need for formal
proof or background theory)
- Advanced coders wanting to jump to the next level (how does it work,
rationales, examples)
- Coders wanting to learn (ok, probably not)
I think it's either 1, 2, or both. But while reading the spec I could
not really get a good feeling and it seems to be a mix between the
first, second, and maybe even the third type. An answer to this
question helps me to determine which items I might ignore :)
2: How would you like me to do this?
I can write a single email to this list for every (bigger) issue I
found, but I don't want to spam the list. A single email will make
individual points get lost in messy comments very fast though. I could
add every point to a github-gist for people to comment on, but that
would require a github account for people to comment there (not sure
how big of an issue this is). I could go through the list with
somebody to filter out the smaller points, through irc or skype? Could
make typo-part quicker to do. Please let me know :)
Learned a few new things while reading the spec (including some things
I think I actually missed/forgot while reading the es5 spec a few
years ago), so it's not been in vain regardless :)
Cheers,
- peter
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
