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
+1, better cabal support for UHC's JS backend would be a big win.
Daniel
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
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
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
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
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
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
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
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
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 jpmores...@gmail.com wrote:
Maybe I'll sound like an overused meme, but what about JQuery? JQuery
already takes a combinator-like
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
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
On Wed, Mar 7, 2012 at 11:47 AM, Alejandro Serrano Mena
trup...@gmail.com 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
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
On Tue, Mar 6, 2012 at 11:40 PM, Alejandro Serrano Mena
trup...@gmail.com 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
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
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
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
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:
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
On 7 March 2012 06:14, Bardur Arantsson s...@scientician.net 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
21 matches
Mail list logo