Newest at the top
| 2025-09-16 05:04:25 +0200 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2025-09-16 05:04:25 +0200 | arandombit | (~arandombi@2603:7000:4600:ffbe:21ee:ceac:8353:7a15) (Changing host) |
| 2025-09-16 05:04:25 +0200 | arandombit | (~arandombi@2603:7000:4600:ffbe:21ee:ceac:8353:7a15) |
| 2025-09-16 05:04:08 +0200 | <geekosaur> | hypothetically could be done. would really complicate GC, though |
| 2025-09-16 05:03:56 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-09-16 05:03:14 +0200 | <StatisticalIndep> | I just wish I could tell Haskell: to point every pointer to an Int, in e.g. a fixey list of Ints, to a pointer location in a block of mmapped data that contains unboxed ints in exactly the same format as GHC expects them. |
| 2025-09-16 05:01:51 +0200 | <hololeap> | makes sense that Map is a binary tree, given the (Ord k) constraint on most operations |
| 2025-09-16 05:01:15 +0200 | <StatisticalIndep> | Yep. |
| 2025-09-16 05:00:55 +0200 | <geekosaur> | which is another reason you must marshal/unmarshal, because it's asking far too much for other languages to have to figure out how Map is a size-balanced binary tree or Seq is a fingertree, etc. |
| 2025-09-16 04:59:48 +0200 | <StatisticalIndep> | Ah, yes, i remembered something like that! |
| 2025-09-16 04:59:35 +0200 | <geekosaur> | Maps are actually more complex than that: "The implementation of Map is based on size balanced binary trees (or trees of bounded balance)" (from the documentation) |
| 2025-09-16 04:58:50 +0200 | StatisticalIndep | (~Statistic@2a02:3035:666:b7d5:4e00:1517:7b0c:d0aa) |
| 2025-09-16 04:58:38 +0200 | StatisticalIndep | (~Statistic@2a02:3035:666:b7d5:4e00:1517:7b0c:d0aa) (Quit: Client closed) |
| 2025-09-16 04:58:26 +0200 | <StatisticalIndep> | I probably expect a Map to internally be stored as an array of pointers, with pointers to keys and to values being interleaved? Or something a bit smarter with fewer pointers. ;) |
| 2025-09-16 04:56:28 +0200 | <geekosaur> | (if you don't have optimization enabled, even the strict values have them, but optimization unboxes whenever possible) |
| 2025-09-16 04:55:56 +0200 | <geekosaur> | right, and all those pointers introduce places where a value could be computed lazily |
| 2025-09-16 04:55:22 +0200 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 256 seconds) |
| 2025-09-16 04:54:59 +0200 | <geekosaur> | *Data.Map.Map |
| 2025-09-16 04:54:58 +0200 | <StatisticalIndep> | I guess my mindset came from having seen diagrams of how GHC stores data in memory. Like how lists are linked lists of boxed values. Lots more pointers than one would think. |
| 2025-09-16 04:54:39 +0200 | <geekosaur> | they are… until ADTs get involved. (what representation do you expect a Data.Map to have?) |
| 2025-09-16 04:53:58 +0200 | <StatisticalIndep> | OK, true. |
| 2025-09-16 04:53:42 +0200 | <geekosaur> | actually I don't see how "doesn't have type information" is related. it's not like C values do |
| 2025-09-16 04:53:31 +0200 | <StatisticalIndep> | Internally though, the fully evaluated values are of course just normal pointers and words and such, right? Just boxed in boxed boxes that are boxed more than the boss on boxyourboss.com was. ;) |
| 2025-09-16 04:52:47 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-09-16 04:52:09 +0200 | <StatisticalIndep> | And after all, those are all things I came to Haskell for, because I liked them. So now I have to live with it.:D |
| 2025-09-16 04:52:01 +0200 | <geekosaur> | which also requires that everything live in Haskell's heap and non-Haskell code not have access to that heap |
| 2025-09-16 04:51:43 +0200 | <StatisticalIndep> | Yup. |
| 2025-09-16 04:51:38 +0200 | <StatisticalIndep> | geekosaur: That was what I needed to hear btw: Marshalling is needed in _any_ case. Because the values don’t have type info attached to them and it’s not that simple anyway within Haskell. :) |
| 2025-09-16 04:51:37 +0200 | <geekosaur> | not only that, but Haskell's implementation of types allows for laziness in the form of thunks, which wouldn't be meaningful to non-Haskell code (a "value" can be a Haskell function that computes the value when demanded) |
| 2025-09-16 04:50:15 +0200 | <StatisticalIndep> | impossible.) |
| 2025-09-16 04:50:15 +0200 | <StatisticalIndep> | geekosaur: Yes, that’s probably my core pet peeve with how Haskell in implemented. It makes interoperation hard. But I get why it was chosen. The whole point was that all types should be checked at compile time, not at runtime. (Hence also things like dynamic libraries and variants with types that aren’t know at compile time yet, being hard or |
| 2025-09-16 04:48:24 +0200 | <StatisticalIndep> | Interesting: The Storable instances for basic types seem to be implemented inside GHC, and the libraries just use stuff like (writeWordOffAddr# = writeWordOffAddr#). So there is probably no actual marshalling work, and it’s fast and 1:1. |
| 2025-09-16 04:47:21 +0200 | <geekosaur> | re marshaling: requiring STorable doesn't seem like much of an issue, and you would need it anyway because Haskell values aren't designed to be meaningful outside of Haskell's heap |
| 2025-09-16 04:46:53 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-09-16 04:46:31 +0200 | <StatisticalIndep> | jackdk: Thanks a lot! |
| 2025-09-16 04:45:18 +0200 | <StatisticalIndep> | Ah, yes, StateVar was a pretty nice experience, when I used SDL. Comes really close to it, indeed. |
| 2025-09-16 04:45:10 +0200 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2025-09-16 04:45:10 +0200 | arandombit | (~arandombi@2603:7000:4600:ffbe:21ee:ceac:8353:7a15) (Changing host) |
| 2025-09-16 04:45:10 +0200 | arandombit | (~arandombi@2603:7000:4600:ffbe:21ee:ceac:8353:7a15) |
| 2025-09-16 04:43:49 +0200 | <StatisticalIndep> | System.IO.MMap looks pretty good, btw. If only there was no marshalling. |
| 2025-09-16 04:42:48 +0200 | <jackdk> | StatisticalIndep: Well I'd probably look at building something that used the https://hackage.haskell.org/package/StateVar interface, and then back it with either the mmap link from before (remember to use a `bracket` function to ensure that you unmap even if an exception is thrown) or some other file io |
| 2025-09-16 04:40:12 +0200 | <StatisticalIndep> | jackdk: To stop people from always assuming the thing I said I want is not the right solution for the thing I want it for. (The “XY problem” fallacy.) 😁 … (Or in this case, there is no deeper reason. I want to explore writing a library that offers transparently persistent variables. Nothing more.) |
| 2025-09-16 04:38:02 +0200 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 260 seconds) |
| 2025-09-16 04:36:05 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-09-16 04:31:06 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-09-16 04:21:55 +0200 | Alleria | (~Alleria@user/alleria) (Quit: Textual IRC Client: www.textualapp.com) |
| 2025-09-16 04:20:01 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-09-16 04:17:10 +0200 | nschoe | (~nschoe@82-65-202-30.subs.proxad.net) nschoe |
| 2025-09-16 04:16:53 +0200 | nschoe | (~nschoe@2a01:e0a:8e:a190:eb80:e362:f8e1:aa2f) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-09-16 04:16:49 +0200 | <jackdk> | StatisticalIndep: a fine ultimate goal, but do you have a subgoal in-between? |