Re:The Baseline Interpreter: A Faster JavaScript Interpreter...
by _bxg1 on Friday August 30, 2019 @02:34PM
(#20841240)
Yeah it's probably not worth it to add types to JS the language, but what if you could ship standard metadata files similar to source-maps that only included type information, which browsers could leverage to speed up compilation?
Re:The Baseline Interpreter: A Faster JavaScript Interpreter...
by WorldMaker on Friday August 30, 2019 @03:10PM
(#20841607)
In the long term, I hope that at least a compromise like the Python annotation approach could be reached (standardize the parsing, but ignore the semantics). Typescript type annotations share a surface level syntax with them in some ways, and also with ES4's type annotation attempt.
"Type maps" are an interesting idea. You could probably piggy back on/boostrap from WASM types.
Re:The Baseline Interpreter: A Faster JavaScript Interpreter...
by tomcam on Friday August 30, 2019 @07:56PM
(#20843795)
Sounds good in theory, but it seems like rich territory for mismatched types in the source and map files.
Re:The Baseline Interpreter: A Faster JavaScript Interpreter...
by _bxg1 on Tuesday September 03, 2019 @01:46PM
(#20869070)
I don't see why that would happen; you wouldn't be writing these by hand
Re:The Baseline Interpreter: A Faster JavaScript Interpreter...
by z3t4 on Saturday August 31, 2019 @05:02AM
(#20845301)
Adding types would probably slow down the code as some optimizations done by the engine wouldnt be allowed. Kinda like when you use bitwise operations for optimization only to find out they actually slow down the code.
We could hower add Interface and optional types as syntax sugar for runtime checks.
It would be great if Typescript hints could pass right along to the JITs as useful optimization factors, but it currently sounds like TC39 would prefer not to recreate the disasters of ES4 and are staying out of type hints for the forseeable future.
(Well-typed code should prevent most JIT bailouts, at least. Typescript linters could possibly give even better "shape" warnings than they currently do, such as catching the issue the React team recently found of bailouts in the V8 engine due to "shapes" being built with "small integers" being reallocated to doubles at runtime. However, such lint warnings would probably be JIT engine specific, and maybe premature optimization in 90%+ of usages.)