IRC channel logs
2026-09-17.log
back to list of logs
<matrix_bridge><Jeremiah Orians> Bootstrapping doesn’t require optimal, perfect or anything better than just barely adequate. <notgull>I was working on a less pathological bootstrap path for rustc a while ago <notgull>I think a Rust compiler written in C using QBE as a backend is possible <notgull>Unfortunately it would’ve taken me a year to complete it and then I got hired full time <jackdk>doesn't mrustc chop a lot of that off? Last I checked it could build Rust 1.8x for some x that escapes me <lanodan>1.90.0 in fact now, but rust is currently at 1.98.x <lanodan>Hopefully ~nothing these days needs latest rust. <Googulator>The issue with Haskell is that the oldest GHC that survives (0.26) already requires not just "a capable Haskell compiler", but specifically "an earlier version of GHC", to bootstrap it. <Googulator>GHC 0.24 was the last version of GHC written in (what was then) standard Haskell. Its source code is lost, just like all earlier GHCs. <Googulator>well, standard enough that compiling it with HBC was a supported bootstrap path <Googulator>GHC 0.26 added code that used GHC-specific extensions, and later versions went even more in that direction <Googulator>some GHC versions even have checks in the build system to detect if the "GHC" you're compiling them with is actually a compatibility wrapper around a different compiler, and bail out <Googulator>The standard Haskell of the era was also very different from, and largely incompatible with, later versions of Haskell <Googulator>completely different I/O system, and no concept of a monad <Googulator>If I'm not mistaken, GHC 2.x was the first to be written using monadic I/O <Googulator>with fallbacks in the code to enable it to be compiled using GHC 0.x (there never was a GHC 1.x) <Googulator>also no source code release ever existed for GHC 0.25, as it was actually a recompile of 0.24's unmodified source code for Linux on x86, where the distributed 0.24 binaries came out broken due to a bug in GHC 0.23 for the same platform, which was originally used to compile it <Googulator>so the GHC team recompiled it using a cross version of 0.24 running on some big iron (SPARC, maybe), and labeled it 0.25 <Googulator>roconnor: GHC's Git commit history goes back to 0.26 <Googulator>0.26 was apparently when the GHC team started using CVS <Googulator>the CVS repository was then imported to Darcs, keeping version history <roconnor>I was just browsing the 0.29 repo thinking to myself, how complicated could such an old compiler be, but oh boy. Though maybe it isn't so bad as it seems. <roconnor>Though even if 0.29 or 0.26 could be bootstrapped, ... the amount of work to get old tooling working to run the bootstrap chain forward from there would be monumental. <Googulator>If we had 0.24, we could try to bootstrap via HBC, but HBC is itself a can of worms <Googulator>HBC was written in LazyML, which is quite a bit simpler than Haskell <Googulator>but LMLC, the LazyML compiler, was also written in LazyML (and indeed, shared most of its codebase with HBC) <Googulator>IMO our best shot at an "archaeological" bootstrap would be with Yale Haskell <Googulator>Written in Common Lisp, and supporting both recursive module dependencies and monadic I/O <Googulator>The challenge is porting it to a modern Lisp that is itself bootstrappable <Googulator>and of course, convincing the GHC build system that Yale Haskell is GHC <Googulator>The alternative is starting with something like MicroHs or blynn-compiler, and avoiding archaeology altogether <roconnor>Implementing LazyML doesn't sound that hard. <roconnor>At least compared to everything else here. lol. <pullpullpull>What's up with the yale vs ghc thing? I don't get why they don't compile eachother (ignoring slightly different syntax)? <Googulator>GHC has no chance compiling Yale Haskell because it's not a Lisp compiler :) <pullpullpull>I looked into implementing LazyML and the biggest issue I feel like isn't the compiler, its the tooling around it <Googulator>Yale could compile GHC if GHC was written in standard Haskell <Googulator>Yes. There was an attempt to port it to clisp, but when I tested it, it didn't work <pullpullpull>Huh, that's interesting. What do you mean by "GHC was written in *standard* Haskell"? <Googulator>Starting with 0.26, the code depends on GHC-specific extensions to the language. <Googulator>0.26 IIRC implements Haskell 1.2, with some extensions - and its source code makes use of those extensions, so a standard Haskell 1.2 compiler can't handle it. <pullpullpull>ah I see, and obviously 0.26 is lost, so 0.29 depends on extensions not present in other compilers <Googulator>0.24 was the last version written in pure standard Haskell <Googulator>0.26's tarball is lost, but it's preserved in the Git repository <pullpullpull>why was 0.24 lost? that's very strange, is there a reason? <Googulator>because it was what got initially imported into CVS <Googulator>and therefore it was then carried forward as part of the commit history <Googulator>until then, the source was only distributed as tarballs on university FTP servers <Googulator>and whenever a new version was released, they would wipe the old one <Googulator>0.26's readme warns you about needing ~20MB for building <pullpullpull>i didnt remember it being so scarce back then, i thought there was already more <Googulator>actually, looks like 0.26's tarball also survives <Googulator>0.27 and 0.28 tarballs are lost, but the code is preserved in Git <Googulator>0.29 was IIRC the first one to be distributed via HTTP in addition to FTP <Googulator>From 0.26's ANNOUNCE file: "We could provide diffs from previous versions of GHC, should you require them. A full set would be very large (7MB)." <pullpullpull>Damn, to be fair floppy disks where 1.44MB which is basically nothing by modern standards <aggi>don't mean to interrupt the Haskell discussion <aggi>i've had another mental lapse on tinycc-devel recently <aggi>to keep it brief, i would prefer to keep tcc mob/HEAD bootstrappable directly <aggi>which means it can be compiled with pnut-cc and/or mes-cc (or even better cc_x86) <aggi>so far i could merely confirm pnut-cc can compile 0.9.27 and did not yet rebase laurenth patchset onto HEAD <aggi>meanwhile further progress was made with tcc, to support C99 _Complex for example (required by musl-libc too for example) <aggi>anyway, i do fear further changes accumulate on tcc mob/HEAD which might clash with bootstrapping progress (i consider the pnut-cc/tcc-0.9.27 a most important proof-of-concept) <aggi>i already did fork tiny-bootstrap for the pnut/tcc mob/HEAD rebase (among other reasons to do so, such as linux-tcc integration, busybox, cdrtools etc.) <aggi>but i've had no luck with any contracting nor university cooperation here in germany (except for the one in autumn 2025 in thuringia which was postponed/cancelled indefinitely since then) <aggi>an appointment at german employment agency proposed a mental evaluation if i was mentally capable to cope with various tasks <aggi>just to let you know, i'm not held back for technical reasons, but bureaucratic insanity <aggi>otherwise, there already would be a tcc mob/HEAD bootstrap confirmed, together with a full re-integration of linux-tcc kernel <aggi>really, it's well prepared with tiny-bootstrap for anyone to proceed with this menial task <aggi>their political argument here was, i've not done anything relevant in recent times <aggi>except for scavenging and backtracking source code over two decades of development, to re-cover POSIX C-toolchain portability with tcc <aggi>i've too put aside the NASM book (it's a decent one btw., 100 pages only to read), idea being to re-cover syslinux/isolinux.bin for bootstrapping <aggi>because that's needed to support cdrecord with a much smaller dependency graph, among other reasons <aggi>i jsut considered it relevant, to have a configurator build step/ for this one too <aggi>given linux-tcc too is ready, and supports relevant hardware (AHCI, PATA/IDE) for cd-rw just fine <aggi>since the last appartment rent hike and another round of extortion letters of tampered energy bills yet again i was forced to terminate all work <aggi>because i got no more than a few weeks each until german politics invent yet another ideological insanity <aggi>to "justify" their corruption and oppression <aggi>often i feel, it's intentenional, almost as if some intentionally seek to sabotage my work <aggi>i too got the suspicion i've been spied upon (i got no evidence for this), phone tapped, my documents scraped by ministry of defense (again no evidence but i noticed some weird citations) <aggi>if german government instutions would compy with GDPR regulations here, and labor market regulations themselves <xentrac>roconnor: the Glasgow Haskell team was already very smart before 0.29, and the difficulty with code written by very smart people is that they don't have to simplify it that much to get it to work, so usually it's more complicated than absolutely necessary, because simplifying it is a lot of extra effort <aggi>i'm not aware of major software written in Haskell, except Pandoc <aggi>which raises the question, how much effort should be invested into ghc <aggi>it's just, i've re-confirmed static-linking and cross-compilation for the complete set of software here that got salvaged <aggi>which was no more than roughly 500 ebuilds only, since i avoided haskell and similar when possible <aggi>except python so far, but i rather removed that too from the package set than any more headache suffered from making this cross-compile and statically linked <aggi>leave alone bootstrapping <aggi>difference in this case, alot of software is written in python (no clue why given the problems with it, probably big corporations such as google supported this, ignorant to principle engineering concerns) <aggi>while ago i skimmed wikipedia article, where haskell originated, where that was coming from <aggi>i think that was Schotland/UK <aggi>no clue why anyone would invest notable amounts of time and money into it nowadays <aggi>anyway, it's good to see python got bootstrapping re-covered, but it remains blocked with clean cross-compilation and static linking still <aggi>no offense, but why bother with Haskell? except pandoc i've not yet encountered software written in haskell <roconnor>It's simply those folks who prefer to program in Haskell would also wish it to be bootstrappable. <xentrac>16:29 < aggi> which raises the question, how much effort should be invested into ghc <xentrac>people who like Haskell can work on bootstrapping Haskell. if you discourage them from doing so, they will not magically gain an interest in bootstrapping Python. they will just go away <xentrac>you aren't in charge of anything, so please stop acting like you are <xentrac>this is the second time I've seen you try to discourage a bootstrapping effort because the person working on it had different priorities than you do <aggi>xentrac: i removed pandoc due to questions surrounding haskell, which indeed had been of interest <aggi>i don't discourage anyone <aggi>that's why, i mentioned pandoc <xentrac>"why bother with Haskell?" is a discouraging remark <xentrac>the other time, you claimed that the guy's work was dishonest (!) because he wasn't working on bootstrapping the Linux kernel, instead taking it as a given <aggi>xentrac: i do keep protocol logs here <aggi>and i merely do recall a proposal to distinguish a language/compiler bootstrap from a complete system bootstrap <xentrac>I think distinguishing is good, but you had descended into personal attacks at that point <xentrac>if people think that coming in here to talk about their bootstrapping efforts will get them (or their favorite language) insulted, they will not return <xentrac>well, if you think that's the kind of thing you wouldn't do, I'm satisfied you don't intend to do it again <aggi>yet i do admit i'm not in best mood for anything, which is unrelated to bootstrapping efforts <xentrac>my condolences. I'm sure having me argue with you isn't improving that <aggi>no need to argue anymore, and not in this channel <xentrac>I hope the things that are dampening your mood cease to do so, and that you feel better