http://vir.mskhug.ru/

And as a Yhc backend it is a work in progress, it is in deep alpha stage now.

http://haskell.org/haskellwiki/Yhc/Javascript

This is a work in progress though and far from being final, but many of the thoughts expressed in the original post slowly come true.

And I don’t know if we really need strong typing on the client side for webapps. I mean, it’s a lot about manipulating the DOM tree, i.e. data the compiler does not understand anyway.

As for portability, it is not a language issue. Let every web browser editor make his own haskell interpretor and you won’t find it that reliable anymore…

Finally, performance : have a look at common lisp or Lua. You’ll see bad performance is not linked to dynamic typing. Sure, they’re not as fast as light, but that’s enough for client-side webapps I guess.

Yes, Haskell is a great language, and developping client-side javascript is a painful experience. But I’m not sure we’ll see Haskell in firefox very soon. I won’t hold my breath here.

Haskell is a purely functional language in which all side-effectful operations including network and disk access take place outside of the language itself, but are presented to Haskell through a special construct called a monad, which (among other things) allows you to sequence operations through a form of function composition.

Given that Haskell is based upon the lambda calculus and (as shown by Jonathan Rees with Scheme) it’s possible to build a security kernel with lambda calculus by controlling which functions or procedures are shared through environments, it shouldn’t be too hard to construct such a kernel for mobile Haskell code by having it run in a special environment where only safe operations are provided — for example, by providing a special version of the IO monad.

Of course, it’s possible to commit DoS attacks with even pure functional code by constructing enough objects to chew up all available memory. Preventing that from happening is a responsibility of the runtime, as with Java.