JavaScript backend

[maxdeviant]

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?

[ziman]

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.

[maxdeviant]

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:

[shmish111]

Out of interest, what is the use case for a javascript back end vs WASM one?

[maxdeviant]

@shmish111 WASM can't currently do everything JS can do, the main thing being building web apps.

[ziman]

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.

[diakopter]

@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

[cypheon]

@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.