Comments (6)
🤔 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. 😢 )
from jison.
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.
- I'm not sure if "AssemblyScript" is the strict sublanguage of TypeScript or if AssemblyScript is the tool which compiles an unnamed strict sublanguage of TypeScript; I've used it above assuming the former meaning.
from jison.
TurboScript was deprecated for a very long time.
from jison.
I can see the usefulness of TypeScript for a project like this (doing it is another matter -- time and all that) but the jison
kernel isn't WASMasble as it is (or so I guess): it's not just the tables, but also about error handling during lexing / parsing and there are callbacks, etc. there which I wouldn't know how to 'do' in WASM -- this is from reading through WASM introductions and a bit of spec scanning plus old asm.js stuff my brain picked up long time ago and distorted.
Anyway, if you want to have a look at viability, there's two main subjects to consider (at least for me):
- do we want this to support everything, or is this for a stripped-down parser where several kernel features have been taken out by the generator (like
jison-gho
does these days: if you don't use error handling/reporting thenjison-gho
SHOULD remove all error handling code from the kernel), ending with a 'optimized' parser with a minimal feature set. - the above then would go together with a kernel inspection to find out about roadblocks and hard-to-translate parts in the kernel. The lexer and parser kernel codes in bleeding edge have been separated out into separate JS files to make life a little easier for me:
- lexer kernel code is in
packages/jison-lex/jison-lexer-kernel.js
- lexer kernel error "class" definition is in
packages/jison-lex/jison-lexer-error-code.js
- the above two chunks would end up in any generated lexer.
jison-gho
doesn't do any serious feature stripping in the lexer YET. - parser kernel code is in
lib/jison-parser-kernel.js
-- this one is postprocessed by a regex-based "intelligent" (koff koff koff) feature stripper in the code generator. - the parser error "class" is in
lib/jison-parser-error-code.js
- the parser default
parseError()
function is inlib/jison-parser-parseError-function.js
jison --main
will also inject a default "main()" code chunk to run the parser as if it were a (very simple) CLI app: this code is inlib/jison-parser-commonJsMain-function.js
-- this code is not performance critical so not a concern for WASM in my opinion, just mentioning it for completeness.- helper APIs, etc. which are included in every parser class are located in
lib/jison-parser-API-section1.js
with a single lineconst API =
which is there to makeeslint
et al happy and stripped off before being dumped in a generated parser. - all the above stuff is included in more-or-less stripped-down form in a generated parser+lexer output by
jison-gho
.
Have a look at a generated parser and you'll recognize the various chunks in there coming from these files. - the kernel codes would be a primary concern for viability research when "porting" this to WASM.
- lexer kernel code is in
Anyway, that's how jison-gho
is "organized". Of course I'd love it if you would use jison-gho
, but another odd thought of mine about WASM: wouldn't it be "easier" (for arbitrary levels of "easy" -- probably also non-trivial to get going, but anyway) if you instead took the C language route to WASM via GNU bison
(and maybe flex
, which is a DFA-based lexer instead of jison
's regex-list based approach) and compile their output to WASM using llvm
and emscriptem
or what-is-the-process-for-that-these-days?
^^^ Just a rough thought, not hampered by any experience with this C-to-WASM stuff, so only riding what I recall of blogs I read about it over the years. 🤭
from jison.
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!
from jison.
👍
from jison.
Related Issues (20)
- Generate lexer/parser in different programming language
- build problem: @gerhobbelt/recast should require @gerhobbelt/esprima
- Rename project, new identity.
- arrow notation barfs on comments HOT 8
- `lexer.conditions[K].rules` grows with each call to parse HOT 7
- Git version looks older than NPM HOT 4
- Question: jison-gho debugger HOT 1
- Do parsers share a global state? HOT 1
- Parser source produced by generate API is different from CLI output HOT 1
- make esprima errors more intelligible (caused by faults in user action code test-parse-passes during grammar compile)
- Add unit tests to directly verify feature stripper generating compiling-and-running output
- Doesn't seem to pick longest possible match HOT 1
- Using "?." and "??" JS operators in action code blocks ?
- TypeError: yylexer.mergeLocationInfo is not a function HOT 1
- Use sub part of the parser HOT 2
- How is possible to implement C-like pre-processor macros ?
- NPM warnings about vulnerabilities
- Can't parse postgresql grammar and missing error location HOT 2
- Decorator error when using `@` variables in actions
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jison.