ghc-proposals VS ghc-proposals

Looks like (https://github.com/adamgundry/ghc-proposals/blob/hasfield-redesign/proposals/0000-hasfield-redesign.rst) got a fair bit of work done on it around the time of ZuricHack which is consistent with the author's plans as stated here: (https://mail.haskell.org/pipermail/ghc-steering-committee/2022-May/002782.html)

The short answer is that the design is still not finalised as far as I'm concerned. I'm in the process of breaking up my over-large redesign proposal draft (https://github.com/adamgundry/ghc-proposals/blob/hasfield-redesign/proposals/0000-hasfield-redesign.rst) into more manageable pieces. This included two proposals shipped during ZuriHac (https://github.com/ghc-proposals/ghc-proposals/pull/515 and https://github.com/ghc-proposals/ghc-proposals/pull/516). Key next steps are a proposal to have separate HasField like classes for selection and update, and then adding type-changing update (for which I've been exploring adapting functional dependencies, see https://gitlab.haskell.org/ghc/ghc/-/issues/21779).

Here is a discussions https://github.com/adamgundry/ghc-proposals/blob/hasfield-redesign/proposals/0000-hasfield-redesign.rst

Please could you elaborate on the problems? Does the redesign I'm sketching in the draft https://github.com/adamgundry/ghc-proposals/blob/hasfield-redesign/proposals/0000-hasfield-redesign.rst address them?

> I think Haskell needs a way to graduate (or retire) language extensions

https://github.com/ghc-proposals/ghc-proposals/pull/601

Additionally, while this proposal is focused on the simple implementation and so in the current proposal or patterns do not bind any variables as per #522, if we do get settled on syntax and then later wish to expand to allow binding variables as in #43, then the syntax is again clean and discoverable.

as syntax is contentious a topic as ever, David (the main proposal author) and I would like to invite you to give your input on https://github.com/ghc-proposals/ghc-proposals/pull/585, where we propose to change the syntax of the accepted proposal #522 introducing Or patterns. In particular, we'd like to know

It's coming: https://github.com/ghc-proposals/ghc-proposals/pull/541

Right. Being able to disable "custom type warnings" at use sites was part of an earlier proposal (https://github.com/ghc-proposals/ghc-proposals/pull/454) but it ended up being shelved.

The lack of concatMap fusion is a notorious issue in stream fusion. I recently implemented Higher Order Patterns in Rewrite Rules which should make it possible to write a rewrite rule for fusing concatMap in GHC 9.8.

The initial proposal was data kind, but in the discussion some people didn't like the word "kind".

I learned about this when proposing multiline strings in Haskell. The convo there might be of interest to you: https://github.com/ghc-proposals/ghc-proposals/pull/569