Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
>
> 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/Language-HJavaScript-Syntax.html
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
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 > 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. >
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
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 > > > > > > ___
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
Jurriën Stutterheim wrote: 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. [..] 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. This sounds like a great GSoC project to me. Maybe you can add it to the list of project suggestions, Jurriën? http://hackage.haskell.org/trac/summer-of-code/report/1 Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
+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/
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
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
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
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
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
On Wed, Mar 7, 2012 at 11:47 AM, Alejandro Serrano Mena wrote: > I agree with you that maybe this proposal is vague for a GSoC, but I don't > think that websockets is a good option either, because not all browsers > support them. We already have a websockets library, but like you say it is not very useful by itself because it may not be supported in all browsers. The GSoC proposal is to create a library that will use appropriate fallbacks on all browsers, which is how websockets are normally used. > > > 2012/3/7 Greg Weber >> >> This is obviously a great concept. However, it may not be appropriate >> for a GSoC. The design space is far too open, and it is not clear if >> anything in that space will end up beating plain old javascript. >> >> I think my proposal for an awesome websockets library [1] shows that >> this is putting the cart before the horse. For some of the potential >> javascript solutions, websockets is a dependency anyways. Without >> being able to hold open a connection to the server, required server >> interaction will be too slow. >> Yesod has been successful by explicitly avoiding any new radical >> paradigms, but by instead just trying to get the basics of web >> development established correctly. Without websockets, we don't have >> the basics down for fluid client-side interaction. >> The groundwork for this ticket has been laid: it should be easy to >> accomplish with time left over. >> So we are guaranteed a clear win for the community. With the time left >> over, a solution to the javascript problem can be attempted. But there >> is no burden for it to be solved within the summer. Next year the >> landscape will be more mature and we can try to come up with a solid >> proposal for the javscript problem if the community hasn't already >> created a solution. >> >> [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1607 > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
I agree with you that maybe this proposal is vague for a GSoC, but I don't think that websockets is a good option either, because not all browsers support them. Indeed, web development has gone a long way without contant communication with the server and I think Haskell should support this way of working too. My idea would rather go on the direction of using stablished Haskell concepts to web development. Some ideas are: - use an applicative interface like the one of Yesod for forms validation and sending - see the DOM via a Zipper interface, so widgets will "anchor" themselves in some point of the tree and change things around them - use FRP for Canvas interaction - ... Actually, thinking which Haskell concepts could behave well with client-side development is an interesting discussion by its own :) 2012/3/7 Greg Weber > This is obviously a great concept. However, it may not be appropriate > for a GSoC. The design space is far too open, and it is not clear if > anything in that space will end up beating plain old javascript. > > I think my proposal for an awesome websockets library [1] shows that > this is putting the cart before the horse. For some of the potential > javascript solutions, websockets is a dependency anyways. Without > being able to hold open a connection to the server, required server > interaction will be too slow. > Yesod has been successful by explicitly avoiding any new radical > paradigms, but by instead just trying to get the basics of web > development established correctly. Without websockets, we don't have > the basics down for fluid client-side interaction. > The groundwork for this ticket has been laid: it should be easy to > accomplish with time left over. > So we are guaranteed a clear win for the community. With the time left > over, a solution to the javascript problem can be attempted. But there > is no burden for it to be solved within the summer. Next year the > landscape will be more mature and we can try to come up with a solid > proposal for the javscript problem if the community hasn't already > created a solution. > > [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1607 > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
This is obviously a great concept. However, it may not be appropriate for a GSoC. The design space is far too open, and it is not clear if anything in that space will end up beating plain old javascript. I think my proposal for an awesome websockets library [1] shows that this is putting the cart before the horse. For some of the potential javascript solutions, websockets is a dependency anyways. Without being able to hold open a connection to the server, required server interaction will be too slow. Yesod has been successful by explicitly avoiding any new radical paradigms, but by instead just trying to get the basics of web development established correctly. Without websockets, we don't have the basics down for fluid client-side interaction. The groundwork for this ticket has been laid: it should be easy to accomplish with time left over. So we are guaranteed a clear win for the community. With the time left over, a solution to the javascript problem can be attempted. But there is no burden for it to be solved within the summer. Next year the landscape will be more mature and we can try to come up with a solid proposal for the javscript problem if the community hasn't already created a solution. [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1607 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
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/1FnTNO9uTobDHRTDXWurKns7vGTjeauw0nRhbtt6vavs/edit >>> > 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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
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/1FnTNO9uTobDHRTDXWurKns7vGTjeauw0nRhbtt6vavs/edit >> > 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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
Hi, Alejandro Serrano Mena wrote: > 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). http://www.haskell.org/haskellwiki/Haskell_web_toolkit - In memoriam ;) Feel free to use these ideas. It would be nice if you could pick it up and complete - I never did... -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
On 7 March 2012 06:14, Bardur Arantsson wrote:
> 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);
Right, that's one of the ones I picked up in HJavascript. Didn't
realise (or remember) it was present in HJScript, supposing that it
had its own pretty printer. Other stuff like this is present in the
HJavascript GADT.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
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,
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
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 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, if you want a reader transformer or whatnot (i.e. to carry around some state, a JS "object"), it breaks down with any higher-order combinators taking actions as arguments. I also had some problems making things generic AND type-accurate, but I don't recall them well enough now. Problems aside, At Least It's Partially Well Typed. I tried UHC out recently, made a little API for the canvas tag and drew some pretty things. Had a little trouble with timers, though… the callback for the timer /worked/, but the alert[1] printed the same thing every time, as if the thunk forcing is somehow broken. I looked at the outputted code but couldn't quite grok what was wrong with it. Didn't get more time to investigate why. It may just be my code but it looks sound to me, though I'm mostly winging it with the HTML5 part. Anyway, look forward to watching ideas and work in this area. Ciao! [1]: module Main where import Control.Monad import Language.UHC.JScript.Assorted import Language.UHC.JScript.W3C.HTML5 import Language.UHC.JScript.ECMA.String import Language.UHC.JScript.ECMA.Date import Language.UHC.JScript.Types import Language.UHC.JScript.Primitives import Data.IORef main = do doc <- document bodies <- documentGetElementsByTagName doc (toJS "canvas") body <- nodeListItem bodies 0 ctx <- getContext body "2d" setFillStyle ctx "rgb(200,0,0)" start <- newIORef 0 setInterval 1000 $ do st <- readIORef start forM_ [st..st+30] $ \i -> do let ir = fromIntegral i fillRect ctx (20 + 10*round (sin ir)) (i*10) 2 2 writeIORef start (st + 1) alert (show st) return () In HTML5.hs: data Timer foreign import jscript "setInterval(%*)" _setInterval :: FunPtr (IO ()) -> Int -> IO Timer foreign import jscript "wrapper" makeIntervalCallback :: IO () -> IO (FunPtr (IO ())) setInterval delay haskellCallback = do jsCallback <- makeIntervalCallback haskellCallback _setInterval jsCallback delay ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
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/1FnTNO9uTobDHRTDXWurKns7vGTjeauw0nRhbtt6vavs/edit >> > 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
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
My first impression on this is that it seems a little vague, but possibly promising. I'd make it clearer that you plan to contribute to the existing UHC stuff. A first glance left me with the impression that you wanted to re-implement a JavaScript back end, which would of course be a non-starter as a GSoC project. Since the actual proposal is to work on the build system and libraries surrounding the existing UHC back end, I'd maybe suggest revising the proposal to be clearer about that, and more specific about what parts of the current UHC compiler, build system, and libraries you propose working on. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
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/1FnTNO9uTobDHRTDXWurKns7vGTjeauw0nRhbtt6vavs/edit > > 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
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
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/1FnTNO9uTobDHRTDXWurKns7vGTjeauw0nRhbtt6vavs/edit > 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
[Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
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/1FnTNO9uTobDHRTDXWurKns7vGTjeauw0nRhbtt6vavs/edit 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
