3 ms·
I think the emphasis on embedded languages is interesting. A lot of modern code is stuff like js-in-jsx-in-html-in-yaml etc., a fact which isn't really addresse
by jhpriestley 7y ago
I think the emphasis on embedded languages is interesting. A lot of modern code is stuff like js-in-jsx-in-html-in-yaml etc., a fact which isn't really addressed by most tooling.
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.
- austincheney 7y agoThe biggest short-coming I have found with my approach is that I have not systematically mapped out the language nesting identity. At the moment I am utterly reliant upon rules in a given language to identify the thing that is nested. For example I know that stuff in an HTML style tag will be CSS, because the rules of HTML say so. 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.