microhs: init at 0.14.21.0

[steeleduncan]

MicroHS is a Haskell compiler and interpreter

This exists as an autogenerated haskell package haskellPackages.MicroHs, but this package builds it independently of GHC, using the bootstrap functionality to build it from just a C compiler. This gives an alternate, easily auditable, lightweight haskell compiler and interpreter, that does not rely on the GHC toolchain at all

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[mdaniels5757]

Re-running CI due to a since-fixed unrelated treefmt-nix failure

[wolfgangwalther]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 458599
Commit: 0953bfa67f06e2aa51b5a60b17c4b627e4037d84

---

x86_64-linux

✅ 1 package built:

• microhs

---

aarch64-linux

✅ 1 package built:

• microhs

---

x86_64-darwin

✅ 1 package built:

• microhs

---

aarch64-darwin

✅ 1 package built:

• microhs

[acid-bong]

the rest (except for the test, i don't know Haskell enough to check it) looks great

[wolfgangwalther]

Except for the unused input, LGTM.

Thank you :)

[sternenseemann]

Why are we redundantly packaging MicroHs?

[wolfgangwalther]

The reasoning in the PR body says that this is bootstrapped without GHC, just from a C compiler. That would be the reason, I guess?

I thought it was a good one - if you think otherwise and think we should not do that, we can revert instead.

[steeleduncan]

Yes, my reason was that this packages builds a Haskell interpreter/compiler without GHC or any part of that ecosystem.

Functionally the resulting binary should be the same as provided by haskellPackages.MicroHs though, the only difference being in the route taken to that binary. I can't find any obvious precedent in nixpkgs for that though, so I can see that may not be sufficient reason to include it!

[sternenseemann]

That seems fine, though I must say that I don't find it much more compelling than using GHC given that the origin of mhs is just a generated C file. Without being able to build packages using mhs, this doesn't really move anything forward, though we can develop this in the future.

W.r.t. bootstrapping, using hugs would be much more interesting and as far as I know, @AlexandreTunstall has worked on that already.

[steeleduncan]

Yes, that is true. That C file is a blob of SKI combinators, which aren't very auditable. I'm working on a patch to the derivation to bootstrap that C file using Hugs

When you mention bootstrapping via hugs, I assume you mean bootstrapping GHC though? That would be great!

[AlexandreTunstall]

As great as it would be to bootstrap GHC via Hugs, that's something nobody has managed to do yet. MicroHs via Hugs, on the other hand, is quite easy and I already have a working version that first needed #443281 merged. You can expect a PR soon (once I rebase my branch to overwrite this drv 🙃).

@steeleduncan I assume you would like me to leave you in the package maintainer list?

[sternenseemann]

MicroHs via Hugs

Is also what I meant!

[steeleduncan]

@AlexandreTunstall I was working on doing the same, but ran into the build problem with hugs. I'll drop that though if you are going to be updating this derivation

You are more than welcome to remove me from maintainers list, I don't mind either way

To avoid any duplication of efforts, what are your plans with MicroCabal? Once MicroHs was properly bootstrapped my plan was to use that in a MicroCabal derivation that doesn't rely on the prebuilt blob in the MicroHs repository. That would probably require a wrapper or an upstream patch for MicroCabal though as it doesn't have a equivalent of Paths_MicroHs.hs that can be overwritten at build time

[AlexandreTunstall]

To avoid any duplication of efforts, what are your plans with MicroCabal?

I'm not sure what the trouble is, because I have a usable source-built MicroCabal in #460845, though it admittedly did need a bit of patching.

[steeleduncan]

To avoid any duplication of efforts, what are your plans with MicroCabal?

I'm not sure what the trouble is, because I have a usable source-built MicroCabal in #460845, though it admittedly did need a bit of patching.

I was referring to changes you made re getMhsDir in #460845

[Atemu]

Given that this is "built" from generated code that has equivalent properties to bytecode, could you set the appropriate sourceProvenance?

It'd also be great if the description mentioned the purpose/difference of this package.

[steeleduncan]

This formula has been superseded now in #460845 which bootstraps without the generated blob using hugs (recently fixed in nixpkgs)

Once that is merged this will be deleted, so I wasn't planning on making any changes to this formula

[Atemu]

I'd prefer this to be done regardless as it's not certain when/if that PR is merged.

[steeleduncan]

I see no reason it shouldn't be merged, and that PR is a superior approach to this one, so I'd rather contribute to it to help get it over the line!