penrose VS ghc-proposals

There is a fork that compiles to js https://github.com/ghcjs/ghcjs compiler, and I believe the official glasgow compiler is working towards also supporting js/wasm (although I don't think they are supported as of yet).

I don't know anything about Haste, but you can get GHCJS 8.6 (or 8.10 with a bloated executable) via nix fairly easily or alternatively wait until the JS target recently merged into mainline ghc gets production ready: https://engineering.iog.io/2023-01-26-ghc-update.

Ah GHCJS does have this header: https://github.com/ghcjs/ghcjs/blob/ghc-8.10/lib/boot/data/include/stg/DLL.h

It seems like https://github.com/ghcjs/ghcjs/issues/821 is a rigid dealbreaker for any sizable project.

About the FFI: GHCJS extended the FFI to support inlined JS, named arguments, etc. See https://github.com/ghcjs/ghcjs/blob/master/doc/foreign-function-interface.md For now the JS backend only implements FFI calls similarly to native FFI. The rest will be open to discussion later (e.g. in a ghc-proposal) and should take into account the Wasm backend so that the same user code compiles with both backends as much as possible.

Other than that, I ran into a GHCJS and Miso bug, but they weren't too hard to solve.

There are a bunch of open branches. And yes, there is ghcjs support in haskell.nix, see this comment.

When I compile the ghc-8.8 branch locally, I get a number of test failures from the test suite. I'm not sure exactly how to fix them and they aren't currently my highest hobby priority.

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