Proposal: New "Haskell Compiler Group"

Haskell Foundation
#1

In a previous post I tried to explain of how I see a way to drive the evolution of the Haskell language by technical rules when developing core libraries. I used there the unspecified term “base library maintainers”. Now I want to concretize it some more how I would see it.

I would suggest this would be a new “Haskell Compiler Group”. Members of this group can be representants of different Haskell compiler developer teams, each of which provides their own implementation of the same base API. This group should also be open for people interested in writing their own compiler.

Tasks of this group could be:

  • Definition of new language standards at longer time intervalls
  • Preserve the base API in between release cycles of a new language standard
  • Issues with the base API are reported to this group
  • Providing support for alternate implementations when there are feature requests
  • When creating a new language standard:
    • Collect which features from base are used how often in the core libraries
    • Evaluating the feature requests for practical feasibility
    • Deprecate obsolete features in base

The group would be not responsible for portability issues to different target platforms, as each compiler devoloper team can therefore have different solutions.

The term “Haskell Compiler Group” was chosen deliberately. Another designation such as “Haskell Language Group” would perhaps lead to a bunch of language features requests being brought to this group from everywhere.

We would then have a total of three groups:

  • Haskell Compiler Group: responsible for the language specification and therefore the API of the base library
  • Haskell Core Libraries Committee: responsible for standards in the core libraries
  • Haskell Foundation Stability Working Group: responsible for stability of the whole ecosystem with tooling and libraries

Certainly the establishment of such a new group must be coordinated with the other two groups. The Haskell Foundation as the head organization of Haskell should give green light. The coordination with the Core Libraries Commitee is also necessary, because they currently state to be responsible for API changes of the base package.

1 Like
#2

Thank you for this proposal. Could you outline why you feel that the GHC Steering Committee doesn’t fulfil your expectations, which led you to write this? :slight_smile:

1 Like
#3

To be honest, I didn’t have the GHC Steering Committee in mind. It’s not so present in perception.

Also I think Haskell has reached a spread for commercial and private uses, that the language shouldn’t be defined by one compiler developer group. The way things are going is that programs get bigger over time, and therefore harder to maintain. GHC is no exception here. I think this would be a way to make Haskell better prepared for the future. I wouldn’t mind if the current GHC steering committee was simply rebranded to signalize that it’s not GHC specific.

#4

This would be the sort of thing that made sense if there was more than one Haskell compiler under active development and in use. But for many years now, there has been, in practice, only GHC. Creating a structure suited to a situation that does not exist does not make a ton of sense.

5 Likes
#5

The core libraries committe is not responsible for this and does not maintain core libraries: https://github.com/haskell/core-libraries-committee#core-libraries

1 Like
#6

Where did I see it…there it is! Since you’re interested in Haskell2010:

https://downloads.haskell.org/~ghc/7.0.1/docs/html/users_guide/release-7-0-1.html

So gather some friends together, make a private fork of GHC 7.0.1 and have some fun!

…oh wait - it’s New “Haskell Compiler Group”, not New Haskell Compiler Group (darn).

#7

There are other compilers that are more or less compliant to Haskell2010. So maybe their developers want a say too.

Also who states that software always must be under active development? There is famous software which is considered as “finished”. Examples are SQlite and Tex. That’s possible because of fixed APIs.

#8

Which compilers? Did you contact them?

2 Likes
#9

Didn’t contact anyone. But you can find this page.

Also AntC2 wrote this week in his post:
“As at 2010, all Haskell compilers supported extensions beyond the 2010 standard – there just wasn’t enough agreement about which extensions were ‘standard enough’.”

I think for Haskell’s acceptance it would be more important to stick to a standard over a longer period than everyone trying to achieve the perfect language. If there’s a consensus in the group, fine, then you can extend the language. If not, leave it outside. Benefit of this: Standard keeps small.

By the way: The reason that “ugly C” (like some say) is so widely adopted in the industry is their standard, which you have a lot of compilers for. As a commercial user you need alternative solutions if something goes wrong.

#10

I understand your perspective, but I want to reiterate an above point that, for almost all intents and purposes, there is only one compiler for Haskell.

C has history because C was reimplemented many times for different architectures, instruction sets, and UX experiences. Every company had they’re own implementation.

Haskell doesn’t have that problem today. As much as AntC2 might keep mentioning “other compilers”, they are basically non-existent. eta is unmaintained, GHCJS is being upstreamed, Frege is not a serious language, I’ve never seen someone besides AntC2 mention Hugs post-2020.

Hopefully some day there will be competing compilers and a requirement for a new standard. But that time is not today. You’re also going to find almost no interest in a standard today, because Haskell is making a big shift into ergonomic dependent types. Certainly full dependent types (i.e. relevant types) might not happen soon, but visible dependent types and some amount of value-relevance is sneaking its way into the language (see this GHC proposal).

Any standardization today would:

  1. Not address a specific need - there is only one compiler that is used in practice
  2. Take a long time. Most are not interested in this effort, and given how much Haskell changes, you would be constantly fighting to keep up.
  3. Probably just look like the GHC documentation

I really urge you to think about what problem you would be solving. Besides AntC2, are any industrial users actually complaining about only having one compiler? Many large companies fork GHC for various reasons - what is the motivation for this? I suspect the motivation is not one of GHC lacking in features, but specialized needs. Take for example Mu at Standard Charter, which is a strict version of Haskell - that’s not an “alternative compiler”.

Another problem is that some things are just plain unspecified. Almost all Haskell codebases contain some type of type family by now. But the evaluation of type families is pretty notorious. So perhaps getting a standardized type family evaluation schema would be a better use of time?

4 Likes