1. 24
  1. 9

    I appreciate all the thoughtful commentary in that thread, and I’m happy folks are thinking about improving this area. Points that stuck with me (paraphrased because I’m on mobile):

    users need to deal with stack/cabal too early; difficult for new users

    This has been a problem for a really long time and I don’t see it being solved anytime soon.. making the prelude more useful is a great way to sidestep the issue

    there should be defaults to support beginners and hobbyists who want to do something quickly (a la python batteries included)

    nix-shell hashbangs really help in this area, but changing my whole workflow to nix has been costly and I don’t think we should expect most users to do that..so making Haskell easy to use quickly should be a priority.. a larger and better organized prelude does this

    something to avoid: users would need to remember multiple prelude package names (in addition to the use of cabal/stack mentioned above) and context switch between similar sets of names with different types or functionality

    Yes, this would be a problem.. I think I agree with the folks who suggest making the changes inside base.. one person mentioned how spitting up base was tried and failed in the past.. I don’t really think it should be split up either.. perhaps organized differently…

    This is a standard library! don’t remove functionality and cause ever more fragmentation as folks seek now missing functionality and come to different conclusions about which libraries to use.. it’s already hard enough as a new user to learn about the default set of blessed packages outside of base (discoverable by doing ‘ghc-pkg list’ on a vanilla ghc install).. what is the point of containers/stm/async not being in base? Are these not the blessed packages?


    Tldr: a standard library should be:

    • easy to use – currently beginners have to master cabal/stack and discover containers to access a Map type
    • obvious – beginners are unlikely to discover ‘ghc-pkg list’ and understand that on a vanilla install that’s approximately the list of stdlib package names
    • powerful – there’s no map in prelude; there’s no stm or async in prelude
    • scale from beginner use to production — current prelude has many things to unlearn (partial functions, laziness footguns, inefficient String) and lacks many things commonly used (map, threads, concurrency usage references, etc)
    1. 2

      Didn’t quite consider myself a beginner, and I wasn’t aware of ghc-pkg list. Thank you!

      1. 2

        I think there’s a difference between what should be in prelude and what should be in base?

        Also, in any nontrivial application one will want to install some packages (whether via apt, cabal, whatever) so I’m not sure I consider that a barrier? For trivial applications I rarely need to leave base.

        1. 2

          As I see it there are four levels of things:

          1. Prelude - bindings in scope in a new module with no imports
          2. base - modules importable in a script with no cabalfile or in a project with no additional package dependencies
          3. standard library / Haskell platform - blessed packages on which your project can depend without downloading third party code from hackage (because they’re installed with ghc)
          4. third party packages obtained from hackage..

          I’m kind of arguing to fold #3 into #2 because

          • #3 isn’t discoverable
          • #3 is a needless jump in complexity for new users because they need a cabal file and a project directory and an understanding of cabal or stack
          • Map is a type which should be available to so-called trivial applications without leaving base

          I’m also arguing to expose more of #3 and #2 in #1.. yes, as you said they are distinct, but I think there should be more and better defaults in #1 and #2

      2. 3

        My perspective is that the less likely it is that a language is any given user’s primary tool, or at least essential for their projects, the more important it is that the libraries and tooling not get in their way. Haskell probably suffers less than some languages, because its reputation warns people that the language itself requires a lot of work. Still, I think reducing friction is more important than almost anyone realizes. As such, I think changing base is by far the best solution, unless it’s truly impossible.

        I’m familiar with alternate preludes, but I never used one because I didn’t want to have to make a choice. Selecting an alternate prelude feels like a bet on the library being maintained and widely used. If there’s a blessed choice that the community rallies around, it still becomes one more hurdle to getting started. If there isn’t, then that’s even worse.

        Background: I have a few thousand lines of Haskell code written a few years ago that I still use on a regular basis, but I go months without touching Haskell. I consider myself an advanced beginner.

        1. 2

          Alternative preludes can only be approriate in application (and not library) development. Even when you can use one they’re a choice of personal taste (I sometimea use basic prelude, but most other alt preludes I’ve seen are totally incompatible with my Haskell usage)

          1. 1

            TL;DR: We need to avoid pleasing every possible group of users at once, and as such the better we can figure out our target group, the better the end result will be…

            I’m reminded of the way Perl 7 pivoted away from forever-support of dynamically enabled language features, and in so doing, deemphasized supporting users with a lot of old code they want to run on the newest Perl version. IIRC they did this to support beginners who want less up-front complexity and modern-feature users who want the good stuff on by default. This seemed positive to me as an outsider, but it seemed to mean risking a category of users to give the language a chance at thriving again.