An alternative front end for Haskell?

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern API for authentication & user identity.
  • Onboard AI - ChatGPT with full context of any GitHub repo.
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • > But the obvious and easy solution in the current language would be to return Maybe, which isn't done because there's a feeling that it's not a big enough step to be worth the effort, and dependent types will eventually solve this anyway.

    That's not why it's not done. listToMaybe already exists[1] and you can't change the type of head without breaking everyone's code, so head in the next version of base will come with a warning[2] and that's about as much as you can do whilst still maintaining backwards compatibility.

    [1] https://www.stackage.org/haddock/lts-21.14/base-4.17.2.0/Dat...

    [2] https://github.com/haskell/core-libraries-committee/issues/8...

  • ghc-proposals

    Proposed compiler and language changes for GHC and GHC/Haskell

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

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

  • WorkOS

    The modern API for authentication & user identity. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • servant

    Main repository for the servant libraries — DSL for describing, serving, querying, mocking, documenting web applications and more!

    > do you really have to understand language extensions?

    You do when your code doesn't compile and you're trying to figure out what the error message means, or when the library you want to use makes heavy use of it for even basic functionality.

    > These days one just enables GHC2021

    My experience was pre-GHC2021. I basically had to enable at a minimum 5-6 language extensions in every single file.

    > Mostly they're just about removing unnecessary restrictions from the older standard.

    Yeah, those ones are usually fine. I have zero objection to things like FlexibleInstances or DeriveFoldable.

    > Could you give an example?

    I believe I was trying to implement Central Authentication Service using Servant. However, that required returning a custom HTTP status code. There has been an open Github issue for this since 2017, but it seems to require basically rewriting the entire framework: https://github.com/haskell-servant/servant/issues/732

    Looking back at it now Servant does have "ServerError", but that basically requires giving up all the advantages Servant claims to have and I believe it was not a viable option at the time. Looking at the timeline I was probably also on Servant 0.15, and there seems to have been a rewrite since then.

    I vaguely recall running into a similar issue trying to interact with a database, but I can't remember the details of that.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts