ghc-proposals VS Cabal

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

Yeah, a relatively natural thing would be to be able to opt-in to having the HasField instances be available in all contexts. The (not yet implemented, but accepted) "Modifiers" GHC proposal might be nice for that.

The local modules proposal imo is excellent as-is.

Why would you drop TypeFamilies? It seems fairly popular, given that it was just one vote short of getting added to GHC2021. Do you consider it a less-ideal compromise, that is subsumed by your second proposal (Core with GRTT)?

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

This looks great, congratulations on completing it! I assume you didn’t get an opportunity to evaluate the delimited continuations based eff library? It would’ve been nice to see Cont included as one of the effects covered, though perhaps not available in all the systems you looked at? Maybe some future work.

I do hope qualified exports are available someday: https://github.com/ghc-proposals/ghc-proposals/pull/283

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.

Also, there's already a cabal RFC to support toml: https://github.com/haskell/cabal/issues/7548

Cabal has a lot of dark corners once you stray from the happy path. Just checked and I'm currently subscribed to 37 threads on the issue tracker, and I'm not a maintainer. A lot of these are related to lesser-used features like cabal scripts, environment files and doctests (though I think all of these things would used more if they were more reliable), but there's also plenty of stupid stuff like: - https://github.com/haskell/cabal/issues/3313 - https://github.com/haskell/cabal/issues/8527 - https://github.com/haskell/cabal/issues/8391 - https://github.com/haskell/cabal/issues/7789 - https://github.com/haskell/cabal/issues/6888 - https://github.com/haskell/cabal/issues/6999 - https://github.com/haskell/cabal/issues/5271

Given that Mike Pilgrim (the Stack maintainer) is on Windows, and Cabal has issues on Windows, I think it might be easier to get Windows specific fixes merged in Stack.

The error message is not too helpful. This is the target of a long-standing ticket: https://github.com/haskell/cabal/issues/7993 Your help would be very welcome.

By the way, there are some open issues for the command to add a package in Cabal.

That's interesting. Could you could open a an issue about this? https://github.com/haskell/cabal/issues

I created this issue a few months ago: https://github.com/haskell/cabal/issues/8270

Reported this as a bug in cabal.

We definitely plan to have benchmarks once we start working on performance. We haven't started yet because there were more urgent tasks. For example: ensuring that the testsuite runs on CI with the JS backend (should be completed this week or the next), ensuring that the toolchain works properly (we're writing a tutorial and we've found new bugs, e.g. yesterday I've fixed the support for js-sources in Cabal https://github.com/haskell/cabal/pull/8636), adding TH support...