[Haskell-cafe] Summer of Code idea: Haskell Web Toolkit

[Alejandro Serrano Mena]

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.stutterheim at 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 at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120311/d9b2750c/attachment.htm>