GHC2024 – community input

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

It seems like that link doesn’t render right any more (possibly because of the reStructuredText issue).

But the rendered version works fine.

#117

I shared this thought initially, but my fervent hope is that GHC20XX will not be de facto “append-only”.

@tbidne This will have maintenance costs for codebases which use GHC20XX, causing problems when transitioning to a newer GHC20XX. I think it’s advisable to avoid it if possible. I get that the future version might enable more extensions, but still removals will cause unnecessary problems. Most of the extensions are quite old and well-known, so informed decisions are at hand to avoid such problems.

1 Like
#118

Definitely need to consider the maintenance cost. However, we simply must be able to move on from experiments or past bad practice. If we consider, for a moment, Haskell2010 to have been a GHC20XX then we already have examples of extensions being removed in CUSKs, DatatypeContexts, and DeepSubsumption. Further, StarIsType seems like a good candidate to remove eventually, usage is already becoming a warning by default in 9.10. If we can’t remove any extension ever, then I’d argue the bar to be included should have been much, much higher for inclusion already.

The language needs to be able to evolve, but must do so in a way to mitigate the pain of the changes. Providing warnings for use is one mechanism for that. We shouldn’t stop there though and explore other ways in which we might make handling changes easier.

4 Likes
#119

This does not match the GHC stability principles afaiu: ghc-proposals/principles.rst at master · ghc-proposals/ghc-proposals · GitHub

A stable package should specify an explicit language edition because subsequent releases of GHC might change the default language edition. So if the package does not pin a specific language edition, it might then fail when compiled with a later release.

So if you want a stable interface: pin the language edition or select the extensions manually.

Otherwise I argue you shouldn’t expect any stability guarantees.

6 Likes
#120

So if you want a stable interface: pin the language edition or select the extensions manually.

Faire point.