IRC channel logs
2024-12-06.log
back to list of logs
<homo>pijul just like darcs is patch-based version control, while fossil, git, cvs and others are snapshot-based <homo>radicle uses git, so is not patch-based <pabs3>in terms of bootstrap. the http downloads are binary-only. the source is only on radicle, or (hopefully the same data) on cargo. <homo>I guess in a way rust is better than haskell in that it builds, but with haskell every update of ghc breaks compatibility and everything has to be adjusted, furthermore many haskell libraries break compatibility every update and everything has to be adjusted again <homo>but talking about that on #haskell leads to response that those breakages are always for improvement and it's easy to adjust existing projects when breakages happen <fossy>i'm pretty sure that rust at least has a policy that release 1.X builds with 1.(X-1) <stikonas>yes, but that's usually the only one that builds it <fossy>but haskell has X.Y may or may not build with X.(Y-1) <homo>if only there was another functional language... <oriansj>homo: well if we can bootstrap GHC on *ANY* architecture, other architectures can do QEMU builds of GHC bootstrap and then just do a cross compile to the native architecture. <oriansj>so getting a complete as possible chain in Guix gives us a way to document and preserve a chain we can link to later <lanodan>Although it seems like qemu wants to adopt rust… :( <homo>unfortunately everything nowadays wants to adopt rust <oriansj>then a bootstrap Haskell compiler only needs to target the first link in the chain (which someone could do simplification on incrementally) <oriansj>lanodan: well, atleast we have a clean bootstrap path for Rust from GCC <fossy>and QEMU is also a fairly complete piece of software, i don't see using today's QEMU being a problem in 10 years <homo>I tried programming in rust, I don't understand why would anyone program in that language, but more and more projects are switching to rust <fossy>lol homo, what's your biggest pain point? <fossy>i'm not a rust lover, but not a hater either <lanodan>via gccrs or rustc-gcc-backend (not sure on the name of this one)? Last time I checked they didn't work for bootstrapping but it's been a while. <oriansj>one possible solution for the GHC bootstrap is to take the simplest version of GHC we can chain and remove the use of one haskell feature at a time until it can be built by a Haskell98 compiler <lanodan>Ah yeah right, that's an extra step, but one that at least currently works <oriansj>we don't have to like what programming languages other people use. We just have to bootstrap and have bootstrap chains for those languages and then we can let the Guix community do the long term support for those languages. <homo>haskell98 doesn't have FFI, pattern guards and hierarchical modules (Data.Char vs Char), so haskell2010 is better <oriansj>homo: well honestly, as long as someone moves the needle in the correct direction of finally getting a GHC bootstrap. I'll be happy to see progress. <fossy>homo: "better" in what sense? as in an overall better language? <homo>fossy: reading haskell report that is the only addition, but (n+k) patterns are removed from language, so yes, a better overall language <fossy>absoltuely agree that it is a better language to program in, but the added complexity makes it an unideal target to directly bootstrap, assuming we can bootstrap haskell2010 from haskell98 <oriansj>which might not be an issue if one of them was written in a smaller haskell subset, which could give us a path out <homo>well, do you really want to convert hierarchical modules to non-hierarchical like renaming Data.Char to Datachar? and what about FFI? ghc is not written entirely in haskell <homo>oriansj: that's what basically blynn's compiler is about? small subset to implement a bigger subset until a good enough subset is implemented? <fossy>I'm confused. why do we want to do that? the most promising method at the moment seems to be soemthing -> something else -> ancient GHC (0.26??) -> marginally newer GHC -> marginally newer GHC -> ....... -> modern GHC <fossy>and somewhere in those ......, conversions from haskell98 to haskell2010 occur <oriansj>homo: kinda and we also could do the reverse with GHC until we can get a simpler Haskell compiler able to build that extended chain. <homo>fossy: do you have hardware that is capable to build so many versions of ghc in less than 2 months? <fossy>homo: no idea, but i suspect so <homo>I'm actually afraid to even try building a single version of ghc simply because of how much resources it eats, I'd rather rely on compiler that implements good enough subset of haskell2010 <oriansj>bootstrappable Haskell -> better haskell -> bootstrap achieved <- simpler haskell able to build ghc -1 <- simpler haskell able to build ghc <- ghc <fossy>when you say "good enough", do you mean for general Haskell programming, or to build GHC? <fossy>FWIW, on my Gentoo system, rust takes ~1 hr to build, GHC takes around the same amount <homo>fossy: for general haskell programming, the subset I use while programming, but again I'd be happier programming in different functional language that has nice-looking syntax, lazy evaluation, strong type system and IO monad <homo>I tried building rust once, it took many hours, and my current laptop is not any better <homo>I like the approach of go, they don't have feature creep in the language, only basic features that everyone uses while programming <matrix_bridge><googulator> homo: the problem is, "Haskell 2010" is a paper language <matrix_bridge><googulator> By the time the 2010 standard was published, everyone was treating "Haskell" as a synonym for "whatever GHC will accept" <matrix_bridge><googulator> In particular, there's no Haskell 2010 implementation written in Haskell 2010 <matrix_bridge><googulator> What makes nhc98 interesting for bootstrapping is that it implements Haskell98 (& some extensions), and is written in Haskell98 (possibly with some use of extensions) <matrix_bridge><googulator> Hugs is interesting because it's written in an eager language, and it implements Haskell98-ish <matrix_bridge><googulator> (unfortunately not full Haskell98, and certainly not whatever is required to build the first Haskell98-compliant GHC) <matrix_bridge><googulator> Yale Haskell is interesting because it, too, is written in an eager language, and it implements Haskell 1.3 (-ish? it's not clear, unfortunately) <matrix_bridge><googulator> Hugs & Yale Haskell both make the jump from an eager language to a real-life lazy one <matrix_bridge><googulator> Blynn & microHs go from an eager language to a toy lazy one <stikonas>well, I was building the whole rustc chain, it's probably 2 or 3 hours here if you do full LLVM + 3 stage rust build and then times 20 or so builds... <stikonas>though soon I guess we should be able to switch to mrustc that can build 1.74 <fossy>stikonas: what hardware do you have out of interest? <stikonas>starbook mkvi, so 13th Gen Intel(R) Core(TM) i7-1360P <fossy>gotcha, that explains things, cause I was thinking you build at least the first bits of live-bootstrap faster than I do, but my rust build is faster than yours <stikonas>I guess it's more parallel but maybe slower single thread performance <homo>googulator: and also hugs is impossible to build on guix despite being packaged <oriansj>homo: sounds like a bug that just needs to be reported. <matrix_bridge><googulator> 5700x, being a desktop CPU, will also stay in turbo clocks for longer than a low-power notebook one like 1360P