# What’s needed to bootstrap GHC with hugs?

**URL:** <https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205>\
**Category:** Learn\
**Created:** [April 26, 2023, 7:22am UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205 "2023-04-26T07:22:39Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![nomeata](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/nomeata/32/1188_2.png) [@nomeata](https://discourse.haskell.org/u/nomeata)\
**Post date:** [April 26, 2023, 7:22am UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/1 "2023-04-26T07:22:39Z")

</div>

I was recently reminded that we still don’t have a bootstrappable GHC build (in the sense of [https://bootstrappable.org/](https://bootstrappable.org/)), and that it would would be nice to have.

Somehow this caused me to [try to combine all of GHC’s source code into one huge file](https://www.joachim-breitner.de/blog/802-More_thoughts_on_a_bootstrappable_GHC), which I didn’t fully succeed, nor would it really directly help with bootstrapping GHC. But it made me wonder again.

A [previous attempt to bootstrap GHC](https://elephly.net/posts/2017-01-09-bootstrapping-haskell-part-1.html) didn’t use hugs because it doesn’t support recursive modules. Presumably, adding that wouldn’t be too hard.

What else would be missing before we can compile a (oldish) version of GHC with Hugs? Could this plan of attack work:

1. Identify an old version of GHC that

2. Wrangle the build system to tell you which files to compile, with which preprocessor flags etc.

3. Boostrap all pre-processing tools used by GHC (`cpphs` or use plan cpp, `happy`, `alex`).

4. For every language feature not supported by Hugs, either

5. Similarly, since Hugs probably ships a `base` that is different than what GHC, or the libraries used by GHC expects, either adjust Hugs’ `base`, or modify the GHC code that uses it.

@AntC2 seems to be the expert on Hugs here; what is your assessment?

---

<div class="post-metadata">

**Author:** ![AntC2](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/antc2/32/1872_2.png) [@AntC2](https://discourse.haskell.org/u/AntC2)\
**Post date:** [April 26, 2023, 11:40am UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/2 "2023-04-26T11:40:39Z")

</div>

Thanks @nomeata for thrusting me into the limelight. Ooh er, if I’m any sort of “expert”, abandon hope now.

The last Hugs release (2006) supports to H98 standard and well beyond. The main H2010 language feature it doesn’t support is guards: the comma-list; the three forms of guard. Those went into GHC ~2000; it was SPJ keen on introducing them, because a lot of compiler code could be improved thereby. If GHC immediately started using those guards itself, that spells trouble.

IIRC from your previous attempt, you particularly wanted to build the whole compiler/Prelude/libraries from source – including all the low-level interfaces to the operating system. Then we still have the same difficulties: the operating systems have evolved such that those low-level interfaces are no longer compatible. Furthermore O.S. versions are out of support: even if you can find an install, you might not be able to get it licensed.

Does your saying “Wrangle the build system” mean you’re not now trying to get an authentic-from-source compile?

I’m not trying to compile Hugs from source ground up, so I just copied the binaries from the distro for that low-level stuff. (Also I’m not trying to call low-level routines.) As we discussed before, theoretically those binaries might be smuggling in malware/trojans to plant in compiled code.

> [@](#):
>
> 1. Hugs probably ships a `base` that is different than what GHC, or the libraries used by GHC expects,

Hugs certainly doesn’t know about the dastardly FTP changes. But then if you’re bootstrapping a GHC of the same vintage as Hugs, neither did GHC in ~2006.

> [@](#):
>
> 1. Identify an old version of GHC … bootstrap subsequent versions …

I presume that early in GHC’s history, it stopped compiling via Hugs (which is an interpreter), and switched to compiling itself(?) – that is, to object code. Maybe that was even before 2000(?) In which case maybe Hugs 2006 was never used to run GHC. GHC version 3.02 (1997) has a ‘Building from Source’ guide that doesn’t mention Hugs.

For compiling GHC, I can see plenty of ugly low-level stuff inside Hugs 2006 sources with machine dependencies. But maybe that was just carried forward unchanged.

> [@](#):
>
> hugs … doesn’t support recursive modules.

Presumably if you can find an old enough version of GHC, it wouldn’t be trying to use recursive modules.

---

<div class="post-metadata">

**Author:** ![AntC2](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/antc2/32/1872_2.png) [@AntC2](https://discourse.haskell.org/u/AntC2)\
**Post date:** [April 26, 2023, 12:20pm UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/3 "2023-04-26T12:20:27Z")

</div>

> [@AntC2](#):
>
> old enough version of GHC, it wouldn’t be trying to use recursive modules.

Ah, sorry I wrote that before looking in detail at your links “mutually recursive module dependencies, which is a feature that even the earliest versions of GHC rely on.” So how early did GHC cease using Hugs to get compiled? Would SPJ remember?

There seem to be some hacks mentioned via Google/Stackoverflow to get mutually recursive modules to work. [Concoct or edit the `cpp`](https://www.ariis.it/static/articles/haskell-circular-imports/page.html); or [a `boot` file](https://haskell-cafe.haskell.narkive.com/KEtikqs2/cyclic-inclusions)? That seems more manageable than squashing the whole compiler into one source file.

---

<div class="post-metadata">

**Author:** ![janus](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/janus/32/1060_2.png) [@janus](https://discourse.haskell.org/u/janus)\
**Post date:** [April 26, 2023, 8:37pm UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/4 "2023-04-26T20:37:28Z")

</div>

> [@AntC2](#):
>
> So how early did GHC cease using Hugs to get compiled?

It must have been before 0.29 since `platform.h.in` mentions it, but as far as I know, no available compilers (Hugs, NHC) can compile 0.29 (i.e. it was probably strictly self hosting). But now that you mention it, it would be good to systematically try all of these. HBC we’d need a Lazy ML compiler for. (maybe it’s easier to write one than modifying Hugs?)

```haskell
#define HC_UNSPECIFIED	1
#define HC_GLASGOW_GHC	2
#define HC_USE_HC_FILES 3
#define HC_CHALMERS_HBC	4
#define HC_ROJEMO_NHC	5
#define HC_YALE_YHC	6
#define HC_HUGS 7

```

(I did email Lennart Augustsson a few months back, but I never heard back)

---

<div class="post-metadata">

**Author:** ![nomeata](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/nomeata/32/1188_2.png) [@nomeata](https://discourse.haskell.org/u/nomeata)\
**Post date:** [April 27, 2023, 9:25am UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/5 "2023-04-27T09:25:39Z")

</div>

I briefly tried to reproduce the steps taken in [https://elephly.net/posts/2017-01-09-bootstrapping-haskell-part-1.html](https://elephly.net/posts/2017-01-09-bootstrapping-haskell-part-1.html). Noting that in the end he did manage to produce `.hc` files by interpreting `nhc98` using Hugs, but then the resulting programs segfaulted, it seems prudent to first make sure that one can compile and run `nhc98` from the generated C sources files included in the distribution.

Trying to do that with a current GHC causes the segmentation faults he describes. So maybe using an old toolchain would be helpful.

What is the best way to get a GCC from around 2005 in nix? Is there maybe a repository of such “old” compilers somewhere?

Or maybe there are flags that one can pass to gcc to make it behave a bit older?

(I’m way out of my depth here, just dabbling around.)

* * *

The last revision of nixpkgs to have gcc-3.3 was `1dfd467c1476d57cf218bad20148d194099c253`, but importing that doesn’t quite work (at least some outdated mirror paths need to be updated.)

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [April 27, 2023, 10:13am UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/6 "2023-04-27T10:13:51Z")

</div>

> [@AntC2](#):
>
> So how early did GHC cease using Hugs to get compiled?

There seems to be some confusion about the origins of GHC, which is somewhat unusual considering the relevant information has been widely available since 2007:

> [@](#):
>
> (page 28 of 55)
> 
> **9.1 The Glasgow Haskell Compiler**
> 
> Probably the most fully featured Haskell compiler today is the  
> Glasgow Haskell Compiler (GHC), an open-source project with a  
> liberal BSD-style licence.
> 
> GHC was begun in January 1989 at the University of Glasgow, as  
> soon as the initial language design was fixed. The first version of  
> GHC was written in LML by Kevin Hammond, and was essentially  
> a new front end to the Chalmers LML compiler. This prototype  
> started to work in June 1989, just as Peyton Jones arrived in Glas-  
> gow to join the burgeoning functional programming group there.  
> The prototype compiler implemented essentially all of Haskell 1.0  
> including views (later removed), type classes, the deriving mecha-  
> nism, the full module system, and binary I/O as well as both streams  
> and continuations. […]
> 
> GHC proper was begun in the autumn of 1989, by a team consist-  
> ing initially of Cordelia Hall, Will Partain, and Peyton Jones. It  
> was designed from the ground up as a complete implementation of  
> Haskell in Haskell, bootstrapped via the prototype compiler. […]
> 
> [A History of Haskell: Being Lazy With Class](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.168.4008&rep=rep1&type=pdf) (Paul Hudak, John Hughes,  
> Simon Peyton Jones and Philip Wadler).

As I dimly recall, the only time GHC and Hugs were ever really _“connected”_ was in the STGHugs project, which gave rise to GHCi as we now know it (because it was then simpler to implement a new interpreter in Glasgow Haskell instead of trying to keep GHC and Hugs _“in harmony”_).

* * *

> [@nomeata](#):
>
> we still don’t have a bootstrappable GHC build […] and that it would would be nice to have.

…but why (re)try bootstrapping [with STGHugs](https://elephly.net/paste/1644020383.html) (as previously noted [here](http://discourse.haskell.org/t/i-built-ghc-4-08-2-with-gcc-2-95/5337)) when you now have (preliminary) [support for WebAssembly](http://discourse.haskell.org/t/ghc-webassembly-weekly-update-2023-04-26/6202) in GHC. It might be easier to use `wasm` as a _“pseudo-[UNCOL](https://foldoc.org/UNCOL)”_, with trusted interpreters then running the `wasm`-version of GHC to then bootstrap GHC from source.

---

<div class="post-metadata">

**Author:** ![AntC2](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/antc2/32/1872_2.png) [@AntC2](https://discourse.haskell.org/u/AntC2)\
**Post date:** [April 27, 2023, 10:24am UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/7 "2023-04-27T10:24:58Z")

</div>

> [@nomeata](#):
>
> hugs … doesn’t support recursive modules. Presumably, adding that wouldn’t be too hard.

I can confirm Hugs 2006 continues to not support recursive modules. There’s one point in the code that makes that check/rejects `Recursive import dependency`.

Looks like that code is trying to sort the imports into dependency order: load first the modules with no dependencies; then the modules that depend only on them; then another round; etc.

Given GHC supported recursive imports from early days, and it’s a requirement in the standard, but the non-compliance is still a ‘known infelicity’ in Hugs 2006 – and indeed Hugs uses a non-compliant `Hugs.Prelude` module to avoid it – I guess “wouldn’t be too hard” to fix is being wildly optimistic.

---

<div class="post-metadata">

**Author:** ![nomeata](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/nomeata/32/1188_2.png) [@nomeata](https://discourse.haskell.org/u/nomeata)\
**Post date:** [April 27, 2023, 10:53am UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/8 "2023-04-27T10:53:22Z")

</div>

> [@atravers](#):
>
> with trusted interpreters then running the `wasm`-version of GHC

Maybe I’m not seeing it, but how do you get the `wasm`-version of GHC?

(Note that we are not talking about bootstrapping in the sense of supporting a new architecture, but in the sense of not using any untrusted binaries or other generated files.)

---

<div class="post-metadata">

**Author:** ![nomeata](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/nomeata/32/1188_2.png) [@nomeata](https://discourse.haskell.org/u/nomeata)\
**Post date:** [April 27, 2023, 11:07am UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/9 "2023-04-27T11:07:55Z")

</div>

> [@AntC2](#):
>
> I guess “wouldn’t be too hard” to fix is being wildly optimistic.

I assume there is a parser for a single module, which could be changed to parse all modules of a SCC in one go, leaving enough traces for the name resolution to keep definitions from different models apart?

(I assume it wasn’t done because nobody needed it - recursive modules are very rarely used outside GHC, snd maybe none of the Hugs users ever missed it.)

At least to me that sounds less scary than debugging segmentation faults in nhc98 when using modern C compilers. I wish I’d know how much of the way it takes us, or if, say, the path via nhc98 is more likely to succeed.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [April 27, 2023, 3:39pm UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/10 "2023-04-27T15:39:34Z")

</div>

> [@nomeata](#):
>
> Maybe I’m not seeing it, but how do you get the `wasm`-version of GHC?

By first compiling GHC to WebAssembly using GHC itself.

* * *

> [@nomeata](#):
>
> ([…] not using any untrusted binaries or other generated files.)

…which would seem to eliminate Hugs as a means of bootstrapping, as it’s also a compiled, untrusted binary (unless you’re intending to use a certified compiler to build Hugs).

---

<div class="post-metadata">

**Author:** ![nomeata](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/nomeata/32/1188_2.png) [@nomeata](https://discourse.haskell.org/u/nomeata)\
**Post date:** [April 27, 2023, 7:12pm UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/11 "2023-04-27T19:12:44Z")

</div>

> [@atravers](#):
>
> By first compiling GHC to WebAssembly using GHC itself.

But then you need GHC first 😃

> …which would seem to eliminate Hugs as a means of bootstrapping, as it’s also a compiled, untrusted binary (unless you’re intending to use a certified compiler to build Hugs).

Hugs is written in C, so (assuming you have a C compiler), you _can_ compile it yourself!

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [April 27, 2023, 8:46pm UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/12 "2023-04-27T20:46:41Z")

</div>

From the project’s website:

> [@](#):
>
> To gain trust in our computing platforms, we need to be able to tell how each part was produced from source. We believe that opaque binaries are a threat to user security and user freedom since they are not auditable; our goal is to minimize the amount of bootstrap binaries.

…therefore:

> [@nomeata](#):
>
> (assuming you have a C compiler), you _can_ compile [Hugs] yourself!

…isn’t satisfactory unless your chosen compiler for [that ol’ warhorse](https://techcrunch.com/2015/05/02/and-c-plus-plus-too) is itself trustworthy. Or should one use a C interpreter to run the C compiler from _its_ source…oh wait, how was that C interpreter built?

There are two approaches to bootstrapping a programming language:

1. someone writes the implementation in some assembly language;

2. someone writes the implementation using an existing programming language and _its_ implementation e.g. a compiler.

In either case, you will be confronted with an _“opaque binary”_ provided by someone else during the bootstrapping process. I’ll leave you to decide which is more trustworthy: assembly written by hand, or assembly generated by another program…

* * *

> [@nomeata](#):
>
> But then you need GHC first [to provide the `wasm`-version]

…only once. The `wasm` sources can then be kept for later reuse, much like the `ABC`-version is also provided for each major release of the [Clean](https://clean.cs.ru.nl/Clean) compiler.

---

<div class="post-metadata">

**Author:** ![AntC2](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/antc2/32/1872_2.png) [@AntC2](https://discourse.haskell.org/u/AntC2)\
**Post date:** [April 27, 2023, 11:31pm UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/13 "2023-04-27T23:31:01Z")

</div>

> [@nomeata](#):
>
> I assume there is a parser for a single module,

No. (Or I don’t understand what you’re asking.) Hugs is an interpreter, not a compiler. It doesn’t produce object code/there’s no separate compilation. If you tell it to compile module `A`, it’ll chase everything `A` imports, and everything the imports import and so on. Then sort the modules into reverse dependency order, as I described. Then in effect compile it as one enormous source file with module ‘fences’. The reason for the reverse dependency order is so that it gets first clean declarations of all the names in the non-dependent modules; then for later decls, it only needs to refer to decls already processed.

> [@](#):
>
> … leaving enough traces for the name resolution

I think Hugs internals doesn’t have a concept of ‘traces for name resolution’. It only has names compiled into the dictionary as syntactically valid decls. (The dictionary is quite a subtle/fragile [\*\*] structure: for example, instances are stored in overlap sequence chained from the class decl. Yes it has several passes over the dictionary after syntax validation, for semantic validation, type improvement. But I see no notion of ‘forward procedure’-- to borrow an ALGOL term.)

> [@](#):
>
> parse all modules of a SCC in one go,

You can’t squish several modules into (in effect) one source file/you have to observe module boundaries, because there might be the same names declared as local only in two different modules.

(Or I don’t understand what you’re asking.)

[\*\*] As I discovered when I tried to make overlapping instances work smarter – I broke a lot of stuff and got the interpreter segfaulting until I figured out the instances chain.

---

<div class="post-metadata">

**Author:** ![angerman](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/angerman/32/892_2.png) [@angerman](https://discourse.haskell.org/u/angerman)\
**Post date:** [April 27, 2023, 11:56pm UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/14 "2023-04-27T23:56:47Z")

</div>

Idk, but bootstrapping from nothing into c isn’t so uncommon. Here is guix doing this in less than 20 steps into guile. C doesn’t seem like a bad idea for a fairly ubiquitously abailabe compiler.

> **[Janneke (@janneke@todon.nl)](https://todon.nl/@janneke/110265435316816890)**
>
> Attached: 1 image
> 
> If you run "guix pull" today, you get a package graph of more than 22,000 nodes rooted in a 357-byte program---something that had never been achieved, to our knowledge, since the birth of Unix: a Full-Source...

Maybe the other route is through lisp/scheme/racket/hacket?

---

<div class="post-metadata">

**Author:** ![AntC2](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/antc2/32/1872_2.png) [@AntC2](https://discourse.haskell.org/u/AntC2)\
**Post date:** [April 28, 2023, 1:31am UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/15 "2023-04-28T01:31:56Z")

</div>

@atravers you seem to be firing off a load of arrows. I don’t see any of them are hitting relevant targets.

> [@](#):
>
> 1. someone writes the implementation in some assembly language;

Still not good enough: that source gets ‘assembled’ by an ‘assembler’: is that “itself trustworthy”? The only reasonable approach is to enter the compiler binary code direct into memory using the machine’s front panel switches. And even then, we’re relying on the microcode interpreting that binary correctly, and all the Operating System’s low-level routines that we call. (And can’t avoid calling, because the OS allows those operations only in protected memory.) Hand-keying a few million bytes of binary, what could be more trustworthy?

But note: Hugs is an interpreter, it doesn’t produce binaries. Rather, we’re using it to host source ghc to compile ghc to produce binaries.

So we don’t need to trust gcc much, but as @angerman points out, C++ compilers are a known evil validated far more widely than LML/Lisp/even rust that your link seems to favour. The critical question is where do the pre-packaged binaries (routines) come from that ghc compiled from ghc interpreted under Hugs merely copies into its output?

The Hugs compiled from C++ might include faults that will cause it to segfault/dangling pointers/buffer overflow given sufficiently evil Haskell input. But providing that doesn’t happen when interpreting ghc to compile ghc, we then throw away the crutch and have an untainted ghc compiler (object code) – which of course we must immediately use to compile ghc ‘properly’.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [April 28, 2023, 4:45am UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/16 "2023-04-28T04:45:23Z")

</div>

> [@AntC2](#):
>
> Still not good enough: that source gets ‘assembled’ by an ‘assembler’: is that “itself trustworthy”? The only reasonable approach is to enter the compiler binary code direct into memory using the machine’s front panel switches. And even then, we’re relying on the microcode interpreting that binary correctly […]

Certainly! I would go one step further and suggest that we would have to make our computers using parts we build ourselves (e.g. relays from copper wire, iron rods and springs, _etc_) to know for sure that we’re not using _“opaque binaries”_ anywhere…

* * *

> [@AntC2](#):
>
> But note: Hugs is an interpreter, it doesn’t produce binaries. Rather, we’re using it to host source ghc to compile ghc to produce binaries.

Alright, so let’s look at how Hugs would deal with all the FFI-C calls GHC relies on: does it call out to a C interpreter to perform the call before continuing on interpreting Haskell? No - it (sensibly) calls a C compiler to build extra _ ~~opaque binaries~~ _ modules which Hugs loads at runtime as needed by the Haskell program being interpreted.

So using Hugs to bootstrap it will not give you that _“untainted GHC compiler”_: all the foreign calls will be implemented with assembly generated by another _“opaque binary”_. Now if **angerman** , yourself and everyone else here is content with that fact, then you are all quite free to use Hugs in this way.

But the real test here is whether the _bootstrappable_ project will be also be content with this approach. I will defer to _their_ judgement on the matter (if someone else wants to ask them).

---

<div class="post-metadata">

**Author:** ![nomeata](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/nomeata/32/1188_2.png) [@nomeata](https://discourse.haskell.org/u/nomeata)\
**Post date:** [April 28, 2023, 7:49am UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/17 "2023-04-28T07:49:19Z")

</div>

> [@atravers](#):
>
> …isn’t satisfactory unless your chosen compiler for [that ol’ warhorse](https://techcrunch.com/2015/05/02/and-c-plus-plus-too) is itself trustworthy.

It is! Just yesterday someone [announced that guix project is now bootstrapped from a 357-byte binary](https://guix.gnu.org/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/)!

> [@AntC2](#):
>
> No. (Or I don’t understand what you’re asking.) Hugs is an interpreter, not a compiler.

Sure, but a interpreter that can deal with mutual recursion within a module can be taught to deal with mutual recursion across modules. You are absolutely right the things it has to keep track of (which names are in which module etc.), but that’s compiler construction bread and butter work.

I’ll wager a bet: If someone demonstrates that we can bootstrap some version of GHC using Hugs if only Hugs supported recursive modules, I’ll implement support for that.

---

<div class="post-metadata">

**Author:** ![AntC2](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/antc2/32/1872_2.png) [@AntC2](https://discourse.haskell.org/u/AntC2)\
**Post date:** [April 28, 2023, 8:03am UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/18 "2023-04-28T08:03:04Z")

</div>

> [@nomeata](#):
>
> Just yesterday someone [announced that guix project is now bootstrapped from a 357-byte binary](https://guix.gnu.org/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/)!

But look _why_ they wanted to do it:

> One reason is to properly address supply chain security concerns. The Bitcoin community was one of the first to recognize its importance well enough to put the idea into practice. At the [Breaking Bitcoin conference 2020], ...

If you want to break Bitcoin, give your money to Sam Bankman-Fried (apparently – the latest in a long line of scams). No amount of fancy software assurance will protect from straight-up crooks (or maybe idiot-savants – it’s a bit hard to tell with SB-F).

---

<div class="post-metadata">

**Author:** ![nomeata](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/nomeata/32/1188_2.png) [@nomeata](https://discourse.haskell.org/u/nomeata)\
**Post date:** [April 28, 2023, 8:03am UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/19 "2023-04-28T08:03:31Z")

</div>

Simon Tournier just told me that guix has bootstrapped 9.4.4 from 7.8.4, then there is a gap that needs to be filled, and also 6.10.4 from 4.08.2. So finding a way to bootstrap 4.08.2 would nicely connect to their work.

Looking at the code, I see boolean guards (`f x | p x = y`), but not multiple guards or deconstructing guards. But it seems that Hugs doesn’t even have boolean guards, right?

---

<div class="post-metadata">

**Author:** ![jaror](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaror/32/3271_2.png) [@jaror](https://discourse.haskell.org/u/jaror)\
**Post date:** [April 28, 2023, 8:21am UTC](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/20 "2023-04-28T08:21:11Z")

</div>

> [@nomeata](#):
>
> It is! Just yesterday someone [announced that guix project is now bootstrapped from a 357-byte binary](https://guix.gnu.org/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/)!

That sounded too good for me to believe and indeed it seems to be:

> while the package graph is rooted in a 357-byte program, the set of binaries from which packages are built includes a 25 MiB statically-linked Guile

What does it mean to say that a package graph is rooted in a binary? It doesn’t seem to mean that all packages can be built using only that binary…

[Next page](https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205.md?page=2)