Newest at the top
| 2024-12-28 01:01:43 +0100 | <OftenFaded> | monochrom: you have me in a spiral of doubt with your 'manufactured reasons' point. Is the reason for choosing a language truly arbitrary? And if so, why are we here? Why do we have a liking for haskell over others if it's truly arbitrary? |
| 2024-12-28 01:00:39 +0100 | <haskellbridge> | <sm> matrix edits are a godsend |
| 2024-12-28 01:00:21 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-12-28 00:59:00 +0100 | <geekosaur> | I should back out of convos while trying to eat dinner 🙂 |
| 2024-12-28 00:58:45 +0100 | <geekosaur> | sorry about all the errors there |
| 2024-12-28 00:58:19 +0100 | <geekosaur> | but MicroHS is deliberatelyh missing alkl the type level extensions, which would bring iut to a very fast halt because of TreesThatGrow |
| 2024-12-28 00:57:45 +0100 | <geekosaur> | I don't think anyone has tried |
| 2024-12-28 00:56:46 +0100 | <homo> | what is the latest version of ghc is compileable with microhs considering that microhs supports about 50 extensions? |
| 2024-12-28 00:56:01 +0100 | <geekosaur> | (barely) |
| 2024-12-28 00:55:49 +0100 | <geekosaur> | someone keeps it compiling, apparently |
| 2024-12-28 00:55:46 +0100 | <haskellbridge> | <sm> hell is like a nano haskell, also active |
| 2024-12-28 00:55:35 +0100 | <geekosaur> | and yeh, ghc's pretty extension-happy. we keep getting people writing code for Cabal who trip up over our 5-year support window, meaning their favorite modern extensions don't pass CI |
| 2024-12-28 00:55:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 00:54:44 +0100 | <homo> | what maintenance mode? it hasn't been updated for quite a long time |
| 2024-12-28 00:54:06 +0100 | <geekosaur> | and that's about it. Hugs still holds on in manintenance mode because there are universities that use it |
| 2024-12-28 00:53:48 +0100 | <homo> | and blynn compiler |
| 2024-12-28 00:53:41 +0100 | <geekosaur> | MicroHS |
| 2024-12-28 00:53:32 +0100 | <haskellbridge> | <loonycyborg> what are current most active non-ghc haskell implementations? |
| 2024-12-28 00:52:52 +0100 | <homo> | but that not only creates very long bootstrap chain, but also is very hostile to other implementations of haskell, it is a race for extensions that alternative implementations cannot win |
| 2024-12-28 00:51:33 +0100 | <geekosaur> | that has been extended to "past two versions" and there is some effort for the same version, but not officially supported |
| 2024-12-28 00:51:05 +0100 | <geekosaur> | at one poimnt there was a hard rule that it had to be built with the most recent release of the previous version |
| 2024-12-28 00:50:01 +0100 | <homo> | which makes a real mystery where upstream 7.x binaries come from |
| 2024-12-28 00:49:34 +0100 | <mauke> | possibly perl4 |
| 2024-12-28 00:49:24 +0100 | <mauke> | and the mangler was written in (pretty bad) perl |
| 2024-12-28 00:49:22 +0100 | <homo> | the bootstrap chain is very long and only recently they fixed bootstrap gap in 7.x where compiled ghc 7.4 segfaulted while trying to build itself |
| 2024-12-28 00:48:45 +0100 | <Zenen> | I might just go pick up Erlang |
| 2024-12-28 00:48:10 +0100 | <OftenFaded> | evil mangler...what a glorious name |
| 2024-12-28 00:48:06 +0100 | <haskellbridge> | <loonycyborg> sounds mindbending |
| 2024-12-28 00:47:08 +0100 | <geekosaur> | in the old days ghc generated modified C source which had to be asm-d and then run through a thing called the Evil Mangler which translated the register assignments from platform standard to what the STG engine uses |
| 2024-12-28 00:46:31 +0100 | <homo> | s/complained/complaint/ |
| 2024-12-28 00:46:19 +0100 | <homo> | like you cannot compile ghc 9 with ghc 4 |
| 2024-12-28 00:46:10 +0100 | <homo> | another complained on #bootstrappable is that ghc maintainers require too much extensions to compile ghc, which makes it impossible to build not just with other implementations, but also with ghc itself |
| 2024-12-28 00:46:08 +0100 | <geekosaur> | originally, yes |
| 2024-12-28 00:45:54 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 00:45:41 +0100 | <haskellbridge> | <loonycyborg> unregistered refers to cpu registers? |
| 2024-12-28 00:45:16 +0100 | <Zenen> | this is why I don't think about compilers too much |
| 2024-12-28 00:45:03 +0100 | <geekosaur> | generally you use it as a starting point to write a registerised/asm backend, yes |
| 2024-12-28 00:45:00 +0100 | <Zenen> | i'm suspicious of haskell now |
| 2024-12-28 00:44:41 +0100 | <Zenen> | Can you use that ghc to build faster GHCs? |
| 2024-12-28 00:44:40 +0100 | <haskellbridge> | <loonycyborg> ye I assume it's useful for porting to new platforms |
| 2024-12-28 00:44:20 +0100 | <geekosaur> | the result is very slow but very portable |
| 2024-12-28 00:44:02 +0100 | <geekosaur> | loonycyborg, if you build ghc in unregisterised mode it will generate ANSI C |
| 2024-12-28 00:43:27 +0100 | <homo> | currently guix uses generated C code to compile ghc, but that is not a clean bootstrap, generated code is dirty no matter whether it is C code or machine code |
| 2024-12-28 00:42:42 +0100 | <haskellbridge> | <loonycyborg> can ghc entirely compile itself to C? |
| 2024-12-28 00:42:42 +0100 | <Zenen> | so like... where does one go from this point? |
| 2024-12-28 00:42:01 +0100 | <homo> | there is complaint on #bootstrappable that ghc 0.26 requires ghc, ghc 0.24 was compileable with hbc, but the source code of ghc 0.24 has completely disappeared from the internet |
| 2024-12-28 00:41:30 +0100 | <geekosaur> | (sadly) |
| 2024-12-28 00:41:18 +0100 | <Zenen> | oh goodness |
| 2024-12-28 00:41:18 +0100 | <geekosaur> | and one of those is currently only available as i386 binaries that probably don't even run on modern systems |
| 2024-12-28 00:41:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |