| 03:08 | <littledan> | I think we would be better off with O(5) constructs, with the aim of not enabling avoiding all type /* */comment formats, rather than literally just parameters and return values. It sounds like you are open to this possibility, right? But I am also not yet sure if the whole thing should be reduced as much as bakkot suggests—we should talk more about overall motivation/usage modes in the next presentation. |
| 03:52 | <bakkot> | I'm open to that possibility. Also to be clear I didn't mean to suggest this would only cover parameters and return values - for example, let x = y ::as string; would be legal under my suggested grammar (assuming the :: comment form is allowed in the appropriate places). And I think that's better than having a separate as production even though that means you can't use TypeScript casts as they're written today. |
| 04:40 | <Jack Works> | /// interface X { /// either(x: this): this /// } /// <T extends X>(i: T, j: T): T function f(i, j) { let next = i.either(j) /// T return next } |
| 06:45 | <littledan> | One issue with magic comments is that it’s unclear how tools should handle errors—was that comment just a comment? |
| 06:47 | <littledan> | I remember having a thought about :: being problematic grammatically, but I can’t remember what the problem was… |
| 06:48 | <littledan> | The main reason I am a little hesitant about that particular grammar is that some things will want to take an argument and some won’t. This is the kind of thing to work out case-by-case when developing encodings of type systems into JS grammar |
| 07:30 | <bakkot> | Uhhh yeah I guess it would be something like :: [nlth] (.? IdentifierName [nlth])+ MatchedBraces? plus also :: MatchedBraces |
| 07:31 | <bakkot> | And yes this still has the FunctionBody ambiguity |
| 07:37 | <littledan> | yeah this seems like it'd have ambiguities about when it ends but I understand what you're getting at. |
| 07:37 | <littledan> | Anyway I'm not sure we should give up on the "easy transition from existing type systems" goal because, if migration to a minimal grammar is difficult or the grammar is seen as ugly, then the ecosystem may be split. |