[Haskell-cafe] Haskell/JS -- better through typeclasses?

John A. De Goes john at n-brain.net
Sat Apr 25 16:28:34 EDT 2009

I'd like this functionality, as well, but it doesn't exist, at least  
for Haskell.

If you don't need a 100% pure functional language, and don't need the  
bells and whistles of the Haskell type system, you might be interested  
in SML -- a purer relative of the more widely-known Ocaml.

There's a tool for converting SML to JavaScript: http://www.itu.dk/people/mael/smltojs/

It allows you to export SML functions so they can be called by  

Moreover, it has a reactive library built in, does pretty decent  
optimization, lets you manipulate the DOM, and is up to version 4.3.5.  
Haskell doesn't have anything close!


John A. De Goes
The Evolution of Collaboration

http://www.n-brain.net    |    877-376-2724 x 101

On Apr 25, 2009, at 11:53 AM, Jason Dusek wrote:

>  I'd like to be able to translate Haskell to JavaScript.
>  Many Haskell/JS bridges provide libraries for writing complete
>  JavaScript programs in Haskell; some of them even include
>  jQuery. However, my goals are more limited -- I'd like to be
>  able to take a Haskell module and turn it into a JavaScript
>  object. For example, I'd like to write a nice parser in
>  Haskell and then reuse it on the client side. No need to
>  handle all the DOM events or implement multi-threading.
>  Of course, the place to start is by reading the commentary. A
>  little bit of browsing suggests some questions of strategy:
> .  Maybe a new backend is not the right thing? All the backends
>    seem to be for real computers with real instruction sets.
> .  Is it better to just work on transforming Core into JS
>    directly? It seems that "External Core" is still in limbo.
> .  Some translations strike me as baffling in principle. For
>    example, a value like `ones`:
>      ones = 1 : ones
>    We'd want to avoid most native JavaScript containers, it
>    seems; however, we are then unable to leverage the speed of
>    native containers.
>  It's entirely possible that translating Haskell to JavaScript
>  may turn out not to be the best idea; maybe it is better to
>  have a type class for types (for example, `Parser Char`) to
>  provide their own translators? The it would be straightforward
>  to prevent translation of programs that use concurrency libs,
>  native ops or `IO`.
> --
> Jason Dusek
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list