GHC2024 – community input

A small tip if @mpilgrem decides to go with this route: HLS features a code action for doing this translation automatically (disclaimer: I wrote it).


I think that would be very helpful in teaching beginners.

It would require a lot of courage (handling the backslash), but if GHC2024 defaulted to sane records using DuplicateRecordFields, OverloadedRecordDot and NoFieldSelectors it would really push the language far.

It takes enormous amount currently to figure out what combinations of extensions are needed to get dot style records.

Anything that breaks among these can be fixed and in the worst case codebases can avoid GHC2024 when needed.


Yeah, I think I said something similar in the GitHub thread, The only real argument against I can think of is that OverloadedRecordUpdate is still not fully implemented. Although whether that really causes any major issues, I’m unsure (it’s difficult to keep track of all the interactions between the record extensions, which is exactly a major reason why it would be nicer if a sensible set were on by default!).

Totally agree with this! This is a small change that could have a big impact for Haskell adoption going forward. Users expect dot style syntax from modern programming languages.

1 Like

Users also tend to expect simple I/O from modern programming languages, as the designers of Rust discovered - where’s the language extension/s for that?

It would require a lot of courage (handling the backslash), but if GHC2024 defaulted to sane records […]

Have you seen the GHC20xx criteria? One criteria is conservativeness, which is defined as backwards compatibility. You say it would be courageous to add these extensions, does that mean that you concede that it wouldn’t be conservative to add them?

Surely you agree that NoFieldSelectors would be a backwards incompatible change. It would be confusing to have a GHC20xx language edition that didn’t adhere to the process.

The ballot was already made, and votes were already cast. How does it makes any sense to propose new extensions for GHC2024 at this point? I think proposals like these are fundamentally unfit for the GHC20xx process since they require all text books to be rewritten, which is not feasible.

Was this post sponsored by Big Syntax?


You don’t need an extension for unsafePerformIO. :wink:

…but there’s still that matter of simplicity:

That’s what I’m implicitly suggesting, there’s a place for the current GHC20xx criteria, but
I would like to see it be expanded beyond the conservativness to take Haskell to a new level - and that requires courage.

1 Like

I’d prefer it if comments about the GHC steering committee’s decisions were harder to interpret as describing them as having demonstrated cowardice. I’m sure you didn’t intend that interpretation, but it is an easy one to make, especially for people less familiar with context.

1 Like

…and the various committee/s responsible for such matters (amongst others) would probably like to see the twelve-year migration plan needed to reach that “new level”.

1 Like

Now that GHC has do-notation for Applicative types:

…are idiom brackets still needed?

As for the monadic-bang annotation:

…Idris is a strict language.

They were never needed; <*> and <$> do the job. But idiom brackets would do the job with less noise. ApplicativeDo does the job with more noise, so I don’t see how that changes things.

1 Like

But how much worse would it be if there were two systems of notation for users to choose from? These days, all monadic type are also applicative…

Probably not at all. We already have a choice between using parentheses or using $, or between using do-notation and using >>=, and I don’t think these are generally regarded as design mistakes.

I doubt GHC is going to get first-class idiom brackets/banged expressions, and I’m not pushing particularly hard for it to happen, but I think they do fill a useful notational niche in a way that is better than do-notation alone can do, and I’d be happy to see them.

We already have a choice between using […] do-notation and using >>= […]


…again, and most likely having experience in languages other than Haskell:

I might understand your point better if you were less cryptic about making it.

1 Like