haskell.{compiler,packages}.microhs: init at 0.15.4.0 by AlexandreTunstall · Pull Request #460845 · NixOS/nixpkgs

AlexandreTunstall · 2025-11-12T03:58:41Z

This change adds microhs-based packagesets to the haskell.packages package sets.
For example, haskell.packages.microhs.mtl is a working microhs-compiled mtl package.

The microhs compilers added here replace the recently added microhs package.
Unlike the previous version, all new versions are built entirely from source by using Hugs to interpret the microhs source code.
cpphs was also booted from source in a similar way.

The goal is to allow Nixpkgs users to more easily experiment with using microhs, and perhaps one day boot GHC from source.
Note, however, that nix-shell (and related derivations) is completely untested.

A few patches were needed to make microhs and microcabal behave properly inside the Nix store, all of which I will seek to upstream.
The patch to make microhs Hugs-compatible is more of a hack, and I expect keeping microhs Hugs-compatible to be too troublesome to be worth upstreaming.

Things done

Add a 👍 reaction to pull requests you find important.

steeleduncan

Could I ask what the reasoning for all the revision-versioned microhs packages is?

I know it is done with GHC, but that is an outlier for nixpkgs. With e.g. gcc, clang, go, etc there are only packages for the major versions with (deliberately) backwards incompatible changes

steeleduncan

If this is a fix to another commit in this PR it should be merged with that commit (ie the initial haskell.{compiler,packages}.microhs-*: init commit)

AlexandreTunstall · 2025-11-19T12:18:49Z

Since 0.14.17.0, array isn't included in microhs' base package. Many packages still work without it.

Would that count as "a fix to another commit"? I'm not sure.

AlexandreTunstall · 2025-11-19T12:25:01Z

Could I ask what the reasoning for all the revision-versioned microhs packages is?

For now, it is solely about making the versions available. There is no particular reason.

If you think that only having the latest version would be better, that is doable, but it will require bumping the boot compiler, and therefore also the Hugs compatibility patch, more frequently.

Perhaps we should check with upstream what the versioning policy is, if any?

steeleduncan · 2025-11-19T22:09:59Z

Looking at the MicroHs repo, there are 15 tags/versions in the last 3 months. Keeping up with a version a week would be a significant maintenance burden, and eventually that number of extra derivations would noticeably affect evaluation and rebuild times.

When old versions of programming languages are supported in Nixpkgs, they tend to get removed when there is no further support (e.g. node.js < 20 is gone now). There doesn't seem to be any intention of support for the old MicroHs versions, so I think having just the latest version would be appropriate here.

Perhaps we should check with upstream what the versioning policy is, if any?

It would make sense. I don't think a programming language with weekly breaking changes could ever be useful, but it would be useful to know if the intentions is for an occasional major version upgrade with breaking changes

steeleduncan · 2025-11-19T22:12:05Z

Would that count as "a fix to another commit"? I'm not sure.

Possibly I am misunderstanding, but the oldest version of the compiler supported by this PR is 0.14.17.0, so if 97260bc3483744eab990c3be4d736333d2915303 is needed to fix every version from 0.14.17.0 onwards, I would have thought it should be part of the initial commit

AlexandreTunstall · 2025-11-19T22:28:06Z

There is 0.14.15.0, which will fail with the fix. But that only matters if I don't update the Hugs patch to 0.14.25.0 as I look into dropping the older versions.

Atemu

If there is no specific need for other versions, I see no reason to keep them.

I propose we strive for the least amount of mhs compilers possible to complete bootstrap to the newest one.
Ideally, this would be 1 but that's unrealistic.

I could see a chain like this though:

hugs-compatible mhs ran/built via hugs
mhs that can build latest
latest mhs

Atemu · 2025-12-04T21:13:18Z

+
+  inherit (microhs-src) src;
+
+  patches = [ patches/hugs.patch ];


Why is this a vendored patch rather than just fetching the upstream hugs branch?

The upstream hugs branch is not kept up-to-date.

We might be able to use the ancient version if we patch out all the newer primitives, but I expect that it would only get less compatible over time.

I see.

If you're going to do that work anyway though.. why not just do it upstream?

The patch mostly replaces uses of ViewPatterns with isJust. It's not pretty code, but I could ask upstream.

