IRCBrowseLink
2025-04-06 21:35:33 +0200 <EvanR> does hugs even "build" stuff?
2025-04-06 21:36:10 +0200 <mauke> |cos|: you're probably not going to have much luck there. hugs is a haskell interpreter (written in C), so there's not much "building" you're going to get out of it
2025-04-06 21:36:54 +0200ham(~ham@user/ham) ham
2025-04-06 21:37:08 +0200 <mauke> also, there hasn't been a hugs release in the last ... 20 years?
2025-04-06 21:37:37 +0200 <|cos|> i figured the answer would be something like this, but it never hurts to ask. thanks! (:
2025-04-06 21:37:49 +0200remexre(~remexre@user/remexre) (Remote host closed the connection)
2025-04-06 21:38:18 +0200 <mauke> basically, anything not explicitly written in what amounts to an ancient haskell dialect won't run on it
2025-04-06 21:38:46 +0200 <|cos|> the next question, probably with a similar answer, then becomes: would one have any hope of running ghc on top of haiku?
2025-04-06 21:38:56 +0200 <EvanR> written in C is good because at least you won't need a working haskell compiler to compiler hugs
2025-04-06 21:39:33 +0200 <mauke> wait, was haiku the beos thing?
2025-04-06 21:39:58 +0200 <|cos|> typ, that's the thing. and i notice there is a thread at https://discuss.haiku-os.org/t/ghc-haskell-compiler/677
2025-04-06 21:42:25 +0200 <EvanR> yes
2025-04-06 21:43:01 +0200 <EvanR> can GHC be ported to haiku, yes
2025-04-06 21:43:22 +0200 <EvanR> will you or me be the one to do it? situation unclear
2025-04-06 21:48:44 +0200 <monochrom> Very clear, the answer is "no". :)
2025-04-06 21:49:08 +0200 <|cos|> it appears to be more of a bug fix than a full port, according to that thread. but, yeah. answer is likely still no.
2025-04-06 21:49:30 +0200 <EvanR> well that thread is 15 years old
2025-04-06 21:49:39 +0200 <EvanR> none of the information may be relevant
2025-04-06 21:51:58 +0200 <energizer> what is the difference between mconcat and fold?
2025-04-06 21:52:12 +0200 <EvanR> :t mconcat
2025-04-06 21:52:13 +0200 <lambdabot> Monoid a => [a] -> a
2025-04-06 21:52:15 +0200 <EvanR> :t fold
2025-04-06 21:52:16 +0200 <lambdabot> (Foldable t, Monoid m) => t m -> m
2025-04-06 21:52:38 +0200 <energizer> what is the point of mconcat then? doesn't fold do the job?
2025-04-06 21:52:46 +0200 <|cos|> the thread might have started fiftheen years ago, but the latest post is merely four years old.
2025-04-06 21:53:05 +0200 <EvanR> Foldable is a lot newer in history than Monoid
2025-04-06 21:53:28 +0200 <EvanR> so it's one of many cases of more general library functions becoming available and the special cases not being removed so as not to break anything
2025-04-06 21:54:02 +0200 <|cos|> but nah. i'm not invested enough to debug and fix assembler generation specific to x86_64. :/
2025-04-06 21:54:46 +0200hgolden(~hgolden@2603:8000:9d00:3ed1:2fa6:8257:2d41:b9b0) (Remote host closed the connection)
2025-04-06 21:55:18 +0200 <EvanR> see also the debate over whether "map" is pointless since there is fmap
2025-04-06 21:58:12 +0200inca(~inca@pool-96-255-212-224.washdc.fios.verizon.net)
2025-04-06 21:58:46 +0200hgolden(~hgolden@2603:8000:9d00:3ed1:1b03:b08c:d961:6530) hgolden
2025-04-06 22:03:40 +0200inca(~inca@pool-96-255-212-224.washdc.fios.verizon.net) (Ping timeout: 252 seconds)
2025-04-06 22:05:45 +0200ham(~ham@user/ham) (Quit: WeeChat 3.5)
2025-04-06 22:06:57 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Quit: Leaving)
2025-04-06 22:11:00 +0200AlexZenon(~alzenon@178.34.162.245) (Ping timeout: 252 seconds)
2025-04-06 22:16:07 +0200inca(~inca@pool-96-255-212-224.washdc.fios.verizon.net)
2025-04-06 22:18:29 +0200AlexZenon(~alzenon@178.34.162.245)
2025-04-06 22:21:19 +0200inca(~inca@pool-96-255-212-224.washdc.fios.verizon.net) (Ping timeout: 244 seconds)
2025-04-06 22:36:40 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-04-06 22:41:11 +0200IlyaChernov566(~IlyaChern@82.215.95.81)
2025-04-06 22:43:03 +0200 <IlyaChernov566> I, for one, think Elon is doing a wonderful job
2025-04-06 22:43:27 +0200 <EvanR> this channel is about haskell, a programming language
2025-04-06 22:43:34 +0200IlyaChernov566(~IlyaChern@82.215.95.81) (Remote host closed the connection)
2025-04-06 22:48:47 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-06 22:48:49 +0200JuanDaugherty(~juan@user/JuanDaugherty) JuanDaugherty
2025-04-06 22:50:25 +0200michalz(~michalz@185.246.207.215) (Remote host closed the connection)
2025-04-06 22:55:44 +0200sh1n(~sh1n@2800:2134:583f:e223:7b49:e90d:6522:419d) sh1n
2025-04-06 22:55:45 +0200troydm(~troydm@user/troydm) (Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset)
2025-04-06 22:57:57 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-04-06 22:58:14 +0200Guest90(~Guest90@76.78.179.109)
2025-04-06 22:59:12 +0200inca(~inca@pool-96-255-212-224.washdc.fios.verizon.net)
2025-04-06 23:04:01 +0200inca(~inca@pool-96-255-212-224.washdc.fios.verizon.net) (Ping timeout: 268 seconds)
2025-04-06 23:08:48 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2025-04-06 23:10:49 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-06 23:11:23 +0200troydm(~troydm@user/troydm) troydm
2025-04-06 23:14:34 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-04-06 23:16:21 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds)
2025-04-06 23:24:58 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 245 seconds)
2025-04-06 23:26:35 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-06 23:27:09 +0200 <hellwolf> I made a lineartype mutable vector hack for https://0xd34df00d.me/posts/2024/09/naive-nfas.html#linear-vectors
2025-04-06 23:27:22 +0200 <hellwolf> now it is almost as fast as the ST monad version.
2025-04-06 23:28:04 +0200 <hellwolf> not sure where contributing to the remaining the slow factor
2025-04-06 23:31:33 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2025-04-06 23:32:17 +0200 <EvanR> confirmed linearity probably doesn't bear on performance in haskell
2025-04-06 23:32:30 +0200 <EvanR> it's more of a type system thing
2025-04-06 23:33:03 +0200 <haskellbridge> <hellwolf> I can't come up with a something that can show case linearity + par/pseq yet
2025-04-06 23:33:09 +0200 <haskellbridge> <hellwolf> that's where ST monad wouldn't be able to do
2025-04-06 23:33:48 +0200 <EvanR> parallel programming ought to bear on performance
2025-04-06 23:33:56 +0200 <haskellbridge> <hellwolf> but I do generally agree that linearity is a type safety feature.
2025-04-06 23:34:20 +0200 <haskellbridge> <hellwolf> and there is a lot of millage we could get with it.
2025-04-06 23:34:39 +0200 <haskellbridge> <hellwolf> I did this experiment because I wanted to make sure it doesn't have fundamental performance issue.
2025-04-06 23:34:54 +0200 <haskellbridge> <hellwolf> in theory, it shouldn't. But in practice, it lacks a few library.
2025-04-06 23:35:02 +0200 <haskellbridge> <hellwolf> especially the unboxed immutable data types.
2025-04-06 23:35:15 +0200 <haskellbridge> <hellwolf> that's why I made the hack to just see if I am missing sometthing
2025-04-06 23:35:33 +0200 <haskellbridge> <hellwolf> I will wrap up the code a little and share it here.
2025-04-06 23:35:37 +0200 <EvanR> using unsafe such and such maybe you can write the library
2025-04-06 23:35:56 +0200 <haskellbridge> <hellwolf> yea, not I used unsafe with mutable unboxed vector
2025-04-06 23:36:08 +0200 <haskellbridge> <hellwolf> s/not//
2025-04-06 23:37:04 +0200 <EvanR> interesting that the unboxed code ended up with a tight gc-less loop
2025-04-06 23:37:17 +0200 <EvanR> good for performance, but bad for interruptibility
2025-04-06 23:38:15 +0200 <haskellbridge> <hellwolf> If the language allow you to organize code into safe and unsafe blocks nicely, I think that is fine.
2025-04-06 23:38:45 +0200 <EvanR> the unsafe kernel of trust hidden in an "internal" module with a type safe interface
2025-04-06 23:38:49 +0200amadaluzia(~amadaluzi@user/amadaluzia) (Ping timeout: 260 seconds)
2025-04-06 23:38:56 +0200 <haskellbridge> <hellwolf> Some people may even push for complete separation of syntax and semantics
2025-04-06 23:39:10 +0200amadaluzia(~amadaluzi@user/amadaluzia) amadaluzia
2025-04-06 23:39:21 +0200 <monochrom> We were hoping that IO was how we would organize code into safe and unsafe blocks. :)
2025-04-06 23:39:46 +0200 <haskellbridge> <hellwolf> that's boomer tech
2025-04-06 23:39:49 +0200 <haskellbridge> <hellwolf> :p
2025-04-06 23:40:03 +0200 <EvanR> if the non IO language was total then maybe, but still probably not
2025-04-06 23:40:30 +0200 <monochrom> What happens is that different people define "safe" differently.
2025-04-06 23:40:58 +0200 <monochrom> E.g., I totally (pun!) accept partial functions as safe. Apparently I'm in the minority.
2025-04-06 23:41:00 +0200 <haskellbridge> <hellwolf> https://safe.js.org/
2025-04-06 23:41:14 +0200 <haskellbridge> <hellwolf> sorry, that was a random post.
2025-04-06 23:41:18 +0200 <c_wraith> Safe Haskell kind of crashed and burned because no one agrees what safe means
2025-04-06 23:41:34 +0200 <EvanR> my webserver is totally safe. Somebody uploads a request which triggers a partial function call leading to freeze up
2025-04-06 23:41:47 +0200 <c_wraith> my web server is totally safe, because I didn't start it.
2025-04-06 23:42:20 +0200 <EvanR> safe -> js -> Void
2025-04-06 23:42:22 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-06 23:43:27 +0200 <EvanR> "safe" gets brought up in conjunction with rust, maybe they have a definition