My issue isn't that you'd need to develop a new set of tools. I just think that using a library approach would allow us to generate more comprehensible code. Hopefully, we could still reuse datatypes, and do lots of other fun stuff. For example, if we used aeson's ToJSON/FromJSON instances for serialization, and some kind of lens library in place of normal record selectors, there's no reason why would couldn't automatically convert: personName person to person.name I know I'm saying a lot of vague stuff here, simply because I haven't had a chance to really solidify my ideas on how to move forward on it. But I'm certainly not ruling out any possibilities at this point, simply stating a preference to avoid a full-blown Haskell-to-JS solution. Michael On Wed, Mar 7, 2012 at 12:10 AM, Alejandro Serrano Mena wrote:

My idea would be reusing some of the already-available tools for compiling Haskell to JS (for example, UHC), and develop with any of them a complete library for client-side scripting; rather that redevelop a way to compile Haskell to JS.

I think it's really a pity not being able to use things like what Yesod provides in a client-side context. And both sides would benefit: they can share common code for datatypes (as it's done in Google Web Toolkit), and autogenerate some code for sending or receiving AJAX requests, for example.

2012/3/6 Michael Snoyman

...

On Tue, Mar 6, 2012 at 11:40 PM, Alejandro Serrano Mena wrote:

...

Hi, I'm really looking forward to helping in the Summer of Code, if Haskell goes into it this year (something I take for granted :). I would like to propose an idea for a project, and I'm looking for suggestions about whether it's good, should be improved or it's just unfeasible.

My idea is to make a client-side Haskell Web Toolkit, in the spirit of Google Web Toolkit, which would allow to program in Haskell the client part of a web application, and would complement the web frameworks already existing for Haskell (such as Yesod and Snap). The point is coming about with a Haskell-ish way to program applications, to reuse all the existing knowledge for our beloved language.

I've added more details in a pre-proposal in Google Docs, available

in https://docs.google.com/document/d/1FnTNO9uTobDHRTDXWurKns7vGTjeauw0nRhbtt6v... Tell me if you prefer to see it in other format, but I didn't want to generate a bigger e-mail.

Thanks in advance.

I definitely think the idea has merit. In general I'm wary of solutions which try to compile down to Javascript[1], and I'm not sure if actually providing a full Haskell-to-JS approach is a good idea. Another possibility might be a DSL/combinator library for generating JS. Though at this point, I wouldn't rule out either approach.

Yesod is currently wrapping up its 1.0 release (almost certainly out-the-door by the end of April), and after that our main focus is intended to be client-side integration, so we would certainly be happy to discuss design ideas and collaborate in general.

Michael

[1] I say "compile down to" to mean nontrivial changes, as opposed to something like Coffeescript, which is a fairly simple conversion.

On 03/06/2012 11:38 PM, Christopher Done wrote:

I might as well chime in on this thread as it is relevant to my interests. I made a write up on a comparison of HJScript (JavaScript EDSL) and my Ji (control browser from Haskell) library: https://github.com/chrisdone/ji

HJScript is "OK", hpaste.org uses it here: https://github.com/chrisdone/amelie/blob/master/src/Amelie/View/Script.hs output here: http://hpaste.org/js/amelie.js

HJScript (0.5.0) generates invalid Javascript if you try to use anonymous functions. (Digs through email archives... Ah, yes:) -------------------- snip -------------------- Given

testJS :: HJScript () testJS = do f <- function (\(e :: JInt) -> do x <- inVar true return $ x) callProc f (int 3) return ()

main :: IO () main = do putStrLn $ "JS: " ++ (show $ evalHJScript $ testJS)

We get the output

function (param0_0){var var_1 = true;return var_1;}(3);

But this is invalid syntax in JavaScript, and should really be

(function (param0_0){var var_1 = true;return var_1;})(3);

... which works. -------------------- snip -------------------- Just something to be aware of. (For my particular usage it was also too strictly typed, but that's another matter.) Regards,

HJScript is "OK", hpaste.org uses it here: https://github.com/chrisdone/amelie/blob/master/src/Amelie/View/Script.hs output here: http://hpaste.org/js/amelie.js

Mini-summary of my experience: You're still stuck with JS semantics, and it can be a little odd when you confuse what level of code (JS or HS) you're working at, but at least it works right now and can be well-typed. The library needs a bit of an overhaul, the GADT of HJavaScript is simply flawed (take a brief look and you can see it can express totally invalid JS in the syntax tree and the pretty printer breaks operator/parens), but HJScript sorts the latter out, and I would make all HJScript's functions generic upon MonadJS or something,

It seems like the unavoidable fact is that HJScript is a library almost without documentation and without examples/tests. And for an EDSL that would seem to be an especially big problem, almost, but not quite as bad as being told to learn Haskell by being given a GHCI prompt and left to trial and error. I've been trying to generate the following line of code: google.load("visualization", "1", {packages:["corechart"]}); I don't know JS, and my reverse engineering of this one line failed in two places: callVoidMethod "load" (string "visualization", string "1", JConst "{packages:[\"corechart\"]}") (TopLvl "google") First, there are classes like IsDeref and IsClass with no clear recipe for how to create values and types satisfying them. Hence "TopLvl", which is my own introduced hack: data TopLvl = TopLvl String instance Show TopLvl where show (TopLvl s) = s instance IsClass TopLvl Second, I couldn't figure out how to generate a dictionary/record expression such as {packages:"core chart"}. It doesn't seem to be part of the data model of the underlying HJavaScript package: http://hackage.haskell.org/packages/archive/HJavaScript/0.4.7/doc/html/Langu... Although it's probably possibly to build up that record in a variable binding through some series of assignments, though I haven't found it yet... What would help enormously, in addition to some documentation patches [which I will try to provide if I use the library further], would be a parser from JS concrete syntax to the HJavaScript AST. Anyway, at this point it seems MUCH easier to just produce strings, which is too bad. -Ryan

Doesn't sound overused to me. FWIW, one of the ideas floating around in my head is exactly what you're describing. On Wed, Mar 7, 2012 at 2:41 PM, JP Moresmau wrote:

Maybe I'll sound like an overused meme, but what about JQuery? JQuery already takes a combinator-like approach to Javascript and DOM manipulations, so maybe we could have a combinator library that would mimic the JQuery library. We'd obviously need some extra combinators for the required parts of Javascript and HTML generation that are not done via JQuery.

JP

On Tue, Mar 6, 2012 at 11:10 PM, Alejandro Serrano Mena wrote:

...

My idea would be reusing some of the already-available tools for compiling Haskell to JS (for example, UHC), and develop with any of them a complete library for client-side scripting; rather that redevelop a way to compile Haskell to JS.

I think it's really a pity not being able to use things like what Yesod provides in a client-side context. And both sides would benefit: they can share common code for datatypes (as it's done in Google Web Toolkit), and autogenerate some code for sending or receiving AJAX requests, for example.

2012/3/6 Michael Snoyman

...

On Tue, Mar 6, 2012 at 11:40 PM, Alejandro Serrano Mena wrote:

...

Hi, I'm really looking forward to helping in the Summer of Code, if Haskell goes into it this year (something I take for granted :). I would like to propose an idea for a project, and I'm looking for suggestions about whether it's good, should be improved or it's just unfeasible.

My idea is to make a client-side Haskell Web Toolkit, in the spirit of Google Web Toolkit, which would allow to program in Haskell the client part of a web application, and would complement the web frameworks already existing for Haskell (such as Yesod and Snap). The point is coming about with a Haskell-ish way to program applications, to reuse all the existing knowledge for our beloved language.

I've added more details in a pre-proposal in Google Docs, available

in https://docs.google.com/document/d/1FnTNO9uTobDHRTDXWurKns7vGTjeauw0nRhbtt6v... Tell me if you prefer to see it in other format, but I didn't want to generate a bigger e-mail.

Thanks in advance.

I definitely think the idea has merit. In general I'm wary of solutions which try to compile down to Javascript[1], and I'm not sure if actually providing a full Haskell-to-JS approach is a good idea. Another possibility might be a DSL/combinator library for generating JS. Though at this point, I wouldn't rule out either approach.

Yesod is currently wrapping up its 1.0 release (almost certainly out-the-door by the end of April), and after that our main focus is intended to be client-side integration, so we would certainly be happy to discuss design ideas and collaborate in general.

Michael

[1] I say "compile down to" to mean nontrivial changes, as opposed to something like Coffeescript, which is a fairly simple conversion.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- JP Moresmau http://jpmoresmau.blogspot.com/

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

+1, better cabal support for UHC's JS backend would be a big win. Daniel 2012/3/11 Jurriën Stutterheim :

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

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

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