2025/11/14

Newest at the top

2025-11-14 17:44:36 +0100Googulator44(~Googulato@team.broadbit.hu)
2025-11-14 17:44:28 +0100 <haskellbridge> <loonycyborg> It's just implementing such containers is generally done via hashing and it just wasn't a widespread thing when haskell was originally designed
2025-11-14 17:44:21 +0100Googulator44(~Googulato@team.broadbit.hu) (Quit: Client closed)
2025-11-14 17:43:21 +0100 <haskellbridge> <loonycyborg> In fact having a set(which is a list in no particular order) as a basic builtin type for a language like haskell would make sense I think :P
2025-11-14 17:40:42 +0100bggd(~bgg@2a01:e0a:819:1510:cb15:dfb4:31e5:1dfe)
2025-11-14 17:40:08 +0100 <haskellbridge> <loonycyborg> so that should be unordered list which isn't a built-in feature in haskell
2025-11-14 17:39:48 +0100 <haskellbridge> <loonycyborg> and then items in list can be in different order
2025-11-14 17:39:26 +0100 <haskellbridge> <loonycyborg> I think it's possible to have pure exceptions too but then you'd have to get whole list of exceptions that happened, not random one of them
2025-11-14 17:38:59 +0100Anarchos(~Anarchos@91-161-254-16.subs.proxad.net) Anarchos
2025-11-14 17:38:42 +0100 <haskellbridge> <loonycyborg> They're in IO only because the order they actually happen in at runtime is undefined.
2025-11-14 17:34:14 +0100DetourNetworkUK(~DetourNet@user/DetourNetworkUK) DetourNetworkUK
2025-11-14 17:33:59 +0100Googulator(~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds)
2025-11-14 17:31:40 +0100wootehfoot(~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer)
2025-11-14 17:31:11 +0100 <dolio> I mean, that is how you get well performing exceptions in GHC, but what if you could have catchable exceptions that performed that well, but were sound to use outside of IO?
2025-11-14 17:30:52 +0100DetourNetworkUK(DetourNetw@user/DetourNetworkUK) (Read error: Connection reset by peer)
2025-11-14 17:30:49 +0100 <kuribas> Still much better than a mess of global state in other languages.
2025-11-14 17:30:46 +0100Inline(~inlinE@2001-4dd7-ae97-0-4674-ae6d-2607-c022.ipv6dyn.netcologne.de) Inline
2025-11-14 17:30:41 +0100Googulator44(~Googulato@team.broadbit.hu)
2025-11-14 17:30:31 +0100 <kuribas> RIO is just fine for most of my applications.
2025-11-14 17:30:23 +0100lucabtz(~lucabtz@user/lucabtz) (Remote host closed the connection)
2025-11-14 17:29:50 +0100 <dolio> 'Just dump everything in IO' doesn't sound like a better answer.
2025-11-14 17:29:22 +0100Lord_of_Life_Lord_of_Life
2025-11-14 17:29:19 +0100 <comerijn> I'd rather have checked IO exceptions, though
2025-11-14 17:29:08 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 256 seconds)
2025-11-14 17:28:51 +0100 <kuribas> For exceptional things. Either for expected things (parser error, etc...).
2025-11-14 17:28:36 +0100 <kuribas> I just use IO exceptions
2025-11-14 17:28:02 +0100Lord_of_Life_(~Lord@user/lord-of-life/x-2819915) Lord_of_Life
2025-11-14 17:27:22 +0100DetourNe-DetourNetworkUK
2025-11-14 17:26:43 +0100 <dolio> What if they could be designed the other way to begin with?
2025-11-14 17:26:23 +0100 <dolio> And then having that baked in can influence the large scale design of things. You can do something better than Either in Haskell, but how many things are you going to have to wrap from returning Either?
2025-11-14 17:25:49 +0100spew(~spew@user/spew) (Quit: WeeChat 4.6.3)
2025-11-14 17:25:06 +0100DetourNe-(DetourNetw@user/DetourNetworkUK) DetourNetworkUK
2025-11-14 17:24:49 +0100DetourNetworkUK(~DetourNet@user/DetourNetworkUK) (Read error: Connection reset by peer)
2025-11-14 17:20:48 +0100 <dolio> Like, Either is a bad way to implement exceptions, and assuming you use continuations to support your algebraic effects, the corresponding algebraic effect is automatically better, I think.
2025-11-14 17:19:06 +0100 <dolio> I think it's more like there are many small 'points.'
2025-11-14 17:18:18 +0100Googulator(~Googulato@team.broadbit.hu)
2025-11-14 17:18:01 +0100Googulator(~Googulato@team.broadbit.hu) (Quit: Client closed)
2025-11-14 17:13:30 +0100 <lucabtz> [exa] i dont know a lot about algebraic effects but i dont see the point like kuribas
2025-11-14 17:09:41 +0100L29Ah(~L29Ah@wikipedia/L29Ah) L29Ah
2025-11-14 17:07:08 +0100 <kuribas> Because pure functions become IO due to logging.
2025-11-14 17:06:49 +0100 <kuribas> The only part where it sucks is in logging.
2025-11-14 17:04:42 +0100 <kuribas> comerijn: sure, maybe I haven't gotten a usecase where I would need it.
2025-11-14 17:04:20 +0100 <comerijn> kuribas: I mean, that's nice and may work for you, but that doesn't mean it works for everything
2025-11-14 17:04:06 +0100 <comerijn> Because the alternative is worse
2025-11-14 17:04:02 +0100 <kuribas> I'd try to better separate pure from effectul code.
2025-11-14 17:03:59 +0100 <comerijn> Sometimes you gotta deal with things you don't want :p
2025-11-14 17:03:37 +0100 <kuribas> [exa]: I don't even see why I would want that...
2025-11-14 17:02:39 +0100 <[exa]> kuribas: imagine you have so much effect kinds that you think that an algebra over them would help you.
2025-11-14 17:01:59 +0100 <geekosaur> mtl is very careful to forbid combinations of effects that aren't safe
2025-11-14 17:01:14 +0100 <comerijn> What geekosaur said :p