That sound like a really cool project. Where could I get more information about what could I do? You mention about contacting but I think it's better to keep the discussion open for everybody.
Alejandro 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
