Idris2-boot
Idris2-boot copied to clipboard
edwinb
JavaScript backend
I was thinking of starting work on a JavaScript backend for Idris2.
I have some preliminary work (AST and codegen) completed on my fork, but I wanted to check in before getting too deep into this.
I just saw this commit which states "This is step 0 towards pluggable back ends". Would it be better to wait until pluggable backends are in place before even thinking about a JS backend?
Also, a more general question, are other backends (like a JS one) intended to be in-tree? Or would they be handled out-of-tree?
I expect that once pluggable backends are a thing, it should not be hard to port the existing ones.
Non-pluggable backends have to be in-tree.
I'm also working on a JS backend but from the opposite end: I'm looking into defunctionalisation at the moment. I have a concrete idea that I want to try out (unrestricted TCO via switch-in-while), so it's a bit of a private experiment of sorts. Besides, if it gets too laborious, I might just give up. It would not be the first time. :)
But I like to have neat generated code with comments, indentation, smart linebreaking, and everything, so i was going to use my pretty-printing library for it. A proper AST library that can do that by itself would be great, of course.
But I like to have neat generated code with comments, indentation, smart linebreaking, and everything, so i was going to use my pretty-printing library for it.
I would just run the JS output through Prettier :wink:
Out of interest, what is the use case for a javascript back end vs WASM one?
@shmish111 WASM can't currently do everything JS can do, the main thing being building web apps.
For the record, I've abandoned the JS project I talked about. It turns out that the JS switch statement does not jump in constant time, at least not in the CLI version of NodeJS.
@ziman Matúš,
If the JS switch is in a top-level function, it is likely not being JITted, just interpreted. Set up some global state and contrive a way to warm up the function, and it can be JITted.. I encountered the same problem in a prior life.
-Matt
@maxdeviant Being unaware of your fork, I implemented a JavaScript backend in my fork: feature/codegen-es
For now, the backend is directly generating the code by building a (long) string, but your approach with a separate AST seems much cleaner! So I'll have a look into switching my codegen over to use your JS AST.