Patch looks okay to maintain since it's not that deep. I wouldn't expect the ViewPatterns stuff to be merged because it is ugly code often enough.

We could try to upstream some of this though, e.g. what about adding a HUGS cpp definition which handles all the removal e.g. of the NFData stuff, seqs and interactive mode?

e.g. what about adding a HUGS cpp definition which handles all the removal

I'd prefer to avoid CPP because it would complicate the bootstrap (mhs doesn't require CPP).
That said, I will see what I can do.

All changes except for the ViewPatterns fixes, without CPP: augustss/MicroHs#429.

sternenseemann · 2026-04-08T15:34:47Z

I get the following when building hscolour which I thought would be a nice test case for a non trivial executable?

Running phase: setupCompilerEnvironmentPhase
@nix { "action": "setPhase", "phase": "setupCompilerEnvironmentPhase" }
Building with /nix/store/fzbf3vx5aj58msg6g4caav35hv3gi3r7-microhs-0.15.3.0-wrapped
ln: failed to create symbolic link '/nix/store/24xydijijbw9f9bv2qdsscn03yabs8lz-hscolour-1.25/lib/mcabal/mhs-0.15.3.0/packages/containers-0.8.pkg': File exists

AlexandreTunstall · 2026-04-08T16:52:12Z

I've noticed while going through your comments that the current version is a breaking change (microhs moved to haskell.compiler.microhs).
Since ghc is re-exported at the top-level, I'll add microhs back as an alias to haskell.compiler.microhs.

sternenseemann · 2026-04-08T19:16:09Z

I already did that in eeb3e9b, though we may want to make it an actual alias that can be deprecated later?

The package set is built entirely from source using the stdenv and Hugs. This also replaces the recently added microhs package, which was built from pre-generated compiler output. Co-authored-by: sternenseemann <sternenseemann@systemli.org>

Test the GHC boot packages that are known to work with MicroHs and mark those that don't work as broken.

Packages that have an empty hydraPlatforms won't be tested on Hydra otherwise, even if explicitly requested.

This makes isNativeBignumGhc purely textual again after NixOS#460845. Could improve performance in the right conditions, but most importantly solves eval issues with aliases allowed (due to the throw-ing ghc attributes) without resorting to tryEval.

AlexandreTunstall force-pushed the hfs-upstream-mhspkgs branch from 3bcd094 to f3d6a88 Compare November 12, 2025 04:33

nixpkgs-ci Bot requested review from maralorn, steeleduncan, sternenseemann and wolfgangwalther November 12, 2025 04:42

AlexandreTunstall force-pushed the hfs-upstream-mhspkgs branch from f3d6a88 to 7bf6633 Compare November 12, 2025 05:22

AlexandreTunstall mentioned this pull request Nov 12, 2025

microhs: init at 0.14.21.0 #458599

Merged

13 tasks

dmjio mentioned this pull request Nov 12, 2025

Add MicroHs support. dmjio/miso#864

Draft

15 tasks

steeleduncan approved these changes Nov 12, 2025

View reviewed changes

nixpkgs-ci Bot added 12.approvals: 1 This PR was reviewed and approved by one person. 12.approved-by: package-maintainer This PR was reviewed and approved by a maintainer listed in any of the changed packages. labels Nov 12, 2025

AlexandreTunstall force-pushed the hfs-upstream-mhspkgs branch from 041e3ef to 97260bc Compare November 19, 2025 09:07

AlexandreTunstall changed the title ~~haskell.{compiler,packages}.microhs: init at 0.14.21.0~~ haskell.{compiler,packages}.microhs: init at 0.14.25.0 Nov 19, 2025

steeleduncan reviewed Nov 19, 2025

View reviewed changes

steeleduncan suggested changes Nov 19, 2025

View reviewed changes

Atemu reviewed Dec 4, 2025

View reviewed changes

AlexandreTunstall force-pushed the hfs-upstream-mhspkgs branch from b7a6273 to 4100f81 Compare December 7, 2025 03:40

nixpkgs-ci Bot added 12.approvals: 2 This PR was reviewed and approved by two persons. and removed 12.approvals: 1 This PR was reviewed and approved by one person. labels Apr 8, 2026

AlexandreTunstall mentioned this pull request Apr 8, 2026

Bootstrap GHC from source #503150

