On Apr 25, 2009, at 13:53 , Jason Dusek wrote:

I'd like to be able to translate Haskell to JavaScript.

http://haskell.org/haskellwiki/Yhc/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

That's not exactly limited; building a self-contained program is easier than producing something that seamlessly adapts between different runtimes with very different notions of how the world works. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

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