The link I mentioned in my previous email contains pretty much all of the 
currently available public information about the UHC JS backend (the "Improving 
the UHC JavaScript Backend" report is already slightly outdated, due to an API 
change, though). My report also contains some ideas for future work where this 
idea is also briefly mentioned. In addition to that, I have a yet unpublished 
paper that is very relevant to the UHC JS backend, but I don't think I can make 
that public yet, hence the "contact me" part :)

Also, I have added it to the project list: 
http://hackage.haskell.org/trac/summer-of-code/ticket/1610


Jurriën

On 11 Mar 2012, at 11:55, Alejandro Serrano Mena wrote:

> 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

Reply via email to