2 ms·
Yes, parsing is trivial, but compiling (in the traditional sense, not the transpilation sense) is a different story. The other sibling comment nails it. Gramma
by lhorie 6y ago
Yes, parsing is trivial, but compiling (in the traditional sense, not the transpilation sense) is a different story. The other sibling comment nails it.
Grammar enforces where a grammar construct is allowed to exist. A custom grammar can be very restrictive (which it is, to great effect, in Svelte's case).
If we reuse JS grammar, then that comes with expectations of what should semantically work. For example something as simple as `$ = svelte.each` might evade a not-sufficiently-smart compiler. Or maybe `console.log(svelte.each(...))` might mis-compile because nobody ever thought to handle that case.
Having used systems with compile-time grammar constructs that look like runtime constructs, I can tell you that having your expectations about semantics being changed from under your feet can be a very frustrating experience.
- jeswin 6y agoYou're right about it being complex (my experience [1]), but such work is within scope for what's perhaps a central design decision for a library. Yes there'll be bugs, but it'll stabilize over time. Just to be clear, I am NOT saying that Svelte needed to do this. But merely suggesting options for discussion and learning. [1]: https://github.com/jeswin-unmaintained/isotropy-ast-analyzer-db/blob/master/src/schemas/sort.js https://github.com/jeswin-unmaintained/isotropy-ast-analyzer... - Here's for instance, some code I wrote for analyzing a JS sort expression. You'd think it'd take just a few hours, until you get to it. Btw, it uses an AST analysis framework I wrote called chimpanzee - it has only one user though. :) https://github.com/jeswin/chimpanzee https://github.com/jeswin/chimpanzee