GHC2024 – community input

#95

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
#96

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?

#98

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.

#99

Was this post sponsored by Big Syntax?

7 Likes
#100

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

#101

…but there’s still that matter of simplicity:

#102

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
#103

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
#104

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

#105
1 Like
#106

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.

#107

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
#108

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…

#109

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.

#110

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

Hrm:

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

#111

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

1 Like
#112

It isn’t about being “cryptic” but not being overly repetitive, as I’ve made the point elsewhere:

Thus far, there hasn’t been a thread here topical enough for a more a more blunt direct assessment (or opinion) of the matter, so I “keep it light”…

#113

A further data point regarding languages with idiom brackets is Lean. Here’s findM from the other day:

@[inline]
def findM? {α : Type} {m : Type → Type} [Monad m] (as : Array α) (p : α → m Bool) : m (Option α) := do
  for a in as do
    if (← p a) then
      return a
  return none

(← p a) here is pretty much Idris’s ! notation. E.g., lift any pure expression in a do block to be effectful. do if (← mb) then (← mt) else (← mf) is the same as do b <- mb; t <- mt; f <- mf; pure (if b then t else f), which also highlights an obvious pitfall wrt. effect strictness.

#114

The URLs are now broken. Is there a new URL for this?

#115
1 Like