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)

Some improvements and updates to the static linking setup

Recently I was faced with a problem: should I use pacman or cabal or another alternative to manage my Haskell packages in my system?

After reading this wiki page, my answer was clear, pacman for the system and cabal for development. The thing was that after following the steps of the wiki in the section Haskell#Tips and tricks trying every alternative, there still were some errors when I was trying to install packages with cabal using static linking.

The error was a bug in the GHC, which was still using some global files even if cabal was linked with another GHC installation in the system. This bug was recently corrected for version 9.8.3 onwards.

For this reason I think it would be beneficial to add not only this information to the wiki, but also move the section "Tips and tricks" to "Package management", because this is a way of setting up a configuration that allows to have the convenience of pacman dealing with your Haskell apps in the system and a development setup, which is better handled with static linking and cabal or stack.

I would like to also modify the section to move, adding a new alternative for static linking (the one I ended up with), using ghcup to install GHC, which allows the user to have multiple GHC, cabal, stack and HLS versions managed by ghcup in the user home directory.

If this sound a reasonable change to make please tell me in the comments. Thank you! Giuli635 (talk) 21:37, 17 December 2024 (UTC)

Here is the link to the bug in the GHC: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13070?commit_id=cdcc6b763b91c4cbf68eacfe2997998550ba49d0 Giuli635 (talk) 21:45, 17 December 2024 (UTC)

I'm not completely sure about moving the section "Tips and tricks" to "Package management". The original intent behind "Tips and tricks" is to describe somewhat hacky and cumbersome ways to use system GHC together with static linking. This is probably not something that should be recommended to users under "Package management". Nevertheless, it would be great to add more information about issues with static linking and provide a link to that GHC bug.

IMO the article lacks clear guidance about which method of managing Haskell packages should be the preferred for different use cases. Perhaps we should make it clear that:

1. If you just want to use Haskell software, such as xmonad or pandoc, then install them from Arch repos via pacman.

2. If you just want to do Haskell development, use GHCup to install GHC, Cabal, Stack and HLS into home directory.

3. If you want to install Haskell software and do Haskell development at the same time, use pacman for the former and GHCup for the latter.

4. Otherwise, if you don't want GHCup and plan to use pacman exclusively:

- 4.1. To use dynamic linking, go with "Configuration" section.

- 4.2. To use static linking, go with "Tips and tricks" section.

- 4.3. But be aware both ways have their own quirks and troubles. Toiffel (talk) 10:41, 19 December 2024 (UTC)

I like the idea, I can start to make some changes. But in which section would it be a good idea to put the recommendations about the different use cases? Giuli635 (talk) 15:16, 20 December 2024 (UTC)

Honestly, I don't know. The "Installation" section begins with a wiki note that suggests to proceed either with "Native installation" or "Alternate installations". Do you think you can improve these notes and add some more navigation tips that instruct the user which sections they should read for different use cases?

Unfortunately the state of Haskell on Arch is... well... complicated. It's quite hard to come up with a good structure of the article.

On the one hand, this is Arch wiki after all. Here we should explain how to install and use Haskell packages from Arch repositories at the first place. The current article is written exactly in this way. The sections "Installation", "Configuration", "Package management", "Development tools" are all about dynamically linked packages installed via pacman. The section "Alternate installations" about GHCup and Stack is treated like a second-class citizen.

On the other hand, I doubt anybody actually uses Arch packages for Haskell development. ghc package from official repos is outdated and stuck on version 9.2.8. It's not very useful beyond learning Haskell in GHCi or recompiling xmonad. Nowadays everybody suggests to install Haskell via GHCup and completely ignore native Arch packages.

For these reasons, it might be worth to restructure the article in the opposite way. That is, move sections about GHCup and Stack to the "Installation" section and suggest them as the "recommended" way of installing Haskell on Arch. Then move everything related to native Arch packages ("Configuration", "Package management", "Development tools", "Tips and tricks") to the bottom of article, probably merge them under single section like "Using Haskell packages from Arch repositories", and put a big purple note like "yep, this is a complicated stuff, proceed if you really want to". The section could be further subdivided into "Using dynamic linking" and "Using static linking" where we could describe the necessary configuration and issues related to this Arch-specific Haskell setup.

However, such structure still feels a bit peculiar and unidiomatic. I'm not sure we really want this. Toiffel (talk) 21:34, 20 December 2024 (UTC)

Although I like the last idea you mentioned, I understand that it's not something Arch-focused but Haskell-development-focused.

I would take the approach of expanding the introduction with recommendations linking to different parts of the article.

And clarifying different sections to make clear that currently using Arch packages for development is discouraged and that they probably won't work (because of the bug I mentioned earlier), until they update the GHC in the repos. Giuli635 (talk) 16:49, 21 December 2024 (UTC)

Sounds great! Seems like this is the way to go. Toiffel (talk) 17:20, 21 December 2024 (UTC)

Well, I've finished making changes I think, if someone wish to review them and give some feedback, I'd be glad to hear it. Giuli635 (talk) 16:54, 23 December 2024 (UTC)

I haven't followed the discussion, but a few comments on the result:

• The Installation section deviates from the standard sections used on the wiki – it does not describe how to install haskell, but gives an overview of the various installation methods. IMHO it should be renamed.
• The Native installation section mentions all ghc, cabal-install, stack, but the Package management section which has further subsections for Cabal and Stack is outside this section.
• If cabal-install and cabal-install-bin^AUR provide exactly the same thing, the latter should not be mentioned.
• The Development tools section mentions ghcup so I think it should be ordered after Alternate installations.

Lahwaacz (talk) 20:59, 24 December 2024 (UTC)

Another point: the part "This packages may need to build from source, building AUR packages or developing software require a compiler and build tools to be installed. Using the #Native installation method is discouraged for this use case, instead see #Alternate installations." reads like you could use any alternate installation to build and install any AUR package. Lahwaacz (talk) 21:01, 24 December 2024 (UTC)

Looks nicer than before! I especially like that Configuration section became a subsection of Native Installation. Now it's clear the described configuration only applies to Haskell packages installed via pacman. Package Management and Development Tools also refer to dynamically linked packages installed via pacman, so they should be probably also become subsections of Native Installation.

I agree with @Lahwaacz that Installation section now looks non-standard. I just remembered about Rust article and I believe we can use it as an example. It starts with a section named Core Language that explains basic Rust notions. We could add similar section at the beginning of Haskell article that explains what GHC/Cabal/Stack/HLS/GHCup are. It would be good to give the reader the basic understanding of Haskell toolchain before discussing alternative ways of installing this toolchain in Installation section. For now explanation of Haskell tools are buried under Native Installation.

The Rust#Installation section starts with the following choice:

The two main ways to install Rust are:

• The Native installation, recommended if you only use Rust for running or installing software made with Rust
• The Rustup installation, recommended if you intend to program anything in Rust

We have exactly the same choice in Haskell, albeit with more quirks. Perhaps we can follow Rust article here. Toiffel (talk) 01:03, 26 December 2024 (UTC)

Thank you guys for your feedback! I'll get hands on as soon as I can. Giuli635 (talk) 02:52, 27 December 2024 (UTC)

Okey, these days I have some time to continue doing modifications, but one thing concerns me.

I added last time the explanation of dynamic vs static linking for Haskell in Arch Linux in the Installation section because I think it's beneficial for the reader to know that information before making a decision.

I understand you don't think it's appropriate to put that information there, I understand that and agree. I can make another section for that, but which could be the name of that section? Giuli635 (talk) 19:48, 3 January 2025 (UTC)