ihp VS ghc-proposals

I found IHP straightforward:

https://ihp.digitallyinduced.com/

despite not remembering much haskell!

This assumes you can get past nix for the install.

I find IHP well-designed. I just wish the licensing scheme were more transparent.

You can find the docs at https://ihp.digitallyinduced.com/ and some getting started videos at https://www.youtube.com/watch?v=PLl9Sjq6Nzc&list=PLenFm8BWuKlS0IaE31DmKB_PbkMLmwWmG

In case this got you interested in Haskell, and you want a good way to start your Haskell journey (and have something to apply the optimization handbook to), check out IHP. It's the Rails/Laravel of the Haskell world. You can start here https://ihp.digitallyinduced.com/Guide/index.html or check it out on GitHub here https://github.com/digitallyinduced/ihp

At IHP we've been using Algora for a while now and it works really great. Here's e.g. one PR that was merged last week with a bounty attached https://github.com/digitallyinduced/ihp/issues/1621 Everything was set up in less than 15 minutes and ioannis and zafer have been super helpful with any questions we had.

In general I think this is a good direction and an interesting take on the open question around sustainable open source. Congrats on the launch and keep up the great work! :)

You could contribute to IHP! We have some great docs to get started here https://github.com/digitallyinduced/ihp/blob/master/CONTRIBUTING.md And we have some low hanging fruits in GitHub issues for you to get started with, e.g. https://github.com/digitallyinduced/ihp/issues/1601 (also there's always lots of activity in the IHP Slack, in case you have any questions/need help)

> Haskell has an endemic problem where way too many development resources are put into fringe parts of GHC

There has been an incredibly amount of work put into all the things you mentioned over the last decade, which it sounds like you're unfamiliar with. https://github.com/haskell/haskell-language-server in particular is a pleasure to use in my experience. Package management is far from perfect, but it's always being worked on and I'll take it over anything in Python or the Node.js ecosystems any day. Developer experience has improved a lot since I started using the language and this is an area that the community and leadership absolutely cares about--I'd be surprised at anyone who spent time reading discussions in https://github.com/ghc-proposals/ghc-proposals or https://discourse.haskell.org/ or etc. would agree with you.

> Haskell has the worst support for records of all its peers. SML, OCaml, F# all have better records.

> Without good records it’s unreasonably hard to write large software projects.

> AFAIK it’s hard to retrofit ML-style structural subtyped records onto Haskell, because the type system is designed around that not being possible.

Haskell is not ML, and while Haskell records are weak they are not what is preventing people from writing big projects in Haskell. There is much more to the language than records. But I said this in my previous comment.

Nothing you've written resonates with me, and I've written Haskell and PureScript professionally as well as Java and JS along with a bunch of other languages that haven't been mentioned. I'm also actively working on an open source project in my spare time with thousands of lines of Haskell and PureScript code (https://github.com/ddellacosta/automation-service), not to mention a half dozen other random half-done projects and contributions I've made to other open source libraries and applications. What have you written in Haskell that has made you dislike it so much?

> Talk is cheap.

Yes it is.

This is really just a matter of how much syntax sugar you want to implement. Idris has this already, and there’s a proposal to add it to Haskell too [0]. But none of this changes the core properties of the system which make it monadic.

[0] https://github.com/ghc-proposals/ghc-proposals/issues/527

> 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