>
> 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
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
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 w
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
c
+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 v
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
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
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 ve
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 w
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
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 an
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 J
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 an
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
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.or
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/ameli
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 seri
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 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
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 i
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 mak
21 matches
Mail list logo