Newest at the top
| 2025-12-16 12:45:37 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 264 seconds) |
| 2025-12-16 12:40:56 +0100 | Maxdamantus | (~Maxdamant@user/maxdamantus) Maxdamantus |
| 2025-12-16 12:40:49 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-16 12:40:11 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-12-16 12:39:40 +0100 | Maxdamantus | (~Maxdamant@user/maxdamantus) (Ping timeout: 255 seconds) |
| 2025-12-16 12:35:23 +0100 | trickard_ | trickard |
| 2025-12-16 12:28:27 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Quit: Leaving) |
| 2025-12-16 12:28:13 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 264 seconds) |
| 2025-12-16 12:23:05 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-12-16 12:20:03 +0100 | xff0x | (~xff0x@2405:6580:b080:900:4560:111e:4edd:d178) |
| 2025-12-16 12:18:48 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Read error: Connection reset by peer) |
| 2025-12-16 12:15:57 +0100 | <dminuoso> | Or is that what you were hinting at? |
| 2025-12-16 12:15:21 +0100 | <dminuoso> | Its what the whole build/foldr fusion works. |
| 2025-12-16 12:14:31 +0100 | <dminuoso> | probie: Joke is on you, thats precisely what GHC does behind the scenes for you in a lot of places. |
| 2025-12-16 12:14:11 +0100 | <haskellbridge> | <magic_rb> Sounds to me like things need to get more generic :) |
| 2025-12-16 12:14:03 +0100 | <dminuoso> | And those problems are exactly the same as the above vector/list problems. |
| 2025-12-16 12:14:00 +0100 | <probie> | (to clarify, my above statement is a joke, since that meets even fewer use cases than a list) |
| 2025-12-16 12:13:54 +0100 | Pixi | (~Pixi@user/pixi) Pixi |
| 2025-12-16 12:13:43 +0100 | <dminuoso> | There's just so much impedance mismatching going on when interfacing with more than one library at a time. |
| 2025-12-16 12:13:24 +0100 | <dminuoso> | Maybe it depends a bit on your problem domain, but in one of our projects there's quite a bit of `pack/unpack`, `fromStrict/ToString` or even combinations going on. |
| 2025-12-16 12:13:17 +0100 | <probie> | Let's just cut out the middle man and pass the fold `data List a = forall b . List ((a -> b -> b) -> b -> b)` |
| 2025-12-16 12:12:54 +0100 | <haskellbridge> | <loonycyborg> There's also Seq, and Set and lots of other containers depending on your needs |
| 2025-12-16 12:11:06 +0100 | <merijn> | So someone wanting to pass a vector can easily convert to a list on demand |
| 2025-12-16 12:10:51 +0100 | <merijn> | especially since Vector.toList is super cheap |
| 2025-12-16 12:10:42 +0100 | <merijn> | dminuoso: A library should use whatever's best for said library |
| 2025-12-16 12:10:15 +0100 | <probie> | Vector is very good for lots of things, and GHC does some very heavy lifting to make List good for lots of other things :p |
| 2025-12-16 12:10:13 +0100 | <haskellbridge> | <magic_rb> Generally List is fine if you dont care about performance and arent storing it around or traversing it in any other direction than linearly forward |
| 2025-12-16 12:09:46 +0100 | <dminuoso> | merijn: For a library thats tought unless you like to duplicate interfaces. And with duplicated things you get the typical `toLazy/fromLazy` nonsense when passing text between library portions. |
| 2025-12-16 12:09:30 +0100 | <merijn> | Vector is very good for lots of things, and List good for lots of other things |
| 2025-12-16 12:09:07 +0100 | <haskellbridge> | <loonycyborg> But still it's procedural state, in haskell you'd want a persistent structure in general. Unless you wanna go all out for a hotspot. |
| 2025-12-16 12:09:06 +0100 | <merijn> | tbh, I'm a big fan of "just thinking about your data type choices" :p |
| 2025-12-16 12:08:50 +0100 | <dminuoso> | Of course it's completely unreasonable for 2 major reasons. |
| 2025-12-16 12:08:30 +0100 | <dminuoso> | Yeah if via backpack I could just swap between vector or list for a given package that would be ideal. |
| 2025-12-16 12:08:26 +0100 | <merijn> | Depending on your usecase |
| 2025-12-16 12:08:17 +0100 | <merijn> | loonycyborg: Vector has a bunch, there's ST, but also IO |
| 2025-12-16 12:08:03 +0100 | <dminuoso> | Right backpack. |
| 2025-12-16 12:07:57 +0100 | <haskellbridge> | <magic_rb> Yeah vector in ST |
| 2025-12-16 12:07:55 +0100 | <probie> | dminuoso: backpack |
| 2025-12-16 12:07:54 +0100 | <merijn> | dminuoso: backpack |
| 2025-12-16 12:07:51 +0100 | <haskellbridge> | <magic_rb> ^ |
| 2025-12-16 12:07:51 +0100 | <haskellbridge> | <loonycyborg> in ST monad? |
| 2025-12-16 12:07:48 +0100 | <dminuoso> | What was that cabal feature along the lines of OCaml functors called again? |
| 2025-12-16 12:07:34 +0100 | <merijn> | probie: Vector doesn't always copy the whole thing, and also mutable Vector exists :) |
| 2025-12-16 12:07:29 +0100 | <dminuoso> | But something without typeclasses |
| 2025-12-16 12:07:23 +0100 | <dminuoso> | I sometimes wish there was a kind of Vector/[] polymorphism, that I could myself decide what I want. |
| 2025-12-16 12:07:01 +0100 | <probie> | Vector requires me to copy the whole thing to "change" a single element. This is often not desirable |
| 2025-12-16 12:06:53 +0100 | <merijn> | Don't get me wrong, Vector is *often* right, but I'm not sure I'd ever recommend defaulting to it |
| 2025-12-16 12:06:51 +0100 | deptype | (~deptype@2406:b400:3a:9d2f:476c:a58e:3471:ff37) |
| 2025-12-16 12:06:38 +0100 | <merijn> | magic_rb: I don't think "generally you should use vector" is right. |
| 2025-12-16 12:06:37 +0100 | <probie> | as in `Integer` is genuinely a better chouce needed for {to,from}Enum in a way that isn't the case in other places `Int` is used instead (like `(!!)`) |