Talk:Haskell

Stack for package management?

The page currently only mentions cabal-install. Stack seems to be an easier way of setting up Haskell environments and getting dependencies (For instance: https://hackage.haskell.org/package/turtle-1.2.8/docs/Turtle-Tutorial.html) Crasm (talk) 22:21, 30 July 2016 (UTC)

- I made more clear Stack is available as an alternative build too, but I tried to imply on the first sentence that you can also use Stack if you want: "You can use Stack but..." but I was focusing on explaining how to get a cabal-install that works and links statically.

- About using stack from the repo (https://www.archlinux.org/packages/community/x86_64/stack/) or the upstream version manually installed, is about if having any haskell-* package installed is incompatible with this new cabal-install we are building. We'd need to check, because maybe installing stack from the repo and bringing those haskell-* packages doesn't affect the linking. Otherwise I was trying to explain how to build a cabal-install in a clean environment. Jimenezrick (talk) 17:59, 28 August 2017 (UTC)

Section: "Building statically linked packages with Cabal (without using shared libraries)"

There's an easier way to install statically linked packages using Cabal, as described in the article. Therefore, I think this section is no longer necessary. --Fylwind (talk) 22:02, 24 September 2017 (UTC)

Regardless, please read ArchWiki:Contributing#Do not make complex edits at once and follow it in the future. The diff for your last edit is almost perfect anti-example for this rule. -- Lahwaacz (talk) 05:51, 25 September 2017 (UTC)

Sorry, I'll keep that in mind in the future. --Fylwind (talk) 08:13, 25 September 2017 (UTC)

Let me answer the --dynamic-too part with maintainer's response, which might give an enlightening perspective. I don't do static builds of system software for precisely the same reason — to save resources. My SSD space is not that cheap as most developers like to think. Haskell isn't the only thing deserving space on my drive, too.

The Template:Expansion does not belong here; this section doesn't any expansion, quite the contrary. It needs to be more streamlined, more organized and shorter — while still exposing the common issues, solutions and tradeoffs. The mere existence of --dynamic-too does not answer any of the reasons why this section exists. I'm removing the "Needs expansion" tag. --Ulidtko (talk) 10:21, 31 July 2020 (UTC)

"Big ball of sadness and despair"

JFYI dear editor, I'll quote from a 2020 blog opinion:

The current state of Haskell development on Arch Linux is a big ball of sadness and despair.

If you need any more convincing of how bad this is: More than half of the Haskell page on the Arch Linux Wiki is dedicated to problems compiling and linking Haskell code.

Bitterly, I concur. This page is a mess. Every next section tries to re-introduce already familiar concepts (cabal VS cabal-install, cabal VS stack, static VS dynamic linking, system GHC VS downloaded GHC, etc, etc), and the forest gets lost behind the trees.

Not only that; Haskell Platform as the only entry under "Haskell Development Tools" — that's inadequate. It's a shame; I removed the whole section. "Haskell Development Tools" ought to describe:

• haskell-language-server,
• haskell-ide-engine (discontinued it seems),
• hdevtools (unmaintained),
• ghc-mod (discontinued),
• linters, formatters, static analyzers: hlint, stylish-haskell, brittany, stan, numerous others.

Leksah is never mentioned. The supposedly strong support in VS Code is never mentioned. Perhaps it makes no sense to support such a section at all, given that Public Domain resources like awesome-haskell exist.

Mundane (and documented elsewhere) usage of Cabal is described; the description is incomplete and intermixed with advanced matters of static/dynamic setup.

This needs to be rectified. As a first step, I propose to split "general introductions" towards the top of the page, leaving the technically thick discussion in better concentration. I already started forming the "overview-level intro" section which initializes the local vocabulary and allows having unimpeded discussion later in the article. I encourage contributors to follow, and/or express any disagreement on this talk page. --Ulidtko (talk) 10:20, 4 August 2020 (UTC)

I totally agree. The messy wiki article confuses users and makes installing Haskell on Arch much harder than it should be. This needs to be fixed.

In general I like your idea of establishing a local glossary in the beginning of the article. The downside is that readers will be forced to read a large wall of text before they actually install anything. If you look at other wiki pages for popular programming languages, e.g. Python, PHP, Node.js, you'll notice they all jump straight into installing required packages without a preamble. With this in mind, I would start Installation section with something like "Install the following packages from the official repositories" followed by bulleted list of required packages similar to existing section Haskell platform. Each package can be explained in a few sentences, e.g. "Cabal is a build tool focused on dependency resolution and sources packages from Hackage. Hackage is the Haskell community's central package archive of open source software". This would be enough to give the reader basic understanding what GHC, Cabal, Stack, Hackage, Stackage mean. Other details like advantages/disadvantages of Cabal and Stack can be explained in later sections as the reader goes through the page from top to bottom.

I was also thinking about complete rewrite of the article. There are basically several different ways to install Haskell on Arch: from official repositories, using Stack, using ghcup/Cabal and using nix. It is tempting to list all approaches at the beginning, describe each approach in following sections and suggest readers to choose the best option. However, too much different options might also confuse readers and cause frustration. Again, looking at another wiki pages, they typically describe only one "official" way that boils down to installing packages from Arch repositories. Alternative ways (if any) are described in separate sections closer to the end of page. So I would not reinvent the wheel and simply do what other articles do: establish installation of GHC/Cabal/Stack and other dynamically linked Haskell packages from official repositories as the only true way (Arch way), declare other approaches as alternative ones and rewrite Haskell article in the same fashion as other articles about programming languages.

Here is rough structure for rewriting this article I came up with:

1. Installation. Provides a bulleted list of packages to install from official repositories. Each package is described in a few short sentences. Also provides a link to Alternate installations section.
2. Configuration. Explains that Arch uses dynamic linking for Haskell packages. Provides configuration of GHC, Cabal and Stack.
   • GHC. Describes how to pass -dynamic flag to GHC in order to successfully build Hello World app. Similar to existing Compiler. Probably not needed.
   • Cabal. Describes how to configure Cabal for dynamic linking globally via configuration file ~/.cabal/config or separately for each project via cabal configure. Uses existing Problems with linking.
   • Stack. Describes how to configure Stack for using system GHC and dynamic linking via ~/.stack/config.yaml. Uses existing Avoiding ~/.stack bloat by dynamic linking.
3. Package management. Explains different ways of managing Haskell packages on Arch (official repositories, Cabal, Stack), their advantages and disadvantages. Similar to existing Managing Haskell packages.
   • Cabal. Describes how to install packages via Cabal and add ~/.cabal/bin to $PATH.
   • Stack. Describes how to install packages via Stack and add ~/.local/bin to $PATH.
4. Package development. Explains how to create and build Cabal/Stack projects against Haskell libraries from official repositories using dynamic linking. Even if such instructions would be mundane and described elsewhere in official documentation, I believe we still need to provide beginners with exact sequence of commands they can run themselves and get a working executable. Once beginners manage to build Hello World successfully, there should be much less frustration and rants.
   • Cabal. Build instructions for Cabal.
   • Stack. Build instructions for Stack.
5. Development tools. I fully agree we should provide a list of modern Haskell tools such as haskell-language-server, ormolu, stan and so on, along with IDE/editors integration. A good example is Rust#IDE support.
6. Alternate installations.
   • Stack. Explains standard way of installing Stack and building statically linked packages under home directory.
   • ghcup. Explains standard way of installing ghcup/Cabal and building statically linked packages under home directory.
   • nix. I'm not familiar with nix too so we can just keep Template:Expansion there.
7. Tips and tricks.
   • Static linking. Various hacks and workarounds to get static linking back using GHC/Cabal/Stack from official repositories.
     • ghc-pristine. A workaround from existing section Static linking.
     • cabal-static. Explains how to use cabal-static^AUR for building statically linked packages. The existing section Building statically linked packages with Cabal (without using shared libraries) seems to be not needed anymore.
8. Troubleshooting. A collection of various solutions for specific issues that are not described in previous sections.
9. See also. This section should be expanded with links to official documentation, free books and useful Haskell resources, e.g. awesome-haskell or What I Wish I Knew When Learning Haskell.

Does that sound good? All comments and suggestions are very welcomed. -- Toiffel (talk) 07:08, 30 August 2020 (UTC)

Sounds totally sane and the provisional ToC is well-structured. Feel free to go ahead with the rewrite.

I especially like the Package Management/Package Development split; "users of Haskell (developers)" and "users of tools-written-in-haskell" pursue different goals and have different priorities, while the article tries to serve both. --Ulidtko (talk) 09:28, 31 August 2020 (UTC)

Great, thank you for your comment! Yes, the idea behind Package Management vs. Package Development is to describe usage of Haskell separately from user's and developer's point of view.

Let's wait for other guys this week. Maybe there are other users who is interested in this and can share their opinion. I have spare time for rewriting the article only on weekends anyway. -- Toiffel (talk) 04:35, 2 September 2020 (UTC)

[Announcement] Article rewrite

Hi everybody,

I'm going to rewrite the entire article following the plan described earlier in #"Big ball of sadness and despair".

I have very limited time mostly on weekends so this will likely take several weeks or even more. I'll post updates here about the current progress.

Your kind comments are highly appreciated!

Cheers! -- Toiffel (talk) 23:49, 12 September 2020 (UTC)

Please do it step by step and follow also the first two rules from ArchWiki:Contributing#The 3 fundamental rules (the third one is hereby fulfilled). -- Lahwaacz (talk) 08:21, 13 September 2020 (UTC)

Thank you! I'll try to organize the rewrite as series of atomic edits. I'll start with Installation and Configuration sections now. Feel free to correct or revert edits if I did something wrong. -- Toiffel (talk) 16:52, 18 September 2020 (UTC)

Okay, I finished first two sections Installation and Configuration. Now they describe how to install GHC, Cabal and Stack from official repositories and configure them to work together with system GHC and dynamic linking.

The next stop is Managing Haskell packages. I'll continue with it when I have time. -- Toiffel (talk) 21:40, 18 September 2020 (UTC)

Rewrote "Package management" section formerly known as "Managing Haskell packages". -- Toiffel (talk) 22:38, 3 October 2020 (UTC)

Added new section "Alternate installations" with (mostly mundane) instructions about installing Haskell using ghcup and Stack. Rewrote "Static linking" section, added instructions for cabal-static and stack-static. -- Toiffel (talk) 00:24, 6 January 2021 (UTC)

Great work! I added some basic information on IDE support. The subsection about editors still needs expansion. Amesgen (talk) 16:56, 6 January 2021 (UTC)

Thanks! The article becomes better and better :) I'll try to expand the section when I have time. -- Toiffel (talk) 10:23, 9 January 2021 (UTC)

Okay, finally got some time to expand and improve "IDE support" section. Now it is renamed to "Development tools". Also added some useful links to "See also" section. -- Toiffel (talk) 09:53, 30 June 2021 (UTC)