IRC channel logs
2024-06-23.log
back to list of logs
<oriansj>but that might just be my love of the IBM x200 keyboard and how much better a trackpoint is to a trackpad <matrix_bridge><cosinusoidally> Andrius Štikonas: I'll raise a PR some point today. Note the FreeBSD issue doesn't actually reproduce with the master version of stage0-posix-x86 as hex2-0 already has the correct filesz. Bumping memsz does fix Linux 2.2 and 2.4 though. <Googulator>janus: MicroHs isn't written in Scheme or anything Lispy <Googulator>It uses binary "combinators" for bootstrapping that themselves are generated using Haskell code <Googulator>of course, if we can generate the combinators using Hugs, Gofer or Yale Haskell (the only Haskells I'm aware that aren't implemented in a lazy language like Haskell itself), that's indeed a viable bootstrap path <janus>that's why i mentioned porting ;) <janus>the advantage of porting MicroHs as opposed to porting other haskell compilers is that you can still actually talk to Lennart <Googulator>"Porting" MicroHs to Scheme would involve bootstrapping lazyness, which is precisely what makes Haskell so hard <janus>ah interesting... i hadn't heard before that lazyness was the central issue <janus>wonder how much lazyness MicroHs takes advantage of <Googulator>BTW, Lennart is also the author of hbc - which sadly has the same problem of being written in a lazy language, Lennart's even earlier LazyML specifically <janus>right, but i don't think Lennart can help much with hbc any more <janus>i wrote him an email about it, never received a reply <Googulator>there are 2 LazyML compliers in existence, one written in LazyML itself (packaged with hbc), and another one in modern Glasgow Haskell <janus>i think the LazyML infrastructure is just lost forever and it makes little sense to reconstruct it <Googulator>Lennart's compiler requires a compiled binary of itself to start with (yeah...), the other one requires GHC 9.x with all the modern Haskell dependency management infrastructure, so I haven't really tried <Googulator>hbc is significant because it's one of the few known examples in which lazyness was *somehow* bootstrapped <Googulator>the other ones were Gofer (later Hugs, a lazy functional interpreter - writing a lazy *interpreter* in an eager language is reportedly much easier than a lazy compiler) and Yale Haskell, written in early Scheme, which is functional, but not lazy - and most importantly, has modern derivatives (Guile and Mes), which are fully bootstrapped <stikonas>Googulator: have you recently ran fiwix? <stikonas>somehow qemu bootstrap seems to be taking forever for me... <Googulator>sadly we don't know how LazyML was bootstrapped, so that path is lost <stikonas>I'm trying to figure out if it's my PR... <janus>i am not a compiler developer but i can see how an interpreter for a lazy language shouldn't be super complicated, at least if it has no optimization <Googulator>janus: compiling a lazy language to machine code is extremely non-trivial, and the standard way of doing so - the "G-machine" - is described using already lazy primitives, like infinite lazy lists <janus>right. i hope we shouldn't need the G-machine (or the STG, which is a derivative IIRC), since our machines are so much faster than back then <janus>if it takes 256 GB RAM to bootstrap GHC, it's still a start, right? :P <Googulator>interpretation is much easier, since it's just graph reduction (in theory at least) <stikonas>yeah, we don't need to have optimum implementation of bootstrap <Googulator>IIRC the problem isn't just "optimum", it's doing it at all <janus>right. the constraints are completely different from when GHC got started. they were focused on having it run on real machines, so they sacrificed elegance <janus>making it hard to grok and reproduce <Googulator>Glasgow never made the eager->lazy jump themselves <janus>super interesting insight, and somehow foundational.. can't believe you're only pointing this out to me now <janus>but don't you think MicroHs has a point with the combinators? that the STG complicating matters too much? <janus>Csaba Hruska made this STG interpreter, i am sure you much have seen it <Googulator>I have a feeling that the combinator generation algorithm probably also exploits the lazyness of its host language to perform finite operations on infinite data structures <janus>what is interesting about the STG interpreter, is that, IIRC, he only made it cause there was no way around it <janus>really, his goal is to have a graph reduction (GRIN-style) compiler <janus>so i'd argue that the bootstrapping community, Csaba and Lennart, we have more in common than immediately obvious <janus>i think he references the 1979 paper by David A Turner, which doesn't seem specific to lazy languages since it talks about LISP <janus>Oooh Turner actually talk about non-strictness: <janus>> A number of recent authors have advocated that the semantics of applicative languages should be redefined so as to permit non-strict functions. (A non-strict function is one that can return an answer even if one of its arguments is undefined.) <Googulator>looks like Csaba's STG interpreter is written in... *Haskell* :( <janus>yeah, writing your infrastructure in your own language is the mind-virus ;) <Googulator>MicroHs is promising, if Hugs or Yale can run it <Googulator>& of course if it can handle modern Haskell (with recursive modules) better than Hugs <Googulator>Hugs's biggest limitation is no recursive module support <janus>well GHC has bad support for recursive modules, right? Since it requires hs-boot files even though they're not theoretically required <janus>so maybe that could provide Lennart with an easy 'win' <Googulator>yeah, but that's unfortunately how GHC's own source code is written <xd1le>but pretty sure this has been brought up before too <matrix_bridge><Andrius Štikonas> I'll probably try to do at least builder-hex0 testing before merging it though...