3 ms·
Great examples, thanks!! I typed them all into the TypeScript playground. I agree this is weird, and seems to follow from TypeScript's heritage as "trying to
by chubot 3y ago
Great examples, thanks!! I typed them all into the TypeScript playground.
I agree this is weird, and seems to follow from TypeScript's heritage as "trying to describe whatever dynamic JS does"
I mean that's probably why I didn't use it for >10 years (in addition to its JS heritage). But I did find that there is an interesting subset, at least for playing around.
I think the JSON.parse() issue is fundamental -- it's not clear what they could have done better, and static languages don't really do better. There is a fundamental problem there -- type systems are interior to a process, while data is exterior (https://www.oilshell.org/blog/2023/06/ysh-design.html https://www.oilshell.org/blog/2023/06/ysh-design.html)
I'm going to read this static TypeScript paper -- https://www.microsoft.com/en-us/research/publication/static-typescript/ https://www.microsoft.com/en-us/research/publication/static-... Hopefully that's a sound subset :)
- deleted 3y ago[deleted]
- consilient 3y ago> I think the JSON.parse() issue is fundamental -- it's not clear what they could have done better, and static languages don't really do better. The best solution, IMO, is to give up on "no type-directed emit" (which harms the language in lots of other ways as well) and derive appropriate parsers at compile-time. Parsing malformed data should fail immediately, not just when you try to use the broken parts. This is a solved problem in C#, C++, Haskell, and no doubt many other languages. Failing that, it should return an appropriate `JSON` type. Something along the lines of type Field = string | number | boolean | null | JSON type JSON = {[key in string]?: Field } | Field[]