Consider combining executables (and specify backend with switch)

[andyarvanitis]

No description provided.

[joprice]

I'm relatively new to haskell, but could give this a go if you'd have some time to point me in the right direction.

[andyarvanitis]

The basic strategy I would follow would be to first find the source files that can be shared between the two without any changes (I think there still are some). Then I would see if any could be modified to be shared, breaking out backend-specific parts (probably a good exercise anyway, as some refactoring is due). Next would be simply renaming and moving the unique modules. The final part would be tackling the driver part (main app), and getting that combined in a clean way.

The full effort should be doable even by someone not very experienced with Haskell or this codebase, but I wouldn't advertise it as a fun exercise.

The other thing is spago support. I think some changes would be needed there to make sure everything works with it correctly.

[andyarvanitis]

Another option is one combined codebase but still have separate executables for each (pscpp, psgo). That would at least have no impact on spago, and might be the cleanest approach. It could also be a good first step even if eventually there was one combined executable.

[joprice]

I would think the two executables sounds better, since it maintains the "interface" of the separate executables. I prefer to change one thing at a time. I'll check out the two branches and see if I'm up to the challenge.

[joprice]

I have a branch where I merged everything and left the cpp issues commented out for now, so I could see the scope of the changes https://github.com/andyarvanitis/purescript-native/compare/golang...joprice:combine?expand=1. Here are my thoughts so far:

1. I added a second executable for pscpp. I think we could use cpp-options on each executable block to conditionally define a constant value of an enum that sets the backend.

2. Some options will be specific to a backend like ucns. These can be determined by the backend variant as well

3. The codegen needs to take into account the backend and produce different output

4. The outer project should be rename to ps-native instead of psgo

I didn't go through with any of this yet since it all hinges on the backend enum. Another approach is to include separate sources in each executable, so they can have entirely separate code paths. If the code diverged or will diverge in the future a huge amount, I would say that's a better path. Currently it's very similar and easy enough to just pattern match on backend. Also, having them in a single binary might supports taking a flag to switch backends instead of having two binaries (for instance, if spago could pass default flags to a binary or if the binary is installed on someone's box wrapped in a bash runner script that adds the flag).