[rahulmutt]

Check out the FAQ: http://eta-lang.org/docs/html/faq.html. For the record, I love Haskell as a language and even after solving the tooling and documentation problems, it doesn't solve the integration problem. The JVM is widely used and being on top of it makes it easy to integrate into existing systems. You can certainly reuse code between Eta and Haskell given the number of extensions that are in common.

[js8]

Well, I didn't find the answer to my question in the FAQ. I see where you want to differ from GHC, but I don't see where you want to differ from Haskell standard.

It seems to me that the Eta language is basically Haskell 2010 compliant compiler/runtime (correct me if I am wrong) for JVM.

Which actually is great and useful and I really like that about the project. I just think the project shouldn't be called "another language", but rather "Haskell 2010 compiler with some GHC extensions for the JVM". I actually don't even care if you avoid Haskell in the name, as long as you keep the compatibility.

[rahulmutt]

How Eta's going to differ from the standard is not clear for me either. It's dependent on a lot of factors, such as how GHC decides to evolve and how that affects the usability of the language. The whole point of the name change was to have the choice of not accepting the new features if we felt they weren't ready yet for wide consumption. GHC is a playground for PL research, and SPJ has made that clear on many accounts. It's great for research, but scary for industry adopters. We are focused on industry more than research.

[KirinDave]

I think that's smart.

When we say "Haskell" it's difficult to separate it from "GHC's Haskell" which is a much more confusing beast, full of half-discarded research projects, dependency on offshoot libraries, and a ton of tribal culture.

It's sort of like the CLHS and CLisp vs Clojure.

[harpocrates]

> full of half-discarded research projects, dependency on offshoot libraries, and a ton of tribal culture.

That's a bit harsh. GHC is a pretty old beast and its source isn't as nice as I wish it was (if only imports were qualified and every GHC source file didn't start off with a huge list of imports), but it is hardly as bad as you make it sound. It is pretty darn-well maintained. Heck, it is even one of the examples in "Architecture of Open Source Applications" [0].

That aside, I completely agree with the spirit of your comment.

[0] http://www.aosabook.org/en/ghc.html

[KirinDave]

> That's a bit harsh. GHC is a pretty old beast and its source isn't as nice as I wish it was (if only imports were qualified and every GHC source file didn't start off with a huge list of imports), but it is hardly as bad as you make it sound.

I don't know the degree to which you want to make it sound bad. I think it's just the reality of GHC Haskell. There are many language extensions and while at any given year a given set are normal, as time goes on that set changes. But in many cases, we don't get new libraries that switch to new extensions, so we end up supporting a rather large superset of Haskell in ghc over time.

So while yeah, the GHC codebase itself is fine, the culture and the community providing the library ecosystem has made things challenging.

What's more, some of the core concepts haskellers lean on are just... I dunno. Underbaked? I've used a lot of lens libraries and conduit libraries now and they always feel a bit undercooked.

[js8]

So what it looks like you want to remain compatible with the Haskell 2010 standard, with some conservative extension choices. Unless a new standard of Haskell appears that you choose to disagree with, why not just accept that what you're doing is compiler of standard Haskell? I don't see why abiding to compliance with standard Haskell should be scary for industry adopters, on the contrary.

[pyrale]

SPJ and others acknowledged that the adoption by industry had changed the way of developping Haskell, though, making playground moves less likely if they hurt existing features.