3 ms·

Fun fact, E4X is the reason JavaScript has ‘for(of)’ instead of ‘for each’ (the reason we didn’t get ‘for (:)’ is even dumber - it would conflict with ‘:type’ a

by olliej 2y ago

Fun fact, E4X is the reason JavaScript has ‘for(of)’ instead of ‘for each’ (the reason we didn’t get ‘for (:)’ is even dumber - it would conflict with ‘:type’ annotations a few TC39 members were convinced would magically be in the language)

rlt 2y ago
Like the type annotations that are now in TypeScript?
- olliej 2y ago
  Yup, that were in typescript, pascal (and rust, etc when they came out). But there was no real progress after years of them pushing this syntax, but failing to actually define a type system that was coherent, or a model that would allow it. As a result I proposed `for (of)` largely to prevent sane enumeration from being blocked on the intransigence of two people. It's also worth noting that for(:) enumeration would not even preclude their syntax - it's certainly not grammatically ambiguous - and most real world code in languages that support enumeration directly and support inference doesn't explicitly specify the types , so the ugliness of `for(let a:type:expression)` would have be rare anyway. shrug Given that ECMA literally killed E4X a few years later the blanket ban on "for each" or "foreach" (because it would be "confusing" in E4X) is arguably worth than for(:), but again shrug
IshKebab 2y ago
There is a proposal to add them, though it does seem to be stalled.
- olliej 2y ago
  There were proposals almost 2 decades ago. They've never gone anywhere because proponents of type specifiers don't want to do the necessary corollary: specifying the type system. Typescript and similar can do it because they don't have to specify the type system, and can't change it in meaningful ways over time. Things in the language standard cannot be easily changed, if they can be changed at all.
  - IshKebab 2y ago
    > the necessary corollary: specifying the type system. It's clearly not strictly necessary though. Python has shown that. I mean I agree it is pretty mad to just say "you can write types but they mean whatever" but surprisingly in practice it seems to work ok.
    - olliej 2y ago
      It is necessary if you’re creating a standard. The Python implementation can do whatever it wants because “Python” does not mean “The Python Language Specification”. It means the one specific implementation, and whatever that impl does is definitionally correct. The ability for a language specification does to hand wave behaviour is very limited, and for JS is non existent (the only places where there is divergence between implementations is some squirrely edge cases of property and prototype chain mutation during for(in) enumeration). So you can’t say “types mean whatever”, you have to specify what the implementation is required to do when it encounters those annotations. Even if they are not meant to have any semantic impact the lack of semantic impact must be specified: e.g the language specification would be required to state “here is the valid grammar for these annotations”, and specify that they are explicitly ignored and must not be evaluated or examined in any way.
      - IshKebab 2y ago
        > The Python implementation can do whatever it wants No you're misunderstanding how it works in Python. This isn't like Rust where "the implementation is the specification". The Python type checking standards explicitly don't define semantics (though I think they give guidelines). The standard Python implementation - CPython - does not include a static type checker. There is no "official" implementation. In fact there are at least 4 Python static type checkers and they are all third party projects and they do differ in interpretation of types sometimes. The most popular ones by far are Mypy and Pyright (and Pyright is the far superior option). So it is exactly the same as what is proposed for JavaScript. It definitely sounds mad and I do agree that it would be better if they just actually specified semantics, but not bothering isn't the complete disaster you might imagine.

by olliej 2y ago

rlt 2y ago

Like the type annotations that are now in TypeScript?

olliej 2y ago
Yup, that were in typescript, pascal (and rust, etc when they came out). But there was no real progress after years of them pushing this syntax, but failing to actually define a type system that was coherent, or a model that would allow it. As a result I proposed `for (of)` largely to prevent sane enumeration from being blocked on the intransigence of two people. It's also worth noting that for(:) enumeration would not even preclude their syntax - it's certainly not grammatically ambiguous - and most real world code in languages that support enumeration directly and support inference doesn't explicitly specify the types , so the ugliness of `for(let a:type:expression)` would have be rare anyway. shrug Given that ECMA literally killed E4X a few years later the blanket ban on "for each" or "foreach" (because it would be "confusing" in E4X) is arguably worth than for(:), but again shrug

IshKebab 2y ago

There is a proposal to add them, though it does seem to be stalled.

olliej 2y ago
There were proposals almost 2 decades ago. They've never gone anywhere because proponents of type specifiers don't want to do the necessary corollary: specifying the type system. Typescript and similar can do it because they don't have to specify the type system, and can't change it in meaningful ways over time. Things in the language standard cannot be easily changed, if they can be changed at all.
- IshKebab 2y ago
  > the necessary corollary: specifying the type system. It's clearly not strictly necessary though. Python has shown that. I mean I agree it is pretty mad to just say "you can write types but they mean whatever" but surprisingly in practice it seems to work ok.
  - olliej 2y ago
    It is necessary if you’re creating a standard. The Python implementation can do whatever it wants because “Python” does not mean “The Python Language Specification”. It means the one specific implementation, and whatever that impl does is definitionally correct. The ability for a language specification does to hand wave behaviour is very limited, and for JS is non existent (the only places where there is divergence between implementations is some squirrely edge cases of property and prototype chain mutation during for(in) enumeration). So you can’t say “types mean whatever”, you have to specify what the implementation is required to do when it encounters those annotations. Even if they are not meant to have any semantic impact the lack of semantic impact must be specified: e.g the language specification would be required to state “here is the valid grammar for these annotations”, and specify that they are explicitly ignored and must not be evaluated or examined in any way.
    - IshKebab 2y ago
      > The Python implementation can do whatever it wants No you're misunderstanding how it works in Python. This isn't like Rust where "the implementation is the specification". The Python type checking standards explicitly don't define semantics (though I think they give guidelines). The standard Python implementation - CPython - does not include a static type checker. There is no "official" implementation. In fact there are at least 4 Python static type checkers and they are all third party projects and they do differ in interpretation of types sometimes. The most popular ones by far are Mypy and Pyright (and Pyright is the far superior option). So it is exactly the same as what is proposed for JavaScript. It definitely sounds mad and I do agree that it would be better if they just actually specified semantics, but not bothering isn't the complete disaster you might imagine.