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 JavaScript.

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!

Regards,

John A. De Goes
N-BRAIN, Inc.
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@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

Reply via email to