New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
suggestion: typescript compilable to WASM #59
Comments
🤔 you want to compile typescript to WASM? But isn't that similar to saying you want to compile JavaScript to WASM, or am I reading this incorrectly? (Aside: jison (jison-gho) is still on the backburner, but I'm getting a little time to fiddle with it again in a month or so, so might do another release if I get enough done. Taking on more would not be possible before 2021 though, I expect. 😢 ) |
Because JavaScript isn't type-safe, the interpreter spends a lot of time testing types. You basically half to compile that work into a WASM target. AssemblyScript ("a strict variant of TypeScript" that makes typing non-optional)* is type-safe so the WASM target can dispense with that cruft. The notion I had in mind was not to port Jison to TypeScript, though that could make some maintenance easier, but instead to write the generated parser and state tables in AssemblyScript -- basically a little printf manipulation. That could be used like any other javascript with typescript annotations (mild benefits: enforce type-safe invocation, IDE hints), or compiled to WASM. I don't know how much of a performance increase that would buy; maybe a lot 'cause you're type-safe and closer to the metal, maybe not a lot 'cause consistent tables of integers are highly-optimized in JavaScript interpreters. At any rate, it would probably produce a smaller image in WASM. A way to test would be to hand-port some parser (I'd use ShEx and test with FHIR) and benchmark it in JavaScript and WASM. Another option would be TurboScript, which is "based on" TypeScript without memory management (AFAIK) and a restricted set of types (which appear to line up well with what you need to build and navigate state tables and stacks). In principle, it could compile to C and JavaScript, as well as WASM, but that's not yet implemented, and the project seems to be on ice, so probably not a good source language.
|
TurboScript was deprecated for a very long time. |
I can see the usefulness of TypeScript for a project like this (doing it is another matter -- time and all that) but the Anyway, if you want to have a look at viability, there's two main subjects to consider (at least for me):
Anyway, that's how
|
- cleanup lib/jison.js Unicode blob in comments - more work done on lib/jison.js as part of the ES6 migration - re-add previously removed test ist/sollwert files - fix jison kernel patcher code for yydebug removal in lib/jison.js - added patch script to patch the line numbers printed as part of test and assertion failure reports - adjust the parser generator code to not use `eval()` (which doesn't pass 'let var' variables to the calling scope) but use our own function()-based exec scaffolding instead (borrowed from the lexer test code, where this was already used) - added test example for issue #59 (grammar is referenced in the comments there) - fix faulty variable name reference in a parser kernel yydebug statement (due to earlier overzealous ES6 migration cleanup removing the name mapping there) - fix infinite loop (continue+break interplay) in lib/jison.js - fix tests/parser/api.js test case: this jison release **requires** yylloc instances to have a valid `range[]` array. (If you want quite different location tracking, one of the required changes would be to specify your own copy_yylloc_native() method via the parser options.)
Yeah, I think that compiling BISON output to WASM with LLVM would give you a pretty optimal executable. I was thinking more about the code path where lazy people (specifically, me) have existing js libraries that they want to shove into the WASM box. Many thanks for the thorough analysis! |
👍 |
cause it would go like stink.
I would happy to pitch in; I'm motivated by some stuff that takes a minute to parse, which hampers user experience.
The text was updated successfully, but these errors were encountered: