You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I got you. I understand bootstrapping is high on the list of goals for MicroHS. But independently, I'm curious if we have cabal-install built with GHC (as usual), can it drivemhs. It'd be interesting to try it I think...
My first experiment was to cabal init -nm --lib and try to "just build" it, and it exploded quickly:
[nix-shell:~/dev]$ cabal build -w mhsWarning: this is a debug build of cabal-install with assertions enabled.Error: [Cabal-8038]The program 'ghc' version >=7.0.1 is required but the version found at /nix/store/3sg4dss3j9i8ikpzvm1gmrp0vncsm2x3-microhs-0.14.21.0/bin/mhs is version 0.14.21.0
after debugging this s bit: although the MHS compiler flavor was added recently, the flavor detection mechanism identifies GHC flavor for MHS and proceeds accordingly. We need to correctly detect the flavor at least.
My recollection is that the only thing that was added was recognition in a cabal file. There's no way to detect it, no way to run it, and in particular no way to know what would go into the store or what hashes to use and what modifies those.
There's no logic to detect a flavor, rather, ghc is the default, and if you don't like it, you're supposed to set it manually with the compiler flag. Funny enough, the docs say that it should be possible to do it via CLI, but I'm getting:
(and same with MHS, all caps). A project file works though. It get's me a bit further but not by much:
[nix-shell:~/dev]$ cabal build -w mhs -v3Warning: this is a debug build of cabal-install with assertions enabled.Searching for curl in path.Found curl at /run/current-system/sw/bin/curlSearching for powershell in path.Cannot find powershell on the pathSearching for wget in path.Found wget at /run/current-system/sw/bin/wgetSelected http transport implementation: curlFile monitor 'config' changed: file /home/artem/Dev/cabal.projectProject settings changed, reconfiguring...Reading project file using the fallback parsercreating /home/artem/Dev/dist-newstylecreating /home/artem/Dev/dist-newstyle/cacheConfiguration is affected by cabal.project at '/home/artem/Dev'.File monitor 'improved-plan' changed: first runFile monitor 'elaborated-plan' changed: first runFile monitor 'compiler' changed: first runCompiler settings changed, reconfiguring...Error: [Cabal-3022]Unknown compilerCallStack (from HasCallStack): dieWithException, called at src/Distribution/Simple/Configure.hs:2528:16 in Cabal-3.17.0.0-inplace:Distribution.Simple.Configure
Right, that's part of what I was getting at. But after that we have a possibly silent problem where mhs-options may contain things that need a different build hash in the store. Also I think objects aren't OS objects but combinator bytecode, and final link tacks a small bytecode interpreter on the front.
MicroHs has no concept of object files. There are two kinds of build products: 1, a .pkg file which is the result of compiling an entire library from a package. 2, an executable which is the result of compiling a runnable program from a package.
The format of the .pkg file is private and should not concern cabal.
It's true that you can get other outputs, like a combinator file, but that's more for debugging and testing.
Telling mhs to install a package will populate a directory with various files, again, the contents of these is private.
@augustss where is this documented? do I switch between the two modes explicitly or MHS just figures it out? I've started some experimenting here: #11392
To create an executable mhs MDL -o FILE.
To create a package mhs -PPKG MDL MDL ... -o FILE.
Where MDL are module names, FILE are file names, and PKG a package name.
To install a package mhs -Q FILE, where FILE is produced by mhs -P.
Activity
augustss commentedon Dec 22, 2025
I didn't really try it. I just looked a bit at the code. And then decided to write my own.
ulysses4ever commentedon Dec 22, 2025
I got you. I understand bootstrapping is high on the list of goals for MicroHS. But independently, I'm curious if we have
cabal-installbuilt with GHC (as usual), can it drivemhs. It'd be interesting to try it I think...augustss commentedon Dec 22, 2025
I think that would be very interesting to try.
ulysses4ever commentedon Jan 5, 2026
My first experiment was to
cabal init -nm --liband try to "just build" it, and it exploded quickly:geekosaur commentedon Jan 5, 2026
I'm surprised it got even that far; there's a fair amount of support that needs to be added to actually drive a compiler.
ulysses4ever commentedon Jan 5, 2026
after debugging this s bit: although the MHS compiler flavor was added recently, the flavor detection mechanism identifies GHC flavor for MHS and proceeds accordingly. We need to correctly detect the flavor at least.
geekosaur commentedon Jan 5, 2026
My recollection is that the only thing that was added was recognition in a cabal file. There's no way to detect it, no way to run it, and in particular no way to know what would go into the store or what hashes to use and what modifies those.
ulysses4ever commentedon Jan 5, 2026
There's no logic to detect a flavor, rather,
ghcis the default, and if you don't like it, you're supposed to set it manually with thecompilerflag. Funny enough, the docs say that it should be possible to do it via CLI, but I'm getting:(and same with
MHS, all caps). A project file works though. It get's me a bit further but not by much:Configure.hs:2528 is:
the next step would be to see if we can implement configure for MHS. Maybe it can be trivial. E.g. for UHC it reads:
geekosaur commentedon Jan 5, 2026
Right, that's part of what I was getting at. But after that we have a possibly silent problem where
mhs-optionsmay contain things that need a different build hash in the store. Also I think objects aren't OS objects but combinator bytecode, and final link tacks a small bytecode interpreter on the front.augustss commentedon Jan 6, 2026
MicroHs has no concept of object files. There are two kinds of build products: 1, a
.pkgfile which is the result of compiling an entire library from a package. 2, an executable which is the result of compiling a runnable program from a package.The format of the
.pkgfile is private and should not concern cabal.It's true that you can get other outputs, like a combinator file, but that's more for debugging and testing.
Telling
mhsto install a package will populate a directory with various files, again, the contents of these is private.ulysses4ever commentedon Jan 6, 2026
@augustss where is this documented? do I switch between the two modes explicitly or MHS just figures it out? I've started some experimenting here: #11392
augustss commentedon Jan 6, 2026
To create an executable
mhs MDL -o FILE.To create a package
mhs -PPKG MDL MDL ... -o FILE.Where
MDLare module names,FILEare file names, andPKGa package name.To install a package
mhs -Q FILE, whereFILEis produced bymhs -P.You can run
mcabal -v -vto see what it's doing.