Ah, amazing project! Congratulations. I was just writing under another thread that we support any and unknowns in two different ways. First, most any and unknowns are lazy programming—if you trace the call graph you can prove they have concrete types, or used only in one shape. If we can't prove a type narrows properly, we lower it to a boxed dynamic value carrier so it doesn't block compilation. Like JSON.parse—for this we have a special syntax, you can do JSON.parse(x) as T, to define the type, and if you don't it becomes a dynamic value whose price you pay only for that site / variable.
We also have limited support for `new Function("...")` via a small evaluator written in C++ that parses and runs the generated body. We mainly built this for Fastify's generated routing functions so it doesn't support classes, asynchronous, destructuring, etc, but conditionals, loops, variable declarations etc work.
There is no "eval" yet, but the same support shape could be added for it too, as the mechanism is already there.
The approaches and the limitations are documented here:
Also curious - how do you handle "number"? i32, i64, doubles, floats, i16 etc have very different performance characteristics. Also, things like sparse arrays, Error.stack etc. I haven't documented them in my project yet, but it's quite high up in the list of things people actually care about.
A plain number is a double, and then the compiler can prove it can be a 64-bit integer if the size is appropriate. The goal is to keep behavior parity with Node here. Loop counters etc stay double. But we also support custom types we introduced such as i32, which is crucial for embedded performance. And then of course we have proper typed arrays.
Regular arrays are dense, but we keep a presence bit for every element so we can identify sparse arrays and differentiate holes from undefined's. And finally, there's no Error.stack support right now.
jeswin · · focus · HN ↗
One of the biggest complaints I get is about missing documentation on what TypeScript is not supported.
For example, the following is obviously impossible:
or even: The rest of it is largely doable. But people want to see what's not supported. Otherwise it's not clear to them what to avoid.dashersw · · focus · HN ↗
We also have limited support for `new Function("...")` via a small evaluator written in C++ that parses and runs the generated body. We mainly built this for Fastify's generated routing functions so it doesn't support classes, asynchronous, destructuring, etc, but conditionals, loops, variable declarations etc work.
There is no "eval" yet, but the same support shape could be added for it too, as the mechanism is already there.
The approaches and the limitations are documented here:
<a href="https://github.com/geastack/compiler/blob/main/docs/EVAL.md" rel="nofollow">https://github.com/geastack/compiler/blob/main/docs/EVAL.md <a href="https://github.com/geastack/compiler/blob/main/docs/DYNAMIC-FALLBACK.md" rel="nofollow">https://github.com/geastack/compiler/blob/main/docs/DYNAMIC-...
jeswin · · focus · HN ↗
dashersw · · focus · HN ↗
Regular arrays are dense, but we keep a presence bit for every element so we can identify sparse arrays and differentiate holes from undefined's. And finally, there's no Error.stack support right now.