Logs: liberachat/#haskell
| 2025-12-10 16:16:27 | → | trickard_ joins (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-10 16:17:07 | × | ec quits (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2025-12-10 16:19:55 | × | mooon quits (~mooon@user/mooon) (Ping timeout: 240 seconds) |
| 2025-12-10 16:24:54 | ← | L29Ah parts (~L29Ah@wikipedia/L29Ah) () |
| 2025-12-10 16:27:55 | → | machinedgod joins (~machinedg@d75-159-126-101.abhsia.telus.net) |
| 2025-12-10 16:30:40 | <haskellbridge> | <Zemyla> Like, I'm thinking about fingertrees, and I'm at the very least thinking that Digits should be unlifted. |
| 2025-12-10 16:33:14 | × | lucabtz quits (~lucabtz@user/lucabtz) (Remote host closed the connection) |
| 2025-12-10 16:39:42 | <haskellbridge> | <Morj> Zemyla what do you mean «boxed unlifted»? Did you mean that the structures that were boxed you want to make unlifted? |
| 2025-12-10 16:39:54 | <haskellbridge> | <Morj> Unlifted values can help performance in tight loops when ghc optimizer can't unlift your data by itself for whatever reason. When not in tight loops, it can confuse the regular optimizations and rewrite rules though |
| 2025-12-10 16:41:41 | <haskellbridge> | <Zemyla> You know the standard fingertree structure, right? data FingerTree a = Empty | Single a | Deep !Int !(Digit a) (FingerTree (Node a)) !(Digit a)? |
| 2025-12-10 16:41:47 | × | trickard_ quits (~trickard@cpe-83-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-10 16:41:52 | <haskellbridge> | <Morj> Plus, and I may be wrong about it, unboxed values interact differently with gc and may use its slower algorithms |
| 2025-12-10 16:41:57 | <haskellbridge> | <Zemyla> I'm thinking of making the Digits boxed unlifted. |
| 2025-12-10 16:42:00 | → | trickard_ joins (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-10 16:42:31 | <haskellbridge> | <Morj> Honestly not familiar! But the answer depends on what you want to do with the Digits after construction |
| 2025-12-10 16:42:37 | <haskellbridge> | <Zemyla> I'm pretty sure they use the same algorithm, given arrays are examples of boxed unlifted arrays. |
| 2025-12-10 16:43:02 | <haskellbridge> | <Zemyla> *boxed unlifted values. |
| 2025-12-10 16:43:30 | → | tromp joins (~textual@2001:1c00:3487:1b00:fc9c:738b:219c:bafe) |
| 2025-12-10 16:44:47 | <haskellbridge> | <Morj> I googled the terminology: unlifted is anything that can't have bottom; unboxed types are unlifted, but not all that is unlifted is unboxed. Right? |
| 2025-12-10 16:49:48 | <haskellbridge> | <Morj> Yes, I confused unlifted and unboxed. You mentioned like MutableByteArray# that is boxed but unlifted |
| 2025-12-10 16:51:16 | <haskellbridge> | <Morj> That's cool. I don't know anything about the performance of unlifted types |
| 2025-12-10 16:52:50 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 245 seconds) |
| 2025-12-10 16:53:26 | → | sindu joins (~sindu@2.148.32.207.tmi.telenormobil.no) |
| 2025-12-10 16:59:12 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-12-10 16:59:41 | <haskellbridge> | <Zemyla> https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/primitives.html#unlifted-datatypes |
| 2025-12-10 17:00:07 | <dolio> | Will it make a difference to justify the effort in this case, though? |
| 2025-12-10 17:02:31 | × | __monty__ quits (~toonn@user/toonn) (Quit: Lost terminal) |
| 2025-12-10 17:02:58 | <dolio> | I guess it might not be much effort, but what does it do other than eliminate the ! around Digit in the finger tree definition? I don't think digts are used except incidentally in the implementation, so changing their overall calling convention doesn't seem like it'd affect much. |
| 2025-12-10 17:03:35 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 240 seconds) |
| 2025-12-10 17:04:05 | <haskellbridge> | <Morj> Since 9.2, that's older than I thought. I'll remember it next time I'm writing some benchmark |
| 2025-12-10 17:04:51 | × | chele quits (~chele@user/chele) (Remote host closed the connection) |
| 2025-12-10 17:05:23 | <dolio> | I think the feature is more for when you're directly using some structure widely, and you know it should remain evaluated, so you'd have to sprinkle ! on a lot of arguments of the type. |
| 2025-12-10 17:05:27 | <haskellbridge> | <Zemyla> True. What might make a bigger difference is the next idea. I'm thinking of Elem a = Elem2 a a | Elem3 a a a, and Node a = Node2 !Int !a !a | Node3 !Int !a !a !a |
| 2025-12-10 17:06:26 | <haskellbridge> | <Zemyla> Nodes only contain Elems or other Nodes. I might make Elem and Node unlifted. |
| 2025-12-10 17:06:55 | <dolio> | And might be an optimization in that case, because putting ! on arguments means that GHC has to insert code to evaluate things that might already be evaluated. |
| 2025-12-10 17:10:55 | × | kuribas quits (~user@ip-188-118-57-242.reverse.destiny.be) (Ping timeout: 240 seconds) |
| 2025-12-10 17:12:21 | → | Square2 joins (~Square@user/square) |
| 2025-12-10 17:13:57 | × | trickard_ quits (~trickard@cpe-83-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-10 17:14:10 | → | trickard_ joins (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-10 17:14:24 | <haskellbridge> | <Zemyla> There's a couple issues, though. The big one is Traversable. |
| 2025-12-10 17:14:48 | → | tzh joins (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2025-12-10 17:15:22 | <haskellbridge> | <Zemyla> The other one is that the values in a Node aren't always strict (for instance, with inits and tails). |
| 2025-12-10 17:15:55 | × | Square quits (~Square4@user/square) (Ping timeout: 240 seconds) |
| 2025-12-10 17:17:27 | <dolio> | Yeah, some of the asymptotic performance of finger trees depends on laziness, so I'm not sure you can make Node unlifted. |
| 2025-12-10 17:17:34 | <dolio> | I don't recall the details, though. |
| 2025-12-10 17:20:33 | × | wootehfoot quits (~wootehfoo@user/wootehfoot) (Quit: Leaving) |
| 2025-12-10 17:25:32 | elarks1 | is now known as elarks |
| 2025-12-10 17:26:33 | × | tromp quits (~textual@2001:1c00:3487:1b00:fc9c:738b:219c:bafe) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-10 17:26:49 | <larsivi> | Morj: There are default colors, but only a couple of elements in vague colors. Since haskell-vim hasn't been updated in a few years, I thought that could be a reason too. I suppose I have LSP via haskell-tools, but it hasn't brought a lot of colors (yet!) |
| 2025-12-10 17:29:00 | → | tromp joins (~textual@2001:1c00:3487:1b00:fc9c:738b:219c:bafe) |
| 2025-12-10 17:30:35 | <haskellbridge> | <Morj> My fork of haskell-vim also hasn't been updated in how many years and still works, so I doubt that /that/ is the problem |
| 2025-12-10 17:31:27 | <haskellbridge> | <Morj> Your original problem was that the haskell-vim colors look like the original colors? |
| 2025-12-10 17:36:40 | → | wootehfoot joins (~wootehfoo@user/wootehfoot) |
| 2025-12-10 17:37:07 | <haskellbridge> | <Morj> Wow, comparing them side by side right now, today I wouldn't make the choice to use haskell-vim, the default colors are just fine |
| 2025-12-10 17:40:47 | → | __monty__ joins (~toonn@user/toonn) |
| 2025-12-10 17:48:57 | <larsivi> | Hah, maybe I'm just a colorful person! I suppose I'll find some neovimmy place to ask :) Thanks! I'm sure I'll be back with other questions when I get into actual Haskell issues. |
| 2025-12-10 17:49:30 | → | skum joins (~skum@user/skum) |
| 2025-12-10 17:54:40 | → | jmcantrell_ joins (~weechat@user/jmcantrell) |
| 2025-12-10 18:04:11 | → | target_i joins (~target_i@user/target-i/x-6023099) |
| 2025-12-10 18:07:49 | × | szkl quits (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-12-10 18:12:02 | → | kuribas joins (~user@2a02:1808:e7:7fdf:108a:7b48:1ca0:3c37) |
| 2025-12-10 18:20:43 | × | ljdarj quits (~Thunderbi@user/ljdarj) (Ping timeout: 264 seconds) |
| 2025-12-10 18:21:37 | × | tromp quits (~textual@2001:1c00:3487:1b00:fc9c:738b:219c:bafe) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-10 18:29:41 | → | tromp joins (~textual@2001:1c00:3487:1b00:fc9c:738b:219c:bafe) |
| 2025-12-10 18:32:31 | × | kuribas quits (~user@2a02:1808:e7:7fdf:108a:7b48:1ca0:3c37) (Remote host closed the connection) |
| 2025-12-10 18:32:45 | → | kuribas joins (~user@2a02:1808:e7:7fdf:840:a1e:53dc:e766) |
| 2025-12-10 18:35:30 | → | ephemient joins (uid407513@user/ephemient) |
| 2025-12-10 18:41:19 | → | ljdarj joins (~Thunderbi@user/ljdarj) |
| 2025-12-10 18:47:05 | × | gmg quits (~user@user/gehmehgeh) (Quit: Leaving) |
| 2025-12-10 18:58:24 | × | ChaiTRex quits (~ChaiTRex@user/chaitrex) (Quit: ChaiTRex) |
| 2025-12-10 18:59:57 | × | farn__ quits (~farn@2a03:4000:7:3cd:d4ab:85ff:feeb:f505) (Ping timeout: 250 seconds) |
| 2025-12-10 19:00:34 | → | farn__ joins (~farn@2a03:4000:7:3cd:d4ab:85ff:feeb:f505) |
| 2025-12-10 19:01:29 | → | ChaiTRex joins (~ChaiTRex@user/chaitrex) |
| 2025-12-10 19:07:59 | × | kuribas quits (~user@2a02:1808:e7:7fdf:840:a1e:53dc:e766) (Ping timeout: 244 seconds) |
| 2025-12-10 19:10:00 | → | milan joins (~milan@88.212.61.169) |
| 2025-12-10 19:11:01 | <milan> | Hello guyz why https://hackage.haskell.org/package/base-4.21.0.0/docs/GHC-IO-StdHandles.html has "Portability non-portable" specified when it's purpose is to be portable? This is written in docs "This model abstracts away the platform specific handles that can be toggled through the RTS." |
| 2025-12-10 19:12:33 | <tomsmeding> | the Portability field in the module metadata is for portability across compilers. The stuff under "GHC." is, unsurprisingly, not at all portable to compilers other than GHC. |
| 2025-12-10 19:13:27 | <tomsmeding> | although with GHC being essentially the only realistic compiler for Haskell for the past decade(s?), these metadata fields are not always filled in quite as diligently as one might hope |
| 2025-12-10 19:13:51 | × | cyphase quits (~cyphase@user/cyphase) (Read error: Connection reset by peer) |
| 2025-12-10 19:15:13 | → | cyphase joins (~cyphase@user/cyphase) |
| 2025-12-10 19:16:23 | → | ljdarj1 joins (~Thunderbi@user/ljdarj) |
| 2025-12-10 19:20:07 | × | ljdarj quits (~Thunderbi@user/ljdarj) (Ping timeout: 240 seconds) |
| 2025-12-10 19:20:08 | ljdarj1 | is now known as ljdarj |
| 2025-12-10 19:20:15 | <milan> | tomsmeding: But this does not prevent using different backend (native, LLVM, c ...) right? Only different compiler altogether like "hugs"? |
| 2025-12-10 19:27:43 | × | machinedgod quits (~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 240 seconds) |
| 2025-12-10 19:28:21 | <tomsmeding> | milan: that should indeed be true. Although these functions in particular you should probably get from System.IO instead of GHC.IO.StdHandles |
| 2025-12-10 19:31:20 | × | Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 244 seconds) |
| 2025-12-10 19:31:46 | → | Lord_of_Life joins (~Lord@user/lord-of-life/x-2819915) |
| 2025-12-10 19:32:55 | × | ljdarj quits (~Thunderbi@user/ljdarj) (Ping timeout: 240 seconds) |
| 2025-12-10 19:34:32 | → | ljdarj joins (~Thunderbi@user/ljdarj) |
| 2025-12-10 19:36:06 | <monochrom> | In this case, "platform" means Linux vs Windows vs MacOS vs BSD vs... |
| 2025-12-10 19:38:47 | → | ljdarj1 joins (~Thunderbi@user/ljdarj) |
| 2025-12-10 19:40:49 | × | ljdarj quits (~Thunderbi@user/ljdarj) (Ping timeout: 264 seconds) |
| 2025-12-10 19:40:49 | ljdarj1 | is now known as ljdarj |
| 2025-12-10 19:41:27 | → | kuribas joins (~user@2a02:1808:e7:7fdf:2747:3312:d53c:fc8c) |
| 2025-12-10 19:43:15 | × | sord937 quits (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2025-12-10 19:43:51 | → | AlexZenon_2 joins (~alzenon@85.174.180.40) |
| 2025-12-10 19:44:13 | → | ss4 joins (~wootehfoo@user/wootehfoot) |
| 2025-12-10 19:44:32 | → | Sgeo_ joins (~Sgeo@user/sgeo) |
| 2025-12-10 19:46:22 | → | ljdarj1 joins (~Thunderbi@user/ljdarj) |
All times are in UTC.