Newest at the top
| 2024-11-18 17:18:42 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate |
| 2024-11-18 17:18:38 +0100 | <dolio> | You should probably check if UnliftedType omits other optimizations. E.G. does GHC still do constructed product returns for them? |
| 2024-11-18 17:17:32 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) (Quit: Nothing to see here. I wasn't there.) |
| 2024-11-18 17:16:53 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) |
| 2024-11-18 17:16:19 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2024-11-18 17:06:33 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 17:06:03 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 17:05:59 +0100 | Alleria | (~Alleria@user/alleria) Alleria |
| 2024-11-18 17:04:46 +0100 | Alleria | (~Alleria@user/alleria) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2024-11-18 16:57:35 +0100 | Alleria | (~Alleria@user/alleria) Alleria |
| 2024-11-18 16:56:23 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 16:55:52 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 16:55:04 +0100 | <Wygulmage> | I guess it operates at a less general level. |
| 2024-11-18 16:54:52 +0100 | <Wygulmage> | I assumed that GHC would unpack anything of `BoxedRep r`, regardless of whether `r` was lifted or unlifted. |
| 2024-11-18 16:54:08 +0100 | <dolio> | Certainly there's no reason you couldn't. |
| 2024-11-18 16:53:47 +0100 | <dolio> | I don't know. I guess they figured you wouldn't be unpacking unlifted data types into other types. |
| 2024-11-18 16:53:12 +0100 | <Wygulmage> | Huh. I wonder whether that's a bug or a feature. |
| 2024-11-18 16:52:07 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-11-18 16:51:33 +0100 | Alleria | (~Alleria@user/alleria) (Ping timeout: 276 seconds) |
| 2024-11-18 16:51:29 +0100 | <dolio> | But the UnliftedType version is: `floobnar = Up.G (Up.F 5# 6#)` |
| 2024-11-18 16:50:51 +0100 | <dolio> | When F is not UnliftedType, a G value ends up looking like: `floobnar = Up.G 5# 6#` |
| 2024-11-18 16:50:30 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) |
| 2024-11-18 16:50:13 +0100 | <Wygulmage> | That is very good to know. |
| 2024-11-18 16:50:12 +0100 | euleritian | (~euleritia@176.2.4.196) (Read error: Connection reset by peer) |
| 2024-11-18 16:49:49 +0100 | <dolio> | You can see this by messing around with -ddump-simpl. |
| 2024-11-18 16:49:03 +0100 | <dolio> | It appears that if `type F :: UnliftedType` is declared, then `data G = G {-# unpack #-} !F` does not actually unpack F. |
| 2024-11-18 16:47:27 +0100 | <Wygulmage> | It's nice to be able to have the `Baz` wrapper for `Array#`, `ByteArray#`, `MutableByteArray#`, etc., but at this low level, not if it creates an extra indirection. |
| 2024-11-18 16:47:00 +0100 | Alleria_ | (~Alleria@user/alleria) (Ping timeout: 276 seconds) |
| 2024-11-18 16:46:28 +0100 | Alleria | (~Alleria@user/alleria) Alleria |
| 2024-11-18 16:46:11 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 16:45:41 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 16:44:40 +0100 | <Wygulmage> | I was wondering whether the polymorphism would introduce an extra layer of indirection. |
| 2024-11-18 16:43:52 +0100 | <Wygulmage> | So a polymorphic `data Baz ( a :: UnliftedType ) = MkBaz Int# a` will have an equivalent in-memory representation to `data BazBytes = MkMazBytes Int# ByteArray#` when `a` is instantiated to `ByteArray#` |
| 2024-11-18 16:43:17 +0100 | Alleria | (~Alleria@user/alleria) (Ping timeout: 248 seconds) |
| 2024-11-18 16:40:44 +0100 | <Wygulmage> | That's exactly what I wanted to know. |
| 2024-11-18 16:40:35 +0100 | <Wygulmage> | OK, thanks. |
| 2024-11-18 16:40:16 +0100 | Alleria_ | (~Alleria@user/alleria) Alleria |
| 2024-11-18 16:40:09 +0100 | <dolio> | If you're asking about a data definition with a specified kind of UnliftedType, then I'm less certain. I think the answer might still be no. |
| 2024-11-18 16:39:24 +0100 | <dolio> | Are you asking about ByteArray#? Then the answer is no, because it's not defined with data. It's a built-in. |
| 2024-11-18 16:38:24 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-18 16:37:35 +0100 | <Wygulmage> | Right. So UnliftedTypes are inside strict boxes (pointers) that allow the garbage collector to manage them. Does unpacking an unlifted type get rid of that box? |
| 2024-11-18 16:36:01 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 16:35:59 +0100 | <dolio> | You can only unpack data types. |
| 2024-11-18 16:35:31 +0100 | <Wygulmage> | (because GC can rewrite the pointer to actual memory inside the lifted structure that it's been unpacked into) |
| 2024-11-18 16:35:29 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 16:34:56 +0100 | <Wygulmage> | Right. I think we're talking past each other. My understanding is that a ByteArray# is a pointer to another pointer to flat memory that consists of length in bytes and then the bytes. I'm wondering whether unpacking the ByteArray# lifts gets rid of that first pointer, |
| 2024-11-18 16:33:38 +0100 | <dolio> | I don't know exactly how it's represented, though. I guess the structure could be all packed together instead of involving another pointer. |
| 2024-11-18 16:32:26 +0100 | <dolio> | It's a structure. |
| 2024-11-18 16:32:08 +0100 | <dolio> | It's not just a pointer to the beginning of the bytes, because byte arrays e.g. know their length. |
| 2024-11-18 16:30:34 +0100 | <Wygulmage> | The byte array structure as in the actual memory region, or another pointer (to GC-managed memory if unpinned and pinned memory if pinned) to the actual allocated memory? |