IRC channel logs

2026-01-30.log

back to list of logs

<fossy>stikonas: ah, okay
<fossy>arguably most cursed language to bootstrap: poly/ml
<fossy>it is bootstrapped from a memory dump of a previous version
<daddy>it's _what_.
<fossy>literally outputs it's internal representation of the program state :D
<fossy>old enough versions had per-architecture memory dumps :D
<fossy>nowadays it has a "portable" version
<fossy>no idea how this language could ever be bootstrapped
<fossy>(from source)
<daddy>there's also Haskell which (by means of GHC) is self-bootstrapped for how long now? ever?
<daddy>something about ML-y shaped languages, i guess?
<jackdk>That is a new frontier in cursedness. GHC is committing the same sin that every other modern language considers a "we're a grown-up implementation" milestone: having a self-hosting compiler.
<daddy>a real grown-up implementation can be bootstrapped in at most 5 iterations.
<daddy>you get 5 breaking changes before you have to update the original compiler or build a new one, mrustc style.
<jackdk>I have an alternative proposal: your self-hosted compiler should be able to boostrap in at most log2 n recompiles from previous releases of itself. So you get a few breaking changes when you first start, but when you get a mature language, you might have to make 128 or 256 new releases before you're allowed an additional breaking build
<daddy>Hm. I accept that as a compromise. Less rewritten code.
<aggi>which raises a question, no offense intended, of cause bootstrapping is a most relevant criteria
<aggi>but, is it worth any effort to bootstrap various languages?
<aggi>it's a matter of priorities
<aggi>i rather wiped c++/g++/rust-lang/java from my system profile completely for this reason
<aggi>currently, i even fear for C language, since it's standard got "improved" upon too
<aggi>because, if at least a GNUish/POSIX can be driven with a bootstrapped/C-toolchain system profile, this covers critical base sytem components
<aggi>in this regard rust-lang and c++ are far less concerning, although Canoncial decided recently they intend to re-implement coreutils in rust
<aggi>then, bootstrapping, that's their problem, not mine
<aggi>haskell, would have been interesting with pandoc iirc - i wiped pandoc from the system profile. done.
<aggi>another aspect of this, is languages and utilities involved not covered by ISO/ANSI/POSIX/etc.
<aggi>i think, that's one reason why rust-lang is problematic, they haven't got a language specification to establish a common baseline
<aggi>and as a consequence their bootstrapping is rigged
<aggi> https://lists.gnu.org/archive/html/tinycc-devel/2025-12/msg00016.html
<aggi>that's how C "standard" got "improved" upon
<aggi>it's no coincidence, C language features are restricted, in particular when bootstrapping a C compiler
<aggi>but it's too a neverending pain when C got "improved" upon destabilizing toolchain and kernel build
<aggi>this was the reason why i quit with linux kernel, to compile this with a gcc-4.x such patching was necessary:
<aggi> http://tinyfront.mooo.com/downloads/linux-5.9.16-gcc47.patch
<mwette>janneke: match that works for cpp.scm: https://paste.debian.net/hidden/8a06fa0d
<mwette>not sure about cxexval.scm and the others you may use
<mwette>there is an extra let in there that does nothing -- need to remove
<mwette>w/o the unneeded let: https://paste.debian.net/hidden/545e8ed3