| 00:00 | <ljharb> | bakkot: Foo (a, b): ThrowCompletion | NormalCompletion(x)? |
| 00:01 | <bakkot> | it might be return or break also, sometimes |
| 00:01 | <bakkot> | Also we don't use the | notation currently, we just say "or" |
| 00:01 | <ljharb> | sure, "or" then |
| 00:01 | <bakkot> | so some form of prose would be ideal |
| 00:01 | <ljharb> | hm |
| 00:02 | <ljharb> | but like, "normally containing X" doesn't cover all the alternatives either |
| 00:02 | <ljharb> | but it sounds like what you want is "a completion of type normal, containing X, or a completion of another type"? (that isn't a real suggestion, too wordy) |
| 00:02 | <bakkot> | that is what it means, yeah |
| 00:02 | <bakkot> | that's how I read "normally containing X" |
| 00:03 | <ljharb> | to me "normally" implies "but sometimes it doesn't" |
| 00:03 | <bakkot> | like, in the normal case, it contains an X; in the non-normal case, all we are saying is that it is a completion record |
| 00:03 | <bakkot> | right, sometimes it doesn't |
| 00:03 | <ljharb> | lol |
| 00:03 | <bakkot> | sometimes it's abrupt rather than normal |
| 00:03 | <ljharb> | but i mean it doesn't speak to the [[Type]] |
| 00:03 | <ljharb> | the enum value "normal" in there is not connected to the english word "normally" for me |
| 00:03 | <bakkot> | they're... the same word? |
| 00:03 | <ljharb> | lol i know, but conceptually it reads weird to me |
| 00:03 | <bakkot> | fair |
| 00:04 | <bakkot> | I have no better alternative though |
| 00:04 | <ljharb> | let me think about it, obv if i can't come up with a workable alternative then there's no reason to block on that |
| 00:04 | <bakkot> | √ |
| 00:08 | <Michael Ficarra> | "an abrupt completion or a normal completion containing X" works |
| 00:08 | <Michael Ficarra> | allows us to refine it in other ways as well |
| 00:08 | <Michael Ficarra> | we type some AOs as "a throw completion" or "an abrupt completion" already anyway |
| 00:09 | <bakkot> | that's pretty wordy still... |
| 00:09 | <Michael Ficarra> | it's a little bit of work to change to that, but nothing unmanageable |
| 00:09 | <Michael Ficarra> | it's a little wordy, but it's a union |
| 00:09 | <Michael Ficarra> | what do you expect |
| 00:11 | <bakkot> | i expect an alias for the union which is shorter :P |
| 00:12 | <bakkot> | like "a completion record normally containing" |
| 00:12 | <Michael Ficarra> | I'm gonna stick with that for now |
| 00:14 | <ljharb> | i still like Foo (a, b): ThrowCompletion | NormalCompletion(x), and we can make those AOs for break/continue/return if we need them |
| 00:15 | <bakkot> | ljharb: to be clear this is for the prose |
| 00:15 | <bakkot> | like in
|
| 00:15 | <bakkot> | the "and returns a List of byte values" part is the part we are discussing |
| 00:15 | <ljharb> | right, i'm still hoping we omit the prose and go with something in the h1 instead |
| 00:15 | <ljharb> | but i'll keep trying to think of something for the prose |
| 00:15 | <bakkot> | ah, we are not doing that as part of this PR, for sure |
| 00:16 | <bakkot> | we'll have a separate marker for "can return abruptly" in the H1, but we will not have the whole type |
| 00:55 | <shu> | bakkot: ah, okay |
| 01:50 | <jmdyck> | I think it's too easy to read "normally containing X" as meaning roughly "usually containing X" or "typically containing X". |
| 15:03 | <Michael Ficarra> | jmdyck: https://github.com/tc39/ecma262/pull/2547 is ready for review now |
| 15:03 | <Michael Ficarra> | happy to answer any questions about the editorial philosophy behind any of the changes |
| 15:03 | <Michael Ficarra> | I recommend reading the task list in the PR description before review |
| 15:07 | <Michael Ficarra> | FYI most of those things in the task list were checked with the assistance of ecmarkup |
| 15:08 | <Michael Ficarra> | bakkot will work on cleaning up the code and committing anything that can be reliably automatically checked to ecmarkup before we merge |
| 15:11 | <Michael Ficarra> | I think it's too easy to read "normally containing X" as meaning roughly "usually containing X" or "typically containing X". that's fair, but every usage will link to the definition, which says
|
| 17:28 | <jmdyck> | link to definition will help. |
| 17:28 | <jmdyck> | Thanks for the heads-up. |
| 17:28 | <jmdyck> | When do you hope to land it? |
| 17:58 | <Michael Ficarra> | as soon as we can, I guess |
| 17:58 | <Michael Ficarra> | I feel quite comfortable with the state of it, personally |
| 17:58 | <Michael Ficarra> | and since bakkot helped with the tooling-assisted confirmations, I'm sure he feels pretty comfortable with it too |
| 18:00 | <Michael Ficarra> | and I expect that landing the ecmarkup improvements will convince others that it's near enough to correct |
| 18:01 | <Michael Ficarra> | there is still room for errors to have crept in, of course |
| 18:01 | <Michael Ficarra> | a lot of the checks didn't apply to internal/concrete methods, for example |
| 18:01 | <Michael Ficarra> | and we don't actually track types through aliases or anything, so some types might not align |
| 18:02 | <Michael Ficarra> | but as far as how completion records are used, I feel good |
| 18:03 | <Michael Ficarra> | the remaining thing to review would be the various phrasing decisions or changes we've made, since that can be subjective |
| 18:56 | <jmdyck> | Okay, well I should be able to start looking at it (i.e, modifying ecmaspeak to handle+analyze it) this aft. |
| 19:05 | <Michael Ficarra> | awesome |
| 19:24 | <bakkot> | it's definitely not landing until next week at the earliest |
| 19:36 | <jmdyck> | okay, so I've got the weekend at least. :) |