Hacker News Reader

Comment by sfvisser | Hacker News Reader

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.

View on HN

Is incredible that we don't have an Android or iOS Haskell interpreter but we can run it on an embedded browser first.

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/CrossCompi... https://github.com/ghc-ios/ghc

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.

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.

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.

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.

Unfortunately, tail calls can't be implemented without breaking JS semantics. See: http://code.google.com/p/v8/issues/detail?id=457 .

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

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.

No. Automatic tail call elimination can't be implemented without breaking JS semantics.

Manual tail calls can perfectly well be implemented without breaking anything.

Of course! The parent mentioned JS getting them however, which is, as I mentioned, impossible.

Yeah, just add goto!

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.

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

The change is proposed for ECMAScript 6: 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.

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)

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?

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

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

Mercury does a decent job of this (not quite auto-parallelism, you need to hint at parallelization points, but it manages granularity for you).

Reply on news.ycombinator.com