Newest at the top
| 2026-05-23 11:17:52 +0000 | weary-traveler | (~user@user/user363627) user363627 |
| 2026-05-23 11:16:33 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-05-23 11:13:37 +0000 | Square | (~Square@user/square) Square |
| 2026-05-23 11:08:53 +0000 | <jaror> | I'm also now realizing that perhaps vector is not the best name since it seems to be more associated with dynamically resizable or at least slice-able arrays |
| 2026-05-23 11:05:43 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-05-23 11:05:34 +0000 | <jaror> | I saw this old note and thought something must have happened by now: https://gitlab.haskell.org/ghc/ghc/-/wikis/unpacking-arrays |
| 2026-05-23 11:05:17 +0000 | <jaror> | Oh annoying |
| 2026-05-23 11:05:08 +0000 | <int-e> | That just means it doesn't explicitly hate the pragma. I don't think it *can* actually unpack it. |
| 2026-05-23 11:04:24 +0000 | <jaror> | GHC is not warning me about it at least |
| 2026-05-23 11:04:14 +0000 | <jaror> | You can unpack Array#, I believe |
| 2026-05-23 11:03:47 +0000 | <int-e> | No, for that it would have to be unpacked into the Array type. And that wouldn't work with the GC which treats Array# (= a frozen mutable array) specially. |
| 2026-05-23 11:03:38 +0000 | <jaror> | Yeah, I guess |
| 2026-05-23 11:03:03 +0000 | <jaror> | Oh, won't that be unpacked twice? |
| 2026-05-23 11:02:44 +0000 | <int-e> | Array is data Array a = Array { array#: Array# a } and Array# a has that size and length and elements and a card table |
| 2026-05-23 11:02:40 +0000 | <jaror> | that's the normal vector |
| 2026-05-23 11:02:34 +0000 | <jaror> | So two ints for the slicing and an unpacked `Array` which is just the length and the total size for the card table (indeed) and then n + ceil(n/1024) |
| 2026-05-23 11:02:16 +0000 | <[exa]> | that's the simple vector or the vector vector? |
| 2026-05-23 11:01:43 +0000 | <jaror> | {-# UNPACK #-} !(Array a) |
| 2026-05-23 11:01:43 +0000 | <jaror> | {-# UNPACK #-} !Int |
| 2026-05-23 11:01:43 +0000 | <jaror> | data Vector a = Vector {-# UNPACK #-} !Int |
| 2026-05-23 11:01:43 +0000 | <jaror> | It's just: |
| 2026-05-23 11:01:11 +0000 | <int-e> | wait, it's worse, isn't it? (Mutable)Array# can't be unpacked, so there's a pointer and another tag? |
| 2026-05-23 11:00:56 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-05-23 11:00:48 +0000 | <[exa]> | afaik as with reserve() from C |
| 2026-05-23 11:00:31 +0000 | <jaror> | a length and a size? |
| 2026-05-23 10:59:45 +0000 | <int-e> | Vector has, let me think, a tag, two indices, a length, a size, n indices, ceil(n/1024) extra words (assuming 8 byte words) |
| 2026-05-23 10:59:45 +0000 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2026-05-23 10:59:09 +0000 | <jaror> | I now often use lists where I think I really should use vectors/arrays instead, but there is no lightweight simple array/vector package. |
| 2026-05-23 10:59:07 +0000 | <[exa]> | Rembane: re "performance properties of lenses" -- I somehow got the feeling that prolens exploited stuff inherent to compilers in a weird way ( (->) is a profunctor that is used there instead of Identity, thus it saves a level of wrapery over the plain (->) that ghc is very good at handling of). Thought it might be relevant to have a look there. |
| 2026-05-23 10:58:26 +0000 | <jaror> | I don't think that's specifically the main use case. I think this will be my go-to package for anything but the case where I need large mutable arrays. |
| 2026-05-23 10:56:39 +0000 | <[exa]> | btw as far as I get it the main use-case for users is for programs that have lots of tiny vectors, right? I'd throw that into the main description. |
| 2026-05-23 10:55:37 +0000 | <[exa]> | ah yes then write "compile" and perhaps point to lack of dependencies |
| 2026-05-23 10:55:35 +0000 | <jaror> | Yeah, I appreciate the feedback |
| 2026-05-23 10:55:13 +0000 | <jaror> | build with ghc, perhaps "compile if not cached" is a better description |
| 2026-05-23 10:55:11 +0000 | <[exa]> | (btw apologies for a bit of reviewer mood here ^ :D it's good, there's just always so many tiny things to clarify) |
| 2026-05-23 10:54:36 +0000 | <[exa]> | "much faster to build from scratch" -- you mean rewrite by hand, or build with ghc? |
| 2026-05-23 10:54:19 +0000 | <jaror> | 2+n should be exact |
| 2026-05-23 10:53:49 +0000 | <[exa]> | also would be great if you could provide exact numbers on overhead (there's like 2+n words estimate written down now, would be great to have exact numbers in hand together with what actual `vector` overhead looks like) |
| 2026-05-23 10:52:55 +0000 | <jaror> | s/a lot of/a lot on/ |
| 2026-05-23 10:52:36 +0000 | <jaror> | vector relies a lot of GHC's optimizations in addition to just the primops they use |
| 2026-05-23 10:52:07 +0000 | <[exa]> | anyway the package looks Ok to me, I'd recommend switching to completely 3rd-person narrative in the readme ("theirs" and "ours" vs "vector" and "vector-simple") |
| 2026-05-23 10:51:59 +0000 | <jaror> | Yes I think it would be easier to adapt to other compilers |
| 2026-05-23 10:51:04 +0000 | <[exa]> | I mean, not directly (you depend on GHC :D ) but would it be easier to implement the necessary compiler tooling for this in a hypothetical new compiler or so? |
| 2026-05-23 10:51:04 +0000 | <jaror> | vector-simple does use GHC's primops extensively |
| 2026-05-23 10:50:27 +0000 | <jaror> | I'm not sure what portability problems there are with vector |
| 2026-05-23 10:50:08 +0000 | <[exa]> | jaror: does the vector-simple have any portability implications/improvements? |
| 2026-05-23 10:50:04 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 270 seconds) |
| 2026-05-23 10:44:59 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-05-23 10:38:51 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-05-23 10:33:37 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |