Newest at the top
| 2025-01-20 12:15:51 +0100 | <homo> | anyway, I need to spend a lot of time and energy figuring out how to add pattern guards to hugs, as yacc and imperative programming are very hard to get right |
| 2025-01-20 12:14:53 +0100 | Pozyomka | (~pyon@user/pyon) (Client Quit) |
| 2025-01-20 12:14:52 +0100 | kaskal | (~kaskal@84-115-237-124.cable.dynamic.surfer.at) kaskal |
| 2025-01-20 12:13:51 +0100 | kaskal | (~kaskal@84-115-237-124.cable.dynamic.surfer.at) (Quit: ZNC - https://znc.in) |
| 2025-01-20 12:13:49 +0100 | monochrom | (trebla@216.138.220.146) |
| 2025-01-20 12:13:48 +0100 | <homo> | it implements tiny language in c and uses that language to recursively implement bigger subset of haskell, that is amazing bootstrap practice |
| 2025-01-20 12:13:31 +0100 | xff0x | (~xff0x@2405:6580:b080:900:89d7:1b64:1ef9:ca1d) |
| 2025-01-20 12:12:57 +0100 | <homo> | another great example is this self-hosting haskell compiler https://github.com/blynn/compiler |
| 2025-01-20 12:11:53 +0100 | <homo> | I rewrote pattern guards to make hugs happy and got entire microhs running inside hugs, even though it throws runtime exception |
| 2025-01-20 12:11:49 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 260 seconds) |
| 2025-01-20 12:11:34 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2025-01-20 12:11:14 +0100 | sprotte24 | (~sprotte24@p200300d16f08390080f981bd603eb58d.dip0.t-ipconnect.de) |
| 2025-01-20 12:11:07 +0100 | SlackCoder | (~SlackCode@64-94-63-8.ip.weststar.net.ky) SlackCoder |
| 2025-01-20 12:10:29 +0100 | <homo> | hugs has everything microhs demands except pattern guards, which are part of haskell2010 |
| 2025-01-20 12:09:46 +0100 | <homo> | take a look at microhs, it only demands haskell2010 (and several extentions supported by hugs), but in return implements over 50 ghc-specific extentions |
| 2025-01-20 12:09:18 +0100 | <__monty__> | Well, GHC itself. Someone's been trying to get every old version of GHC building recently-ish. Presumably that'd be enough to build current GHC. |
| 2025-01-20 12:09:11 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-01-20 12:09:08 +0100 | sroso | (~sroso@user/SrOso) (Client Quit) |
| 2025-01-20 12:08:52 +0100 | <homo> | also self-hosting language implementation is not big of a deal if it uses subset of its own features to implement itself |
| 2025-01-20 12:08:10 +0100 | sroso | (~sroso@user/SrOso) SrOso |
| 2025-01-20 12:07:46 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-01-20 12:07:37 +0100 | <homo> | kuribas ghc is not bootstrappable at all, there is no haskell implementation that has enough features to deal with ghc and its internal quirks |
| 2025-01-20 12:05:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-20 12:05:53 +0100 | <homo> | the bootstrappable seeds they use are https://github.com/oriansj/bootstrap-seeds and they are smaller than 500 bytes |
| 2025-01-20 12:04:58 +0100 | sroso | (~sroso@user/SrOso) (Read error: Connection reset by peer) |
| 2025-01-20 12:04:48 +0100 | <homo> | __monty__ thanks, but I'm not into forth and there is already #bootstrappable channel on libera, as well as https://bootstrappable.org and https://bootstrapping.miraheze.org/ |
| 2025-01-20 12:04:43 +0100 | sroso | (~sroso@user/SrOso) SrOso |
| 2025-01-20 12:04:27 +0100 | sroso | (~sroso@user/SrOso) (Read error: Connection reset by peer) |
| 2025-01-20 12:04:15 +0100 | sroso | (~sroso@user/SrOso) SrOso |
| 2025-01-20 12:04:03 +0100 | <__monty__> | Interpreter vs compiler doesn't really make a difference. |
| 2025-01-20 12:03:57 +0100 | sroso | (~sroso@user/SrOso) (Read error: Connection reset by peer) |
| 2025-01-20 12:03:41 +0100 | sroso | (~sroso@user/SrOso) SrOso |
| 2025-01-20 12:03:35 +0100 | <kuribas> | idris2 is also fully implemented in itself. |
| 2025-01-20 12:03:23 +0100 | sroso | (~sroso@user/SrOso) (Read error: Connection reset by peer) |
| 2025-01-20 12:03:23 +0100 | <kuribas> | homo: You can bootstrap via an interpreter. |
| 2025-01-20 12:02:34 +0100 | sroso | (~sroso@user/SrOso) SrOso |
| 2025-01-20 12:02:32 +0100 | <homo> | kuribas about software, to have software truly bootstrappable, you have to start from very basic features and use those to recursively implement more and more features, so ghc depending on its own extensions to implement those extensions is a horrible practice |
| 2025-01-20 11:59:35 +0100 | <kuribas> | homo: are you talking about hardware or software? |
| 2025-01-20 11:59:03 +0100 | <__monty__> | homo: You might be interested in this series of blogs, https://compilercrim.es/bootstrap/ |
| 2025-01-20 11:57:51 +0100 | <homo> | not to mention historical hardware that nobody has anymore |
| 2025-01-20 11:57:38 +0100 | <kuribas> | https://www.youtube.com/watch?v=RuVS7MsQk4Y |
| 2025-01-20 11:57:21 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-20 11:57:14 +0100 | CiaoSen | (~Jura@2a05:5800:2ce:7100:ca4b:d6ff:fec1:99da) (Ping timeout: 260 seconds) |
| 2025-01-20 11:57:08 +0100 | <homo> | except you don't need historical crufts to have bootstrappable builds if you write code for entire bootstrap chain, it would be hell to replicate all historical software |
| 2025-01-20 11:57:00 +0100 | <kuribas> | There was a guy who build a µM scale lithography machine, but he used modern tech. |
| 2025-01-20 11:55:55 +0100 | aforemny | (~aforemny@2001:9e8:6ce7:fd00:e796:ccd3:bb44:3a2f) aforemny |
| 2025-01-20 11:55:44 +0100 | <kuribas> | homo: you want to replicate ASML with stone tools? :-O |
| 2025-01-20 11:54:07 +0100 | <homo> | it's like start with stone tools to produce modern-day computers |
| 2025-01-20 11:52:09 +0100 | <kuribas> | dminuoso: We do a lot of math at our work, but I find it's often not based on solid theoretical principles. |
| 2025-01-20 11:52:05 +0100 | <homo> | the actual bootstrap chain is longer than that, but you get the idea |