| 20:54 | <Michael Ficarra> | @bakkot do you have an opinion on this? https://github.com/tc39/ecma262/issues/3370 |
| 21:40 | <bakkot> | lean negative. the prose becomes hard to read without knowing the types if we do that, I think |
| 21:44 | <shu> | wouldn't the return type of these expressions that have "is true" or "is false" elided always be Boolean? |
| 21:50 | <bakkot> | well, yes, but if you're reading an english sentence it's kind of weird to encounter something which would normally be a noun and instead it's being used as a condition |
| 21:55 | <shu> | not sure i follow |
| 21:56 | <shu> | the proposal is allow elisions where it reads naturally in english, not that "is true" and "is false" be systematically dropped everywhere |
| 22:00 | <jmdyck> | how would you systematically drop "is false"? |
| 22:01 | <jmdyck> | or un-systematically? |
| 22:02 | <jmdyck> | like, would you change X is false to it is not the case that X ? |
| 22:09 | <shu> | no, you just wouldn't change it |
| 22:10 | <jmdyck> | So ignore mentions of eliding "is false"? |
| 22:10 | <shu> | i want to type e.g. "If IsFoo(foo), then" instead of "If IsFoo(foo) is true, then" |
| 22:10 | <shu> | oh sorry, you were specifically talking about false |
| 22:10 | <jmdyck> | yes |
| 22:10 | <shu> | hmm that's a good point, i don't see a natural way to elide "is false" at the moment |
| 22:12 | <jmdyck> | I'm trying out eliding "is true", modifying my pseudocode grammar to handle the result, but I'm hitting some ambiguities. |
| 22:14 | <shu> | ooh fun, do tell |
| 22:17 | <jmdyck> | later; time for food |
| 22:20 | <bakkot> | the proposal is allow elisions where it reads naturally in english, not that "is true" and "is false" be systematically dropped everywhere |
| 22:20 | <bakkot> | conditions like "x is y" are not nouns |
| 22:21 | <bakkot> | so it cannot read naturally unless you stop seeing the AO invocation as an AO invocation and instead read it as words based on its name |
| 22:21 | <bakkot> | also michael did want to drop it everywhere it sounded like |
| 22:23 | <shu> | i also don't want to drop it everywhere i don't think |
| 23:39 | <Michael Ficarra> | yeah I don't see a reason not to drop it everywhere |
| 23:39 | <Michael Ficarra> | it can be easily explained |
| 23:44 | <jmdyck> | I made the ambiguities go away, but at the expense of misparsing at least one condition. |
| 23:47 | <jmdyck> | In IsLessThan, there's a step If _nx_ or _ny_ is *NaN*, return *undefined*., which required me (long ago) to add a production to my pseudocode grammar {CONDITION} : {var} or {var} is {LITERAL}. If I leave that production in, I get tons of ambiguities. If I take it out, no ambigs, but _nx_ or _ny_ is *NaN* is now parsed like (_nx_) or (_ny_ is *NaN*). |
| 23:51 | <jmdyck> | That one step has the only instance of that production in the whole spec, so if you rewrote the condition to _nx_ is *NaN* or _ny_ is *NaN*, I wouldn't need the production. |