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
