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

Jason Dusek jason.dusek at gmail.com
Sat Apr 25 13:53:16 EDT 2009


  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


More information about the Haskell-Cafe mailing list