Cabal support for the UHC JavaScript backend

[norm2782]

We recently improved the UHC JavaScript? backend[1] and showed that we can use it to write a complete front end for a web application[2]. A summary and demo of our results is available online[3].

Currently, however, it is still quite inconvenient to compile larger UHC JS projects, since Cabal support for UHC's different backends is limited. The programmer currently manually specifies include paths to the source of the used modules. Improving this situation is the goal for this GSoC project: make it possible to type cabal configure && cabal build and find a complete JS application in the project's dist folder.

Successful completion of this project would go a long way towards making the UHC JS backend more usable and as a result, make Haskell a practical language to use for client-side programming.

In solving this problem, one will have to think about how to deal with external Haskell libraries (UHC compiles JS from its internal core representation, so storing pre-compiled object files won't work in this case) and perhaps external JS libraries as well. One will also need to modify Cabal so that it becomes possible to select a specific UHC backend in your cabal files. Ideally, only one cabal file for an entire web application is needed; for both the front-end and backend application.

An additional goal (in case of time to spare) would be the creation of a UHC JS-specific Haskell Platform-like distribution, so that programmers interested in using this technology can get started right away. Of course, such a distribution would have to be installed alongside the regular Haskell Platform.

As for mentoring is concerned, I (Jurriën) might be able to help out there, but since the above project would revolve more around Cabal and not so much around the UHC internals, there might be more suitable mentors out there.

[1]  http://www.norm2782.com/improving-uhc-js-report.pdf
[2]  http://alessandrovermeulen.me/2012/01/26/getting-rid-of-javascript-with-haskell/
[3]  http://uu-computerscience.github.com/uhc-js/

[AlessandroVermeulen]

Ideally, only one cabal file for an entire web application is needed; for both the front-end and backend application.

This suggests at that you should be able to specify the target per section (project or library), as well as the compiler.

[serras]

I've written a preliminary proposal for this project, and made it available in  https://docs.google.com/document/d/1OLVa2VJ0eUub84fQqLMxwjnhqjqwvKyeyvvBQZsUtfk/edit May I get some feedback about it? Thanks in advance :)

[norm2782]

I'll comment on individual snippets of your proposal as I read through it. The snippets are in bold text.

Libraries could be precompiled to JS (or some intermediate representation) for later usage, Currently the backend generates JS code from Core code. If you are going the intermediate language way, that's probably your best bet, since it's a stage shared by every backend as well. However, since the conventional approach for Cabal is to only store things further down the pipeline, just storing the .mjs files that UHC generates might be a better solution.

Cabal should support changing compiler and backend for each of the project targets, It is already possible to use a different compiler. The backend is currently hardcoded in the cabal code, though.

Cabal should support a way to reference Javascript libraries needed for building as it does now for C libraries. I'm not sure if this can be solved (purely) on the Cabal level, since the biggest challenge will be including the JS libraries in the generated HTML file. You might need to do some UHC hacking for this as well. Including the JS files themselves should be relatively easy using the existing Cabal ways of including additional files.

Your By the end of the summer point: I think that if you port the entire JCU app to the new infrastructure, you essentially already have an app showcasing all functionality. Of course, a minimal example would still be interesting.

[serras]

Thanks very much for the comments :)

About Javascript libraries, I was thinking of the problem of having some library X which targets JS and uses, say, JQuery; and then having an app which used this library. My intent is to get a good behaviour for this scenario.

[AlessandroVermeulen]

There has been some discussion at Utrecht on how to model said dependency on (external) javascript libraries. I believe the outcome was that it would be too complicated to support every combination of [static/dynamic/at-compiletime/at-runtime/url/local-file]. I'm not familiar with how Cabal / GHC currently links against C/C++ libraries or how you can register the dependency on a certain reference. Maybe we should go a similar route with the JS bit, or make it more general?

[norm2782]

Re: external library: I'm looking forward to see what you come up with. It's something I haven't given a lot of thought yet.

One more remark for your document: as you state, your starting point for Cabal hacking will likely be Distribution.Simple.UHC. If you look at  line 271 of that module you can see that the bc backend is currently hardcoded in uhcTarget. You can probably modify this existing module instead of writing a second one for UHC. You would need to make sure that it's possible to specify the uhcTarget from your Cabal file and pass it to UHC with the -t flag: uhc -tjs or uhc -tbc. By doing so you would already add support for all possible UHC backends, so there is probably no need to limit yourself to just supporting the JS backend. It will also make it relatively straight-forward to separate the various object files on the filesystem.