4 ms·
There's a big difference: that's basically just a pipeline for AST tranforms. That's not very hard. Basically just a bunch of different JS libraries that you ha
by jlongster 12y ago
There's a big difference: that's basically just a pipeline for AST tranforms. That's not very hard. Basically just a bunch of different JS libraries that you hand an AST through.
That's not actually that useful. In my post, I mentioned adding syntax for literal persistent objects, using something like Mori data structures. The syntax could look like this:
* #[1, 2, 3] <- persistent vector
* #{x: 1, y: 2} <- persistent map
An AST pipeline makes the "analyze" phase extensible, but it doesn't do anything to the parser. You can't actually add syntax, ever. So it's just not that useful for extending the language. It's good for something like implementing various parts of ES6.
Actually, it's even better for something like types or modules, which really need the whole AST. But in my opinion, everything else is better as macros.
sweet.js works on a tree of tokens, and it allows extending actual syntax. It's also way easier to transform code because it has a pattern matching language and you don't have to manually wrangle AST nodes.
Lastly, sweet.js keeps track of scoping, and in the future it will have modules, so you will be able to do something like:
```
import JSX from "jsx-reader";
import # from "mori";
// code ...
```
And those language extensions are only available inside the module. Everything is scoped.