9 ms·

GHCJS - Haskell in the Browser

139 points by wtetzner 13y ago

wslh 13y ago
Excellent, but where is the "try now" link to test in the browser?
- carterschonwald 13y ago
  That's partly the point of the student's gsoc pastebin like project! Luite also has a vagrant image available that has a working ghcjs patched build available for down load.
- luite 13y ago
  I want that too! Dan Frumin is working on a GSoC project that uses GHC, GHCJS and diagrams to make a "try now" pastebin site with graphics. Unfortunately, GHCJS is not quite Safe Haskell code, so we are still working on sandboxing the compiler with SELinux. his weblog, more updates will follow: http://parenz.wordpress.com/ http://parenz.wordpress.com/
sfvisser 13y ago
Note that they have almost the entire runtime working, including the threading model, which allows you to fork threads, use MVars, perform STM, etc. Truly awesome and very promising.
- carterschonwald 13y ago
  Exactly! As I understand it, the moment js gets nice things like tail calls or concurrency, with very little work ghcjs can too! I'm really really excited.
  - yoklov 13y ago
    Unfortunately, tail calls can't be implemented without breaking JS semantics. See: http://code.google.com/p/v8/issues/detail?id=457 http://code.google.com/p/v8/issues/detail?id=457 .
    - carterschonwald 13y ago
      Well then I dream of a day when an ecmascript revision makes the breaking changes needed to fix this. Or some sort of clever hack works around that constraint
      - luite 13y ago
        The change is proposed for ECMAScript 6: http://wiki.ecmascript.org/doku.php?id=harmony:proper_tail_calls http://wiki.ecmascript.org/doku.php?id=harmony:proper_tail_c... GHCJS currently uses a trampoline, but all calls are in tail position, so when this gets implemented we can easily generate code that uses native JS tail calls. Like GHC, GHCJS uses its own stack for non-tail calls.
        carterschonwald 13y ago
        I think native code GHC has its stack in the standard location, though it manages it explicitly (as most native code languages do). (I'll double check the ghc source later to make sure i'm quibbling correctly)
    - ethzero 13y ago
      You don't need tail calls in JavaScript in order have them in a language that compiles to JS. The tail call can be compiled as a while loop. This is what Scala does on the JVM (and presumably what Scala.js does as well).
      - amalcon 13y ago
        This only works with calls that can be resolved at compile time (unless you mean a trampoline). That happens to be most of the common use, which is great, but it's not perfect. Trampolines still work, albeit with a pretty substantial perf penalty.
    - colanderman 13y ago
      No. Automatic tail call elimination can't be implemented without breaking JS semantics. Manual tail calls can perfectly well be implemented without breaking anything.
- wslh 13y ago
  Is incredible that we don't have an Android or iOS Haskell interpreter but we can run it on an embedded browser first.
  - joeyh 13y ago
    There are ports of ghc to both Android and IOS. I've run ghc directly on Android. ghci not so much, so you're technically right about there being no interpreter.
    - geal 13y ago
      That's awesome! I have played a lot with Scala and Android, and type safety, options, futures really improved the development on Android (less code, less bugs). I would be curious to try Haskell on that platform.
  - efnx 13y ago
    I hear ARM support will be standard in the next GHC, and there currently are ports and cross-compilers. Unless you're specifically talking about ghci, which I agree needs to be ported, though that hasn't happened for the browser yet. It's possible a project like this could help that happen, though... http://hackage.haskell.org/trac/ghc/wiki/Building/CrossCompiling http://hackage.haskell.org/trac/ghc/wiki/Building/CrossCompi... https://github.com/ghc-ios/ghc https://github.com/ghc-ios/ghc
    - wslh 13y ago
      I am looking to the gchi because it's mainly to play and learn . I think a mobile/tablet is a nice environment to do that.
- colanderman 13y ago
  fork threads, use MVars, perform STM As someone who is very familiar with purely functional languages and with multiprocessor synchronization, I must ask, why would anyone want to use any of these things in Haskell? Aren't two of the primary benefits of Haskell the ability to auto-parallelize, and not needing to reason about state?
  - chongli 13y ago
    Haskell doesn't have auto-parallelism. There are some excellent libraries for parallelism (strategies, DPH, repa) but they take some work. True auto-parallelism (a la Parasail) is far more difficult to get right (often due to granularity of work units).
    - colanderman 13y ago
      Mercury does a decent job of this (not quite auto-parallelism, you need to hint at parallelization points, but it manages granularity for you).
  - Peaker 13y ago
    "Purely functional" is a misnomer. A better description is "typed effects". Haskell doesn't forego effects, it types them. You still have imperative destructive updates if you need them (e.g: to avoid a logarithmic complexity hit, or a constant performance hit). You still may want to write imperative programs, often-times as the backend of a pure functional interface. Haskell is actually quite good at it, and jokingly referred to as "the world's finest imperative language".
tome 13y ago
I really hope never to have to write Javascript again.
pekk 13y ago
Where are all the people saying that we should only ever use Javascript in the browser? Mysteriously missing now that the language discussed is Haskell?
- recursive 13y ago
  We should only ever use javascript in the browser.
  - efnx 13y ago
    And maybe not even there =P
joeyh 13y ago
There's also Fay <https://github.com/faylang/fay/wiki> https://github.com/faylang/fay/wiki> which provides a lighter-weight compilation of Haskell to JS, omitting stuff like threading and type classes. Nice thing about Fay is you can read the generated javascript and see the 1:1 correspondance to the haskell code. This can be a nice way to get an intuition abvout how thunks are used to implement eg, infinite length lazy lists in haskell. There is also a live IDE <http://ide.fay-lang.org/> http://ide.fay-lang.org/>. I think this makes Fay an excellent teaching tool. The way it seems to be shaping up is that ghcjs will be used for big serious projects where a javascript runtime that is measured in (IIRC) megabytes is acceptable and the full power of haskell is needed. While fay will be used as glue code for projects that are mostly written in server side Haskell and want to run some code in the browser, with access to the same types used on sever-side to eg, make AJAX nicer. Fay's entire runtime is 16 kb (unminified; with minification and other size optimisations a complete program can be as small as 3 kb) <https://github.com/faylang/fay/blob/master/js/runtime.js> https://github.com/faylang/fay/blob/master/js/runtime.js> which makes it work well in these niches.
- tome 13y ago
  I never really understood how Fay users could avoid using typeclasses, since it means (presumably) avoiding functors, applicatives, monads and all that other Haskelly stuff.
  - tel 13y ago
    Typeclasses provide nothing but convenience there (see [1] for instance). The real power comes from the Algebraic Data Types which are intact. [1] http://www.haskellforall.com/2012/05/scrap-your-type-classes.html http://www.haskellforall.com/2012/05/scrap-your-type-classes...
    - colanderman 13y ago
      I don't see how that mechanism provides subtyping (which typeclasses do)? Last I checked Haskell's structures weren't structurally typed.
ocharles 13y ago
There is another option to GHCJS and Fay now - Sunroof (http://www.ittc.ku.edu/csdl/fpg/software/sunroof.html http://www.ittc.ku.edu/csdl/fpg/software/sunroof.html) - which is entirely inside Haskell - no compiler needed other than GHC.

139 points by wtetzner 13y ago

wslh 13y ago

Excellent, but where is the "try now" link to test in the browser?

carterschonwald 13y ago
That's partly the point of the student's gsoc pastebin like project! Luite also has a vagrant image available that has a working ghcjs patched build available for down load.
luite 13y ago
I want that too! Dan Frumin is working on a GSoC project that uses GHC, GHCJS and diagrams to make a "try now" pastebin site with graphics. Unfortunately, GHCJS is not quite Safe Haskell code, so we are still working on sandboxing the compiler with SELinux. his weblog, more updates will follow: http://parenz.wordpress.com/ http://parenz.wordpress.com/

sfvisser 13y ago

Note that they have almost the entire runtime working, including the threading model, which allows you to fork threads, use MVars, perform STM, etc. Truly awesome and very promising.

carterschonwald 13y ago
Exactly! As I understand it, the moment js gets nice things like tail calls or concurrency, with very little work ghcjs can too! I'm really really excited.
- yoklov 13y ago
  Unfortunately, tail calls can't be implemented without breaking JS semantics. See: http://code.google.com/p/v8/issues/detail?id=457 http://code.google.com/p/v8/issues/detail?id=457 .
  - carterschonwald 13y ago
    Well then I dream of a day when an ecmascript revision makes the breaking changes needed to fix this. Or some sort of clever hack works around that constraint
    - luite 13y ago
      The change is proposed for ECMAScript 6: http://wiki.ecmascript.org/doku.php?id=harmony:proper_tail_calls http://wiki.ecmascript.org/doku.php?id=harmony:proper_tail_c... GHCJS currently uses a trampoline, but all calls are in tail position, so when this gets implemented we can easily generate code that uses native JS tail calls. Like GHC, GHCJS uses its own stack for non-tail calls.
      - carterschonwald 13y ago
        I think native code GHC has its stack in the standard location, though it manages it explicitly (as most native code languages do). (I'll double check the ghc source later to make sure i'm quibbling correctly)
  - ethzero 13y ago
    You don't need tail calls in JavaScript in order have them in a language that compiles to JS. The tail call can be compiled as a while loop. This is what Scala does on the JVM (and presumably what Scala.js does as well).
    - amalcon 13y ago
      This only works with calls that can be resolved at compile time (unless you mean a trampoline). That happens to be most of the common use, which is great, but it's not perfect. Trampolines still work, albeit with a pretty substantial perf penalty.
  - colanderman 13y ago
    No. Automatic tail call elimination can't be implemented without breaking JS semantics. Manual tail calls can perfectly well be implemented without breaking anything.
wslh 13y ago
Is incredible that we don't have an Android or iOS Haskell interpreter but we can run it on an embedded browser first.
- joeyh 13y ago
  There are ports of ghc to both Android and IOS. I've run ghc directly on Android. ghci not so much, so you're technically right about there being no interpreter.
  - geal 13y ago
    That's awesome! I have played a lot with Scala and Android, and type safety, options, futures really improved the development on Android (less code, less bugs). I would be curious to try Haskell on that platform.
- efnx 13y ago
  I hear ARM support will be standard in the next GHC, and there currently are ports and cross-compilers. Unless you're specifically talking about ghci, which I agree needs to be ported, though that hasn't happened for the browser yet. It's possible a project like this could help that happen, though... http://hackage.haskell.org/trac/ghc/wiki/Building/CrossCompiling http://hackage.haskell.org/trac/ghc/wiki/Building/CrossCompi... https://github.com/ghc-ios/ghc https://github.com/ghc-ios/ghc
  - wslh 13y ago
    I am looking to the gchi because it's mainly to play and learn . I think a mobile/tablet is a nice environment to do that.
colanderman 13y ago
fork threads, use MVars, perform STM As someone who is very familiar with purely functional languages and with multiprocessor synchronization, I must ask, why would anyone want to use any of these things in Haskell? Aren't two of the primary benefits of Haskell the ability to auto-parallelize, and not needing to reason about state?
- chongli 13y ago
  Haskell doesn't have auto-parallelism. There are some excellent libraries for parallelism (strategies, DPH, repa) but they take some work. True auto-parallelism (a la Parasail) is far more difficult to get right (often due to granularity of work units).
  - colanderman 13y ago
    Mercury does a decent job of this (not quite auto-parallelism, you need to hint at parallelization points, but it manages granularity for you).
- Peaker 13y ago
  "Purely functional" is a misnomer. A better description is "typed effects". Haskell doesn't forego effects, it types them. You still have imperative destructive updates if you need them (e.g: to avoid a logarithmic complexity hit, or a constant performance hit). You still may want to write imperative programs, often-times as the backend of a pure functional interface. Haskell is actually quite good at it, and jokingly referred to as "the world's finest imperative language".

tome 13y ago

I really hope never to have to write Javascript again.

pekk 13y ago

Where are all the people saying that we should only ever use Javascript in the browser? Mysteriously missing now that the language discussed is Haskell?

recursive 13y ago
We should only ever use javascript in the browser.
- efnx 13y ago
  And maybe not even there =P

joeyh 13y ago

There's also Fay <https://github.com/faylang/fay/wiki> https://github.com/faylang/fay/wiki> which provides a lighter-weight compilation of Haskell to JS, omitting stuff like threading and type classes. Nice thing about Fay is you can read the generated javascript and see the 1:1 correspondance to the haskell code. This can be a nice way to get an intuition abvout how thunks are used to implement eg, infinite length lazy lists in haskell. There is also a live IDE <http://ide.fay-lang.org/> http://ide.fay-lang.org/>. I think this makes Fay an excellent teaching tool. The way it seems to be shaping up is that ghcjs will be used for big serious projects where a javascript runtime that is measured in (IIRC) megabytes is acceptable and the full power of haskell is needed. While fay will be used as glue code for projects that are mostly written in server side Haskell and want to run some code in the browser, with access to the same types used on sever-side to eg, make AJAX nicer. Fay's entire runtime is 16 kb (unminified; with minification and other size optimisations a complete program can be as small as 3 kb) <https://github.com/faylang/fay/blob/master/js/runtime.js> https://github.com/faylang/fay/blob/master/js/runtime.js> which makes it work well in these niches.

tome 13y ago
I never really understood how Fay users could avoid using typeclasses, since it means (presumably) avoiding functors, applicatives, monads and all that other Haskelly stuff.
- tel 13y ago
  Typeclasses provide nothing but convenience there (see [1] for instance). The real power comes from the Algebraic Data Types which are intact. [1] http://www.haskellforall.com/2012/05/scrap-your-type-classes.html http://www.haskellforall.com/2012/05/scrap-your-type-classes...
  - colanderman 13y ago
    I don't see how that mechanism provides subtyping (which typeclasses do)? Last I checked Haskell's structures weren't structurally typed.

ocharles 13y ago

There is another option to GHCJS and Fay now - Sunroof (http://www.ittc.ku.edu/csdl/fpg/software/sunroof.html http://www.ittc.ku.edu/csdl/fpg/software/sunroof.html) - which is entirely inside Haskell - no compiler needed other than GHC.