GeezerVison

Sorry, things got busy around here, I'm going to pick this back up soon to address the feedback.

@rhendric I've addressed your initial feedback.

While doing the codegen refactoring, I noticed that purs codegen doesn't allow opting-in to generating source maps - I should probably add an option to the command to allow the user to opt-in to that.

I'll spend some time thinking about how we could add a meaningful test for this soon.

Other than that, there is the outstanding question of initializing the codegen supply with 0, which I've gone ahead and done. Then this should be ready for a final review!

@colinwahl do you have bandwidth to finish this off? Can I help?

I've rebased on current master here.

@MaybeJustJames would you like to take this over from me? My bandwidth for compiler work is pretty low these days.

The big open question is that I'm still not sure if #4092 (comment) could lead to any problems.

As the question is over a year old, I'm inclined to say let's ship it and find out.

Happy to take over. How would you like to do it?

Happy to take over. How would you like to do it?

However you'd like to do it is fine with me - you could continue off this PR, or make a new branch and cherry-pick my changes, or just close it and start again from scratch. Let me know what you decide and if I should close this PR!

However you'd like to do it is fine with me - you could continue off this PR

IMHO it would be a shame to lose the context here. Could I get write permission to your branch so I can pick up from here?

I was wondering - is this work necessary at all now that we have the backend optimizer?

I was wondering - is this work necessary at all now that we have the backend optimizer?

Supporting an optimizer was certainly my main goal for this - now that we've got purescript-backend-optimizer, I don't think I'd use the command (at least, I don't have anything in mind ATM). However, maybe someone's got other ideas :)

It does strike me as a loss if the best general-purpose JavaScript backend for PureScript remains in a third-party project in the long term. I'm not sure how exactly this happened—I suspect the friction to contributing to PureScript is just too high for this level of innovation—but with enough time I would hope it can be mostly unforked. At that point, exposing the backend used by purs becomes a feature of interest again, unless the unforking includes some other mechanism for making the CoreFn-handling pipeline extensible.

@rhendric I agree with you - my point here is that the new backend has shuffled the landscape quite a bit: it shows not only that it's possible to aggressively optimise the CoreFn, but also that it's possible to emit more performant JS outside of the compiler, and all of this while the implementation is in PureScript.
Given this new perspective, I am suggesting that we should reconsider the premises for this command to exist at all - with the baseline being that everything that is exposed by the compiler is a public API that we can't deprecate easily, e.g. see how long it took to remove bundle - and if the new project offers a better way to achieve the goal of this work (that is: generate better JS).
I am sure that this work will be unforked in the long term, hopefully while lowering the barrier for contribution, for example by showing that we can implement chunks of the compiler (or even all of it) in PureScript itself.

Okay yeah, I agree with looking at bundle as an example. We got rid of bundle when the ecosystem around ES modules matured enough and we did enough work on our codegen that we could recommend another no-regrets tool to replace it; waiting for those things to happen was what made deprecating bundle take so long, as far as I know.

Is purs-backend-es already that no-regrets tool for codegen? It's very impressive but also very young and possibly more aggressive than some of our users want. If it becomes that tool in the future, I don't see a significant barrier to ripping codegen back out, along with all the codegen internals. Just like with bundle, we'll paper over the switch in spago and basic users won't need to be aware of it.

In the meantime, as long as there's some value in having a built-in JS backend (regardless of the language in which the backend is written or the repo in which it lives), I think there's still a case for exposing it, so users can benefit from custom optimizations and rewrites without needing to also use a third-party backend.

Is purs-backend-es already that no-regrets tool for codegen?

purs-backend-es does not subsume compiler functionality.

• It is not incremental, so right now it's largely targeted at production builds. If we want to separate out the backend from the core compiler, then the compiler must be able to inform backends of incremental status, otherwise all backends have to duplicate the work the compiler has already done to sort out what needs to be built, which is a complete waste of non-trivial work and resources. I would like to make it incremental in the interim by just depending on cache-db.json, whether or not the compiler considers it a stable target because it's the only realistic way to get that information.
• It does not emit source maps. I personally have no intention of ever implementing this without near unanimous support from the community that it's something that people use since I consider the power-to-weight-ratio to be extremely poor.

So, I do not see any near term future where the current JS backend is rendered obsolete, though I would like a near term future where something like purs-backend-es can be used in a first-class way. That being said, if there are currently no pending users of this feature, I'm not sure what the point is. I think the fresh name issue seems like it can clearly cause a problem, however unlikely, and I'm not sure how you'd fix it. I don't know how I feel about merging a feature with a uncertain prospects and potentially buggy behavior.

I'm happy to talk about purs-backend-es background/motivation in general, but I don't think this is the place. If you have any thoughts or questions, I'd love to hear from you on discourse!

I think there's still a case for exposing it, so users can benefit from custom optimizations and rewrites without needing to also use a third-party backend.

I agree. I wanted to get this through for zephyr specifically. There is potential for other optimization tools to make use of this interface even if an improved backend is eventually merged.

I think this PR can be closed, right?

I would still vote to merge for the zephyr | ${other_optimizer} use case.

Is the vision for purescript to have multiple codegen backends? If non-javascript backends are always going to be separate projects then maybe to makes sense for JavaScript codegen to be separate too? In which case this PR should be closed. If the vision for the compiler is to include multiple backends then I think a codegen command will remain useful