4 ms·

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 awes

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.
    - chongli 13y ago
      Yeah, just add goto!
      - colanderman 13y ago
        Yes, add goto. If JS is going to be the "assembly language of the web", it needs a general branch construct or it will suck.
    - yoklov 13y ago
      Of course! The parent mentioned JS getting them however, which is, as I mentioned, impossible.
      - deleted 13y ago
        [deleted]
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".

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.
  - chongli 13y ago
    Yeah, just add goto!
    - colanderman 13y ago
      Yes, add goto. If JS is going to be the "assembly language of the web", it needs a general branch construct or it will suck.
  - yoklov 13y ago
    Of course! The parent mentioned JS getting them however, which is, as I mentioned, impossible.
    - deleted 13y ago
      [deleted]

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