+1, better cabal support for UHC's JS backend would be a big win. Daniel
2012/3/11 Jurriën Stutterheim <j.stutterh...@me.com>: > While I might be a bit biased (I spent a good deal of time working on > improving the UHC JS backend), I think there are a lot of opportunities to > get Haskell as a client-side language via the UHC, as Heinrich suggested. > Alessandro Vermeulen recently wrote an entire front-end application using the > UHC JS backend, so we know that it's capable of producing working front-end > applications. See also[1]. > > Currently, however, it is still a bit of a pain to compile larger UHC JS > projects, since Cabal support for UHC's different backends is limited. This > could be one potential goal for your GSoC project: make it possible to type > `cabal configure && cabal build` and find a complete JS application in your > dist folder. This would go a long way to make 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, you 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. You would also need to modify > Cabal so that it becomes possible to select a specific UHC backend in your > cabal files. Ideally, you will only need one cabal file for an entire web > application; for both the front-end and backend. > > I think this would make a nice GSoC project. The scope of the above should be > about right, but if you would be done way ahead of time, there are plenty of > relevant related things you could work on (e.g., a UHC JS-specific Haskell > Platform-like package). If this sounds interesting to you, let me know and I > can send you some more detailed information about the UHC JS backend. As for > mentoring, I 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. > > > Jurriën > > [1] http://uu-computerscience.github.com/uhc-js/ > > On 8 Mar 2012, at 14:58, Heinrich Apfelmus wrote: > >> Chris Smith wrote: >>> My first impression on this is that it seems a little vague, but >>> possibly promising. >> >> My impression is also that this project proposal is rather vague. The >> general goal "Haskell as client-side language for websites" is clear and >> worthwhile, but I can't tell from the proposal whether the project will >> succeed or not, or, more importantly, *what* it will succeed at. >> >> >> The way I see it is that a successful GSoC proposal has to embody four key >> points: >> >> 1. One specific goal - "I want to compile Haskell to JS via UHC's backend" >> 2. in a larger context - "as a step towards Haskell as a client-side >> language for websites." >> 3. that is accompanied by a successful example - "To demonstrate that this >> works, I will write a small Asteroids game with HTML5 and Haskell" >> 4. and that others can build upon - "Moreover, I want to make it really easy >> for others to use the Haskell->JS compilation from cabal." >> >> The last point is extremely important: you don't want to build a hobbled >> prototype that languishes in a dark corner of github, you want to build a >> great software that changes the world by solving an important problem and >> making this solution really easy to use! >> >> >> Alejandro, your proposal mentions several different specific goals, each of >> which can be the basis for a successful GSoC project: >> >> * Make UHC's Haskell->JS compilation easy to use. >> * Design combinators for DOM manipulation in functional style, f.i. zippers. >> Note that this goal does *not* involve running Haskell on the client-side, >> the focus is solely on the design of combinators. This means that you'd have >> to use another example, for instance XML parsing. Of course, the idea is >> that this can be reused when someone else manages to run Haskell on the >> client. >> * Design combinators for "remote procedure calling" via HTTP/AJAX. Again, >> there is no Haskell running in the browser, the showcase would be two >> Haskell processes that communicate with each other via HTTP/AJAX. >> >> Each of these goals is a tangible improvement on the status quo and specific >> enough to be completed in a single GSoC project. >> >> >> Of course, the one specific goal is not supposed to be a limit, it is meant >> to be a foundation. If there is time remaining, the student is free to work >> on whatever he dreams of. By all means, don't hesitate to reach for the sky, >> but help us climb to the tree top first. >> >> >> Best regards, >> Heinrich Apfelmus >> >> -- >> http://apfelmus.nfshost.com >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
