4 ms·

For people new to the party, this looks great. For those who had been following the GHCVM project, it's a horrible disappointment. Basically, this project used

by moomin 10y ago

For people new to the party, this looks great. For those who had been following the GHCVM project, it's a horrible disappointment. Basically, this project used to be a fork of the Haskell compiler to support the JVM. Now it's a fork of the Haskell compiler that may or may not be compatible for your use case depending on their opinion of GHC's features.

rahulmutt 10y ago
We maintain quite a bit of compatibility, which is why we have access to the wonderful, but dependency-heavy lens library. See the Eta Playground for an example.
abiox 10y ago
> For people new to the party, this looks great. For those who had been following the GHCVM project, it's a horrible disappointment. maybe it's for the best? a ghc-is-the-spec approach to developing a haskell implementation seems... well, perhaps convenient, but less hygienic for the overall language. (that said i don't actually know what eta's philosophy here is.)
- Buttons840 10y ago
  Eta will still be "Haskell" because they conform to the language spec, even if they don't have all the features of the latest version of GHC (the flagship Haskell compiler). I agree with the grandparents disappointment somewhat though. At the very least there is still room for someone to build a JVM compatible backend for GHC, since this is no longer a goal of Eta.
willtim 10y ago
I don't think it is necessarily a bad thing if they remain Haskell 2010 compliant and use pragmas for their own extensions. I certainly would like to see features like extensible records and variants; and this is unlikely to happen anytime soon in GHC, as the focus seems to be dependent types.
- rahulmutt 10y ago
  This is exactly the direction we're going. I'm a big fan of extensible records/variants. We'll be supporting the GHC 8 extensions that are orthogonal to the type system refactoring like Strict, StrictData, etc. pretty much everything other than TypeInType.
  - willtim 10y ago
    Exciting stuff! The JVM really needs a modern statically typed functional language.
- moomin 10y ago
  I'd say the focus (as always) is on making GHC a better compiler. Join points, levity polymorphism and the new typeable improvements are all in that category. And there's an amazing amount of stuff under the hood in 8.2. Dependent types? 8.6, 8.4 if they're lucky.
ARussell 10y ago
I'm confused. Isn't Eta the new name for GHCVM? https://github.com/typelead/eta/commit/76cdf91843ad679bcb44168e1f0b7fa5fc6bad4f https://github.com/typelead/eta/commit/76cdf91843ad679bcb441...

by moomin 10y ago

rahulmutt 10y ago

We maintain quite a bit of compatibility, which is why we have access to the wonderful, but dependency-heavy lens library. See the Eta Playground for an example.

abiox 10y ago

> For people new to the party, this looks great. For those who had been following the GHCVM project, it's a horrible disappointment. maybe it's for the best? a ghc-is-the-spec approach to developing a haskell implementation seems... well, perhaps convenient, but less hygienic for the overall language. (that said i don't actually know what eta's philosophy here is.)

Buttons840 10y ago
Eta will still be "Haskell" because they conform to the language spec, even if they don't have all the features of the latest version of GHC (the flagship Haskell compiler). I agree with the grandparents disappointment somewhat though. At the very least there is still room for someone to build a JVM compatible backend for GHC, since this is no longer a goal of Eta.

willtim 10y ago

I don't think it is necessarily a bad thing if they remain Haskell 2010 compliant and use pragmas for their own extensions. I certainly would like to see features like extensible records and variants; and this is unlikely to happen anytime soon in GHC, as the focus seems to be dependent types.

rahulmutt 10y ago
This is exactly the direction we're going. I'm a big fan of extensible records/variants. We'll be supporting the GHC 8 extensions that are orthogonal to the type system refactoring like Strict, StrictData, etc. pretty much everything other than TypeInType.
- willtim 10y ago
  Exciting stuff! The JVM really needs a modern statically typed functional language.
moomin 10y ago
I'd say the focus (as always) is on making GHC a better compiler. Join points, levity polymorphism and the new typeable improvements are all in that category. And there's an amazing amount of stuff under the hood in 8.2. Dependent types? 8.6, 8.4 if they're lucky.

ARussell 10y ago

I'm confused. Isn't Eta the new name for GHCVM? https://github.com/typelead/eta/commit/76cdf91843ad679bcb44168e1f0b7fa5fc6bad4f https://github.com/typelead/eta/commit/76cdf91843ad679bcb441...