Haskell Architecture Proposal

Maybe we do not need official guidelines. We could start by introducing a flag for packages on Hackage. If a library fulfills the criteria that it only depends on base, uses no ghc-language extensions and does not import the parts from GHC that currently are in base, the library maintainer can decide to switch the flag on or not. But the flag cannot be switched off again.

Then place a big switch button labeled with “Show only language compliant core libraries” at the top of the Hackage website that affects search. Wait, this could scare off users as there aren’t listed any libraries at the beginning. So maybe a label “Show only new core libraries” would be better.

In addition there should be an email to all library maintainers that explains the whole thing.

Ok, I delved deeper into the topic than I intended. As I see, the way we write Haskell has substantially diverged from the last standard Haskell2010. For example the widely used function unsafePerformIO isn’t mentioned anywhere in the Standard. On the other side there is the old array type included in the standard (under the GHC namespace) which is generally considered obsolete. And there are more examples.

From the discussions I see two tendencies at the moment:

  • We want reliable core libraries
  • We want a small base library

In order to achieve this I would suggest, we start small and try to make the new or existing core libraries conform to the Haskell2010 Standard. I found out there’s the compiler flag for ghc -XHaskell2010 that may be used for this when developing core libraries. As I mentioned, core libraries should only depend on base. If authors find no other way to implement things, they will be requesting more functions they’re used to or maybe for completely new functions. In a next post I explain how these feature requests could be handled for developing a new standard.

Maybe we do not need official guidelines.

I’m writing a book about writing Haskell in production, so I would profit considerably by suggesting that my material be the official/blessed resource. And I still would oppose any blessed or official guidelines. There’s just too much variability in how code is written and how things work in Haskell. There’s also no where near enough real world experience in writing production Haskell codebases for us to have anything resembling authoritative.

At most, we should be pointing folks towards “Want to do X? Here’s a Success Report from some group doing something similar to X.”

5 Likes

The point is to teach good techniques and proper mindset, and for those materials to come directly from haskell.org (as well as maintained on into the future), instead of some random fellow’s unmaintained writing from a by-gone era.

I think having that type of material on haskell.org would produce a better end result than what we have now.

I think a big part of the problem is that the group of people who have written a lot of production code don’t agree on the best practices, or what is a reasonable suggestion.

I think that happens because we are focused on our successes and our opinions (and being right in the argument) instead of focusing on helping other people learn it right from the start. Or when someone steps up to create better material, we play a game of king of the hill until they leave.

Let’s start with something simple: what’s the right way to handle effects in Haskell?

1 Like

Monads :stuck_out_tongue_winking_eye:

2 Likes

…and there’s plenty of tutorials to choose from! However, for I/O at least: