ghc-proposals VS polysemy

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

Thirdly, composing arbitrary effects without losing state is really, really difficult. Things are fine when you limit yourself to State and Reader, sure, but once you start with nondeterminism you’ll discover it’s shockingly easy to produce behaviors that are baffling unless you’ve spent a preposterous amount of time thinking about this stuff. (I’ve been bitten in prod by silent state-dropping bugs, and rarely have I been more flummoxed.) Consider this example, which produces silent changes in the semantics of <|> depending on whether you use it inside or outside of a higher-order effect. Every single effect library (besides the still-unreleased eff) gets certain combinations of effects + nondeterminism wrong. You could make the argument that most people don’t use nondeterministic monads, but eDSLs really shine when you have access to them, as you can turn a concrete interpreter to an abstract one fairly easily.

Looking for a few projects that make use of it, I found accelerate, hawk, polysemy and pretty-simple, so I'll be interested to poke around in their code and see how they have things set up.

Right, I think I'll just give it a shot to see. Polysemy is nice but I'm still having trouble getting what I want out of it (which may very well be entirely a fault of my own understanding)

Languages such as Koka only support algebraic effects, not scoping operations such as catch and listen. The Effect Handlers in Scope paper introduces scoping operations, which lead to the Haskell libraries fused-effects and polysemy, but they turned out to have some weird semantics. eff is her effort to fix that.

Looking at the interpreter for Reader might give some clues if this doesn't work. https://github.com/polysemy-research/polysemy/blob/master/src/Polysemy/Reader.hs#L38-L45

*But I'm not terribly well versed in Scala's other DI offerings. I came from Haskell and didn't find anything in Scala that clicked with me until I found ZIO. It reminded me a lot of my favorite way of writing Haskell programs (https://github.com/polysemy-research/polysemy)—albeit with a completely different implementation.