Newest at the top
2025-01-22 12:04:19 +0100 | <kuribas> | I wouldn't call haskell "pretty syntax". |
2025-01-22 12:03:57 +0100 | <kuribas> | there idris2 with optional lazyness. |
2025-01-22 12:03:50 +0100 | agent314 | (~quassel@208.131.130.116) agent314 |
2025-01-22 12:03:39 +0100 | agent314 | (~quassel@208.131.130.89) (Ping timeout: 265 seconds) |
2025-01-22 12:03:00 +0100 | <homo> | I'll say it more completely: lazy statically-typed with IO monad and pretty syntax, combination of which cannot be found in other languages |
2025-01-22 12:02:59 +0100 | <geekosaur> | curry |
2025-01-22 12:01:48 +0100 | <kuribas> | homo: "lazy statically-typed", are there other than haskell? |
2025-01-22 12:01:23 +0100 | pointlessslippe1 | (~pointless@62.106.85.17) pointlessslippe1 |
2025-01-22 11:58:55 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 264 seconds) |
2025-01-22 11:58:29 +0100 | j1n37- | (~j1n37@user/j1n37) j1n37 |
2025-01-22 11:58:10 +0100 | <homo> | hellwolf I'm focused on something more realistic than bootstrapping ghc and porting ghc to different platform (whether it is processor instuction set or operating system), bootstrapping haskell on different platform doesn't imply bootstrapping ghc, I don't intend to sound like ghc's stakeholder, rather I respect their lack of interest by not working with them |
2025-01-22 11:57:44 +0100 | pointlessslippe1 | (~pointless@62.106.85.17) (Read error: Connection reset by peer) |
2025-01-22 11:50:46 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
2025-01-22 11:47:53 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 245 seconds) |
2025-01-22 11:44:41 +0100 | chele | (~chele@user/chele) chele |
2025-01-22 11:43:49 +0100 | __monty__ | (~toonn@user/toonn) toonn |
2025-01-22 11:42:59 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
2025-01-22 11:42:58 +0100 | j1n37- | (~j1n37@user/j1n37) (Ping timeout: 272 seconds) |
2025-01-22 11:41:28 +0100 | xff0x | (~xff0x@2405:6580:b080:900:55d6:5b69:524c:1857) |
2025-01-22 11:40:52 +0100 | hellwolf | retiring from this thread, I guess I got lost somewhere |
2025-01-22 11:40:21 +0100 | <hellwolf> | huh, why plan9 was brought up. |
2025-01-22 11:39:28 +0100 | <homo> | kuribas 1. for clean bootstrap something other than ghc must be able to convert ghc language into c language, 2. practically plan9 is so different that you'll need to rewrite generated c code by hand |
2025-01-22 11:38:18 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 245 seconds) |
2025-01-22 11:37:04 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
2025-01-22 11:36:54 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
2025-01-22 11:36:38 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 245 seconds) |
2025-01-22 11:36:29 +0100 | <homo> | just to port microhs to plan9 I'll still have to rewrite combinator virtual machine to align with plan9, and on top of that I'll need to get rid of all posix and ffi dependencies in haskell code |
2025-01-22 11:35:51 +0100 | <merijn> | kuribas: Only kinda |
2025-01-22 11:35:00 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 276 seconds) |
2025-01-22 11:34:24 +0100 | j1n37- | (~j1n37@user/j1n37) j1n37 |
2025-01-22 11:34:20 +0100 | <homo> | merijn and practically microhs "not being haskell" is irrelevant if all I want is to have compiler for lazy statically-typed functional programming language on plan9, even if ghc was on plan9 I would unlikely be able to build more than 1% of packages on stackage, because plan9 is neither posix nor microsoft windows |
2025-01-22 11:34:18 +0100 | <kuribas> | Can you not compile ghc to C, and bootstrap from there? |
2025-01-22 11:34:12 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-01-22 11:30:33 +0100 | EvanR | (~EvanR@user/evanr) (Ping timeout: 252 seconds) |
2025-01-22 11:30:24 +0100 | tnt2 | tnt1 |
2025-01-22 11:30:23 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 245 seconds) |
2025-01-22 11:29:14 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
2025-01-22 11:29:09 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
2025-01-22 11:27:51 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 276 seconds) |
2025-01-22 11:25:34 +0100 | <homo> | the only thing that can be worse than ghc in terms of quality is zig, because to bootstrap zig you need to rebuild zig 0.10.0 32 times and zig 0.11.0 16 times, all those 48 are slightly different from each other, but broken enough to need step-by-step source code adjustments after every build |
2025-01-22 11:24:39 +0100 | <merijn> | Even UHC is questionable, since it presumably can't compile large parts of Hackage |
2025-01-22 11:24:21 +0100 | <merijn> | I mean, at this point anything that's not GHC isn't Haskell in any practical sense, tbh. |
2025-01-22 11:23:47 +0100 | <homo> | merijn don't bother, like I said earlier my goal is to get haskell to plan9 and I am satisfied with microhs |
2025-01-22 11:23:42 +0100 | <merijn> | Who cares, how often do you think new platforms get bootstrapped? |
2025-01-22 11:23:40 +0100 | <geekosaur> | you want to make life hard for yourself, go right ahead. don't demand everyone else bow to your insistence |
2025-01-22 11:23:30 +0100 | <merijn> | "It takes time and is annoying to do"? |
2025-01-22 11:23:22 +0100 | <merijn> | homo: So? What's the problem with bootstrapping via ancient versions? |
2025-01-22 11:22:44 +0100 | <homo> | geekosaur thank goodness I'm not stakeholder, but that was reply to suggestions such as building from ancient ghc or doing cross-compiling |
2025-01-22 11:22:32 +0100 | <geekosaur> | C doesn't have these problems because C doesn't change that redically |
2025-01-22 11:22:28 +0100 | <merijn> | homo: ok, so suppose we spend 5 or so man-years to make GHC 9 be compilable with GHC 4. Then what? What exactly is the benefit of that massive time investment? |