IRC channel logs
2021-09-09.log
back to list of logs
<oriansj>stikonas: sorry for the delay, been out sick but your pull has been merged. <oriansj>well it is why bus factor is important for key projects, it should be trivial for someone to take my place and continue the work. <guerrilla>(just reading the wiki on discarded ideas) So nobody's been able to make a readable scheme in forth? That's disappointing. I had it as a dream to hex in an assembler, then assemble a forth and forth a scheme :) <oriansj>guerrilla: well assembling a FORTH isn't a difficult task, just harder than writing a C compiler in assembly. (As interpreters are harder to debug during development than compilers) <oriansj>That being said FORTH is not a good language for writing of Garbage collectors (unless you twist your garbage to be entirely on the stack) <oriansj>pabs3: now the problem is extend that enough to run MesCC <guerrilla>oriansj: Yeah, I can see that. My naive attempt would definitely be to try to do gc on the stack. <oriansj>as writing a minimal s-expression evaluator with scheme live primitives isn't anything close to having a proper macro support needed to run real scheme programs (because scheme programmers rarely skip using those features) <oriansj>these sorts of things are certainly interesting and it is easy to see much promise in them. <oriansj>The problem is once you need them to do real work and be extended to support the functionality required to be useful. <oriansj>They just don't live up to the hopes we might have for them. I'd love to be proven wrong but thus far C seems the most easy to implement and extend when it comes to growing functionality to bootstrap from hex to GCC. <oriansj>because a minimal C with structs, ->, arrays and inline assembly covers a great deal of sins. Enough that we were able to bootstrap mes-m2 and run MesCC to get a full bootstrap. <guerrilla>The multiple languages is just more to maintain too as they grow <oriansj>So it isn't about what what is impossible, just more along the lines of much more work to achieve the exact same ends. So it isn't to discourage anyone from pursuing those options but to inform that it will be a bunch of extra work without measurable benefit. <guerrilla>Yeah, ok. If I do it, it'd just be a poc, for the art of it :) <oriansj>or for personal enjoyment which is always a good reason to do something. <theruran>oh I had half an idea - what about using Kernel's vau expressions to bootstrap Guile's syntax-case? 😆 <stikonas>oriansj: thanks for merging. Hopefully you are feeling better <stikonas>oriansj: by the way did you also run some other (arm?) stage0-posix testing in qemu and it was slow or am I misremembering something... <stikonas>if yes, then it's the same qemu issue with the same workaround that I applied to hex1 and hex2 on Risc-V <stikonas>I can also reproduce it when I e.g. run qemu-i386 hex2-0 ... <stikonas>I'm not even sure if bootstrapping Scheme early is the easiest path... Although, mes is what we use right now... <stikonas>but I guess it's mostly historic, that's what already existed, so got used in bootstrap <stikonas>but I'm not really Scheme/Guile/Mes expert, so not really qualified to compare <stikonas>siraben: isn't blynn-compiler bootstrapped from M2-Planet