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