| 00:01 | <jmdyck> | https://fenix.tecnico.ulisboa.pt/downloadFile/1689244997263330/ECMA_SL_Extended_Abstract.pdf is interesting: "Hence, we believe that the ECMAScript specification should be generated from a reference implementation of the language." |
| 00:05 | <jmdyck> | Mind you, they're (apparently) writing in 2021 about ES 5.1, which is odd. |
| 00:30 | <bakkot> | my undergrad research back in ~2014 was against ES3 |
| 00:30 | <bakkot> | it's just a lot easier to use old versions |
| 00:30 | <bakkot> | new versions are... larger |
| 00:34 | <Michael Ficarra> | as an editor, I would prefer to maintain spec text and derive reference implementations for the purposes of automatically checking the spec, not the other way around |
| 01:54 | <jmdyck> | Given that people will read the text, it does seem that maintaining the text and deriving an implementation is safer than the reverse. With the reverse, you'd presumably have to generate the text as part of CI, and then diff that against the previous text, so more stuff to check. |
| 02:14 | <jmdyck> | And if you can derive a reference impl from the text, then you get benefits 2-4 anyway. Benefit 1 ("Writing code is easier than writing HTML pseudo-code following the conventions of the standard.") is a weird thing to say because ES 5.1 was written in MS Word. In the current regime, I'm not sure which would be easier. Writing code might be more satisfying, because you could (at least sometimes) get into a quick feedback loop. |
| 15:47 | <shu> | well also, like, our spec isn't 100% executable |
| 15:47 | <shu> | re: liveness and memory model |
| 18:34 | <shu> | git question time, how do i cherry-pick the commit from a PR into my local branch? |
| 18:37 | <ljharb> | git cherry-pick X where X is any commit-ish |
| 18:37 | <ljharb> | the short or long sha, eg |
| 18:37 | <shu> | no i mean |
| 18:38 | <shu> | how do i find that sha |
| 18:38 | <shu> | like what repo and branch i need to fetch to get that sha |
| 18:40 | <ljharb> | oh - you can get it from the PR webpage most easily |
| 18:41 | <shu> | ah okay |
| 18:41 | <ljharb> | to get it on the CLI you have to fetch the PR ref specifically, which i'd need a minute to craft the command for |
| 18:41 | <shu> | ah no need, i'll try to find it on web page |
| 18:41 | <ljharb> | cool |
| 18:47 | <shu> | thanks |
| 18:47 | <shu> | bakkot Michael Ficarra i've cherry-picked michael's commit and added my wording tweaks on top to https://github.com/tc39/ecma262/pull/2777 |
| 18:47 | <shu> | PTAL |
| 18:47 | <shu> | it should be the agreed-upon state |
| 19:46 | <shu> | And if you can derive a reference impl from the text, then you get benefits 2-4 anyway. Benefit 1 ("Writing code is easier than writing HTML pseudo-code following the conventions of the standard.") is a weird thing to say because ES 5.1 was written in MS Word. In the current regime, I'm not sure which would be easier. Writing code might be more satisfying, because you could (at least sometimes) get into a quick feedback loop. |
| 19:47 | <shu> | i can guarantee you what will happen with a reference interpreter as the source of truth is that, implementations will more than likely converge on whatever the reference implementation does for new proposals, down to bug compat |
| 19:48 | <shu> | because our spec drafts aren't executable, there's more doubt cast on the correctness of it by implementers when something doesn't smell right |
| 19:48 | <shu> | vs what i contend will happen in a reference-implementation-first world, which is "well this sure seems like a weird design but the reference implementation already does this so it must be intentional, i'll just copy that" |
| 19:49 | <shu> | and because we have multiple interoperable implementations, there're more chances for doubt to be cast, which i feel like raises the quality bar |
| 19:49 | <shu> | at the expense of small set of people being annoyed, of course, but that seems fine |
| 19:49 | <ljharb> | i think that's how ruby's tended to work (as shu described, i mean) |
| 19:50 | <bakkot> | python too |
| 19:50 | <shu> | oh yeah? there're multiple ruby implementations? i didn't know |
| 19:50 | <shu> | i know for python there's the JIT forks |
| 19:51 | <shu> | like pypy and whatnot |
| 20:01 | <Michael Ficarra> | yeah, at least back in the day jruby (a JVM impl) was a big deal |
| 20:01 | <Michael Ficarra> | but the reference implementation was in C |
| 20:08 | <shu> | Michael Ficarra: for https://github.com/tc39/ecma262/pull/2777#pullrequestreview-1346560131 do you prefer the singular everywhere? |
| 20:22 | <Michael Ficarra> | I'm not an expert in English grammar, but to me "use as" is always followed by a singular form |
| 20:22 | <Michael Ficarra> | but like I don't know if that's an actual English grammar rule or if that just sounds natural to me because I've heard it used incorrectly? |
| 20:22 | <Michael Ficarra> | I dunno |
| 20:23 | <Michael Ficarra> | it's like "these tools are not suitable for use as a hammer", which sounds better to me than if it was pluralised |
| 20:24 | <ljharb> | "these tools are not suitable for use as hammers" is also perfectly correct afaict |
| 20:24 | <shu> | it's like "these tools are not suitable for use as a hammer", which sounds better to me than if it was pluralised |
| 20:25 | <shu> | i don't know if there's a rule here either |
| 20:26 | <Michael Ficarra> | I read it as "use as a hammer" is the thing they're unsuitable for |
| 20:26 | <Michael Ficarra> | and "use as hammers" is not a thing |
| 20:26 | <Michael Ficarra> | anyway, it's not a big deal, the thing I was really trying to get at was consistency in phrasing |
| 20:27 | <Michael Ficarra> | as long as it's the same everywhere, it's fine |
| 20:27 | <shu> | i think then i will make everything singular |
| 20:28 | <shu> | that sounds better than mixed and avoids the question |
| 20:28 | <shu> | i.e. "a value" instead of "values" |
| 20:35 | <Michael Ficarra> | "value" still needs to correspond to "is" though |
| 20:35 | <Michael Ficarra> | in that last sentence |
| 20:36 | <Michael Ficarra> | and we still need to drop the curly quotes because eww |
| 20:38 | <shu> | yeah sure, i'll apply the rest of your suggestions |
| 21:54 | <ljharb> | psh, only curly quotes are typographically correct in prose |
| 21:57 | <shu> | ,,x'' |