GHC2024 – community input

ozkutuk · January 7, 2024, 5:30pm

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

lylek · January 8, 2024, 3:58am

I think that would be very helpful in teaching beginners.

domenkozar · January 8, 2024, 12:29pm

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.

george.fst · January 8, 2024, 5:41pm

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

mpscholten · January 8, 2024, 5:50pm

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.

atravers · January 8, 2024, 8:56pm

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?

janus · January 9, 2024, 5:25am

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.

ocramz · January 9, 2024, 7:40am

Was this post sponsored by Big Syntax?

ReleaseCandidate · January 9, 2024, 8:44am

You don’t need an extension for unsafePerformIO.

atravers · January 9, 2024, 8:58am

…but there’s still that matter of simplicity:

domenkozar · January 9, 2024, 12:21pm

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.

tomjaguarpaw · January 9, 2024, 12:28pm

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.

atravers · January 9, 2024, 1:07pm

…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”.

googleson78 · January 10, 2024, 1:38pm

github.com/ghc-proposals/ghc-proposals

Borrow some Applicative/Monad syntax from Idris

opened 03:39PM - 28 Jul 22 UTC

Ericson2314

Idris has two syntaxes we don't, idiom brackets and `!`-notation. It might seem …that they overlap with each other and `do` notation too much, but actually I think they are very good in catering to needs at opposite ends of what I might call the "predictability --- magic spectrum". I therefore think both have their own niches and we ought to consider adding both of them. ## Idiom brackets https://docs.idris-lang.org/en/latest/tutorial/interfaces.html#idiom-brackets This is just for `Applicative`, and completely predictable. It also doesn't force naming things so it is less bureaucratic. I would in fact make it more level than Idris: instead of being type directed, have an explicit splice syntax. Then the user can write: ```haskell m_add' :: Maybe Int -> Maybe (Maybe Int) -> Maybe Int m_add' x y = [Applicative| $x + $(join y) |] ``` is lifted to: ```haskell m_add' :: Maybe Int -> Maybe (Maybe Int) -> Maybe Int m_add' x y = (\fresh1 fresh2 -> fresh1 + fresh2) <$> x <*> join y ``` This has very simple and completely predictable (doesn't depend on types or even name resolution) desugaring, and is thus best for those that value predictability more than magic / compiler doing lots of work for the user. ## `!`-notation https://docs.idris-lang.org/en/latest/tutorial/interfaces.html#notation This is on the other end of the spectrum, an extremely minimal syntactic hint to tell the compiler "go figure out the do notation I need to write". Conceptually combine it with `ApplicativeDo` post the de sugaring into do notation (though I imagine it might make sense to combine the algorithms into one pass), and it is even more magic: ```haskell let y = 42 in f !(g !(print y) !x) ``` is lifted to: ```haskell let y = 42 in do y' <- print y x' <- x g' <- g y' x' f g' ``` which can be "optimized" (per `ApplicativeDo`) to ```haskell let y = 42 in do g' <- bind [Applicative| g $(print y) $(x) |] f g' ``` Sure, there is a lot of magic, but there is also so much more power than the sugar we have today. This is also comparable to the `?` or `await` sugar other languages have. In a strict side-effecting languages which already can be thought of elaborating to a "monadic metalanguage", those constructs might seem less magical than in Haskell. But the fact remains that this is the level of convenience people are increasingly used to. Finally, `!` unlike anything else actually provides a way for a hypothetical junior Haskeller to *never* understand what `Applicative` and `Monad` actually are --- "got error? add `!` and try again lol". As much as I am personally strongly in the "don't do what you don't understand camp", Haskell should be a big tent, and we should not actively shun the sort of programmer that is more interested in the destination than the journey. Also, merely unlocking a broader gamut of educational methods to experiment with is also valuable. `do` notation places a barrier in the curriculum that the student must at least sort of vague partial understanding what is going on with `Monad` before they can do IO. `!` places less of a barrier, allowing a even vaguer or more partial understanding to suffice. Whether there is merit of doing IO earlier in the curriculum I cannot say, but with `!` we can have proper apples-to-apples experiments to that end. And it is better to be able do the experiment than just *assume* `do` imposes no constraints on what is regardless the best curriculum.

atravers · January 10, 2024, 2:07pm

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.

rhendric · January 10, 2024, 7:22pm

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.

atravers · January 10, 2024, 9:22pm

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…

rhendric · January 10, 2024, 11:33pm

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.

atravers · January 11, 2024, 12:32am

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

Hrm:

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

rhendric · January 11, 2024, 1:04am

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