3 ms·

Ecmascript 4 was an attempt to add better types to the language, which sadly failed a long time ago. It'd be nice of TS at least allowed for specifying types l

Ecmascript 4 was an attempt to add better types to the language, which sadly failed a long time ago. It'd be nice of TS at least allowed for specifying types like integer, allowing some of the newer TS aware runtimes could take advantage of the additional info, even if the main TS->JS compilation just treated `const val: int` the same as `const val: number`. I wonder if a syntax like const counter: Number<int> would be acceptable.

THBC 2y ago
Number is not semantically compatible with raw 64-bit integer, so you might as well wish for a native const counter = UInt64(42); The current state of the art is const counter = BigInt.asUintN(64, 42);
obviouslynotme 2y ago
Yeah, that is why I said TS (or something similar). TS made some decisions that make sense at the time, but do not help compilation. The complexity of its typing system is another problem. I'm pretty sure that it is Turing-complete. That doesn't remove feasibility, but it increases the complexity of compiling it by a whole lot. When you add onto this the fact that "the compiler is the spec," you really get bogged down. It would be much easier to recognize a sensible subset of TS. You could probably even have the type checker throw a WTFisThisGuyDoing flag and just immediately downgrade it to an any.
- com2kid 2y ago
  > I'm pretty sure that it is Turing-complete. Because JS code can arbitrarily modify a type, any language trying to specify what the outputs of a function can be also has to be Turing complete. There are of course still plenty of types that TS doesn't bother trying to model, but it does try to cover even funny cases like field names going from kebab-case to camelCase.
the_imp 2y ago
With Extractors [1] (currently at Stage 1), you could define something like this to work: const Integer = { [Symbol.customMatcher]: (value) => [Number.parseInt(value)] } const Integer(counter) = 42.56; // counter === 42 [1] https://github.com/tc39/proposal-extractors https://github.com/tc39/proposal-extractors

THBC 2y ago

Number is not semantically compatible with raw 64-bit integer, so you might as well wish for a native const counter = UInt64(42); The current state of the art is const counter = BigInt.asUintN(64, 42);

obviouslynotme 2y ago

Yeah, that is why I said TS (or something similar). TS made some decisions that make sense at the time, but do not help compilation. The complexity of its typing system is another problem. I'm pretty sure that it is Turing-complete. That doesn't remove feasibility, but it increases the complexity of compiling it by a whole lot. When you add onto this the fact that "the compiler is the spec," you really get bogged down. It would be much easier to recognize a sensible subset of TS. You could probably even have the type checker throw a WTFisThisGuyDoing flag and just immediately downgrade it to an any.

com2kid 2y ago
> I'm pretty sure that it is Turing-complete. Because JS code can arbitrarily modify a type, any language trying to specify what the outputs of a function can be also has to be Turing complete. There are of course still plenty of types that TS doesn't bother trying to model, but it does try to cover even funny cases like field names going from kebab-case to camelCase.

the_imp 2y ago

With Extractors [1] (currently at Stage 1), you could define something like this to work: const Integer = { [Symbol.customMatcher]: (value) => [Number.parseInt(value)] } const Integer(counter) = 42.56; // counter === 42 [1] https://github.com/tc39/proposal-extractors https://github.com/tc39/proposal-extractors