Show HN: Sparser – A Multilanguage Parser
* https://sparser.io
* https://github.com/Unibeautify/sparser
This is my attempt at creating a universal language parser. It attempts to solve a couple of problems:
* Support multiple languages
* Recursively extend support to languages embedded within other languages
* Output a uniform format for all supported languages
This is a personal project so any feedback would be helpful. Something interesting I found after I built it is that this parser is not as fast to write output as many other JavaScript parsers, but its output is much faster to read from due to the simplicity and predictability of the format.
18 comments
[ 2.7 ms ] story [ 51.8 ms ] threadI personally think its easier to use something like the `sublime-syntax` grammar format to define a lexer (with a project like syntect[1]), rather than implementing each language's lexer as code, but that would need some extra annotation to get such a nice structured output. The bonus, however, if someone where to work on such an addition, would be that syntax highlighting will use the same engine and deal with incomplete/incorrect code consistently
[1]: https://github.com/trishume/syntect
It seems like you're aiming to make a more flexible lexer, with support for nested contexts. My immediate question is how this differs from a grammar-driven parser. Does it handle types of embedding that can not easily be encoded as CFGs? Or is it faster or simpler than e.g. an Earley or LR parser? I couldn't find an answer to these questions on a casual read of the docs.
This approach has limitations where the relationship between an embedded grammar is not clear. Is a markup grammar that contains something like Liquid template tags HTML or XML? How do you specify the code by language name, because the embedded grammar is the Liquid tags but you want to identify the grammar of the template tags apart from other template languages. What if a markup language instance contains template tags from unrelated grammars?
I could auto detect the language each time the grammar changes, but that would be slow and introduce unexpected results. The precise solution would be to allow users a means to define nesting based upon syntax or structure and I have not thought through this yet.
> Doesn't actually parse, it's a lexer.
Good lord!
* https://en.wikipedia.org/wiki/Lexical_analysis
* https://en.wikipedia.org/wiki/Parsing#Parser
Your home page eats my CPU and makes my notebook hot enough to boil water.
Whatever you're doing on that page, please stop it.
If you're hoping HN users will use/support your library, I think we deserve to know why your simple page consumes nearly 100% CPU.
Are doing something nefarious or are you just incompetent?
Would you mind reviewing the site guidelines and following them when posting here? Note that they include Be kind and Don't be snarky.
https://news.ycombinator.com/newsguidelines.html
Then why didn't I get banned?
If you're hoping HN users will use/support your library, I think we deserve to know why your simple page consumes nearly 100% CPU.
Are doing something nefarious?
This is far from a "universal language parser".
"obj = {};" the last token is ";"
but when the input is "obj = {}" the last token is "x;"
does "x;" mean an implicit ";"?
I include the pseudo tokens for two reasons. The first reason is that they allow the parser to reason about the code more closely to the language specification. For example the specification says statements MUST be terminated by a semicolon and if a semicolon is not provided one will be inserted automatically (ASI). The second reason is that the pseudo tokens are necessary to eliminate certain ambiguity necessary for some advanced features.