Open

AlexandreTunstall force-pushed the hfs-upstream-mhspkgs branch from 4f00894 to dfb6e23 Compare April 8, 2026 20:46

AlexandreTunstall changed the title ~~haskell.{compiler,packages}.microhs: init at 0.15.3.0~~ haskell.{compiler,packages}.microhs: init at 0.15.4.0 Apr 8, 2026

nixpkgs-ci Bot added 8.has: changelog This PR adds or changes release notes 8.has: documentation This PR adds or changes documentation and removed 8.has: package (new) This PR adds a new package 2.status: merge conflict This PR has merge conflicts with the target branch labels Apr 8, 2026

AlexandreTunstall force-pushed the hfs-upstream-mhspkgs branch from dfb6e23 to b233c6e Compare April 9, 2026 17:27

AlexandreTunstall and others added 3 commits April 9, 2026 22:33

haskell.{compiler,packages}.microhs: init

e805baa

The package set is built entirely from source using the stdenv and Hugs. This also replaces the recently added microhs package, which was built from pre-generated compiler output. Co-authored-by: sternenseemann <sternenseemann@systemli.org>

microhs: make alias/shortcut for haskell.compiler.microhs

903ce1a

top-level/release-haskell.nix: test some pkgs with MicroHs

74f842f

AlexandreTunstall force-pushed the hfs-upstream-mhspkgs branch from f570913 to 8fbef80 Compare April 9, 2026 21:35

sternenseemann enabled auto-merge April 9, 2026 21:38

AlexandreTunstall and others added 2 commits April 9, 2026 22:39

top-level/release-haskell.nix: test GHC boot pkgs

437109b

Test the GHC boot packages that are known to work with MicroHs and mark those that don't work as broken.

haskell.packages.microhs: add doDistribute where necessary

ee2751c

Packages that have an empty hydraPlatforms won't be tested on Hydra otherwise, even if explicitly requested.

sternenseemann added this pull request to the merge queue Apr 9, 2026

AlexandreTunstall force-pushed the hfs-upstream-mhspkgs branch from 8fbef80 to ee2751c Compare April 9, 2026 21:40

Merged via the queue into NixOS:master with commit bc9ff3c Apr 9, 2026
6 of 8 checks passed

github-project-automation Bot moved this from In Progress to Done in Haskell infrastructure in nixpkgs enhancements Apr 9, 2026

alexfmpe mentioned this pull request Apr 10, 2026

pkgsStatic.ghc: fix attr pointing to package set sometimes #507998

Merged

13 tasks

sternenseemann mentioned this pull request Apr 11, 2026

haskell.compiler.native-bignum: don't evaluate compiler exprs #508952

Merged

13 tasks

Uh oh!

Uh oh!

Conversation

AlexandreTunstall commented Nov 12, 2025

Things done

Uh oh!

steeleduncan left a comment

Choose a reason for hiding this comment

Uh oh!

steeleduncan left a comment

Choose a reason for hiding this comment

Uh oh!

AlexandreTunstall commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AlexandreTunstall commented Nov 19, 2025

Uh oh!

steeleduncan commented Nov 19, 2025

Uh oh!

steeleduncan commented Nov 19, 2025

Uh oh!

AlexandreTunstall commented Nov 19, 2025

Uh oh!

Atemu left a comment

Choose a reason for hiding this comment

Uh oh!

Atemu Dec 4, 2025

Choose a reason for hiding this comment

Uh oh!

AlexandreTunstall Dec 7, 2025

Choose a reason for hiding this comment

Uh oh!

Atemu Dec 7, 2025

Choose a reason for hiding this comment

Uh oh!

AlexandreTunstall Mar 20, 2026

Choose a reason for hiding this comment

Uh oh!

sternenseemann Apr 8, 2026

Choose a reason for hiding this comment

Uh oh!

AlexandreTunstall Apr 8, 2026

Choose a reason for hiding this comment

Uh oh!

AlexandreTunstall Apr 8, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sternenseemann commented Apr 8, 2026

Uh oh!

AlexandreTunstall commented Apr 8, 2026

Uh oh!

sternenseemann commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

AlexandreTunstall commented Nov 19, 2025 •

edited

Loading

sternenseemann commented Apr 8, 2026 •

edited

Loading