Home liberachat/#haskell: Logs Calendar

Logs: liberachat/#haskell

←Prev  Next→ 1,803,413 events total
2025-10-19 17:58:22 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2025-10-19 18:04:40 infinity0 joins (~infinity0@pwned.gg)
2025-10-19 18:09:21 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-10-19 18:11:29 × bggd quits (~bgg@2a01:e0a:819:1510:71a9:d225:b66f:12bd) (Remote host closed the connection)
2025-10-19 18:14:35 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-19 18:18:21 × SlackCoder quits (~SlackCode@64-94-63-8.ip.weststar.net.ky) (Ping timeout: 250 seconds)
2025-10-19 18:18:29 wbrawner joins (~wbrawner@static.56.224.132.142.clients.your-server.de)
2025-10-19 18:25:03 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-10-19 18:28:56 × wootehfoot quits (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer)
2025-10-19 18:29:52 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2025-10-19 18:30:42 wootehfoot joins (~wootehfoo@user/wootehfoot)
2025-10-19 18:32:19 Haskeller0x00 joins (~Haskeller@38.49.92.193)
2025-10-19 18:33:39 Haskeller0x00 parts (~Haskeller@38.49.92.193) ()
2025-10-19 18:33:39 Haskeller0x00 joins (~Haskeller@38.49.92.193)
2025-10-19 18:35:55 <Haskeller0x00> Hey y'all! I heard this was the place to go if one needs help with haskell?
2025-10-19 18:38:21 <Rembane> Haskeller0x00: Hello! This is true!
2025-10-19 18:39:53 <Haskeller0x00> Uh.. I need some help with my capstone project.
2025-10-19 18:40:29 <Haskeller0x00> some background... I'm trying to implement the RGN monad discussed here: https://www.cs.cornell.edu/people/fluet/research/rgn-monad/JFP06/jfp06.pdf and I have basically hit a roadblock.
2025-10-19 18:40:52 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-10-19 18:41:23 ss4 joins (~wootehfoo@user/wootehfoot)
2025-10-19 18:41:41 <Haskeller0x00> I don't think I have enough haskell experience to implement it from scratch (i'm assuming I'll have to hack the compiler to do that) so I'm instead implementing this as a wrapper around ST.
2025-10-19 18:42:08 target_i joins (~target_i@user/target-i/x-6023099)
2025-10-19 18:42:37 × wootehfoot quits (~wootehfoo@user/wootehfoot) (Ping timeout: 250 seconds)
2025-10-19 18:43:46 <Haskeller0x00> I have so far been able to define the basic functions, but haskell does not like it when I try to wrap runST
2025-10-19 18:46:56 × trickard_ quits (~trickard@cpe-57-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-10-19 18:47:18 trickard_ joins (~trickard@cpe-57-98-47-163.wireline.com.au)
2025-10-19 18:47:22 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2025-10-19 18:49:02 <Haskeller0x00> Uh... can anyone help me with understanding what I'm doing wrong here?
2025-10-19 18:50:48 <geekosaur> wrapping runST isn't generally a good idea, because if you wrap individual functions you'll find you can't carry anything between invocations of runST (by design)
2025-10-19 18:51:05 × trickard_ quits (~trickard@cpe-57-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-10-19 18:52:15 <geekosaur> right at the bottom of page 3 of the paper you linked, it tells you why runST won't work
2025-10-19 18:53:17 <Haskeller0x00> Uh, even if I were to define RGN as newtype RGN s r a = RGN (ST s a)?
2025-10-19 18:53:52 <Haskeller0x00> Also, if that is not going to work, then how would I go about implementing this?
2025-10-19 18:54:42 wootehfoot joins (~wootehfoo@user/wootehfoot)
2025-10-19 18:55:57 <geekosaur> see section 2 of the paper, they go into detail why encoding the RGN monad via ST won't work
2025-10-19 18:56:07 × ss4 quits (~wootehfoo@user/wootehfoot) (Ping timeout: 246 seconds)
2025-10-19 18:56:25 <geekosaur> (I suspect you took it as saying how to encode RGN via ST, but in fact it does so and then demonstrates why the result doesn't work)
2025-10-19 18:57:22 <Haskeller0x00> Yes, I saw that but I thought that was at least a good starting point to understand what I need to do to encode this.
2025-10-19 18:57:32 <geekosaur> "Does this suffice to encode region-based languages, where runRGN corresponds to letregion? In short, it does not."
2025-10-19 18:57:56 trickard_ joins (~trickard@cpe-57-98-47-163.wireline.com.au)
2025-10-19 18:58:13 <geekosaur> it's a starting point but it's one that demonstrates that soemthing else is needed; that something else not only modifies the compiler, it modifies System F (the type system)
2025-10-19 18:58:53 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-10-19 18:59:08 <Haskeller0x00> hmm... because when my advisor emailed one of the authors of the paper, their response was this: "There wasn't ever an implementation of RGN. You could certainly write RGN (with all the types) as a wrapper around ST; it would essentially just treat the region parameter as phantom. The meaningful implementation would really all be in terms of the
2025-10-19 18:59:09 <Haskeller0x00> memory management, but, AFAIK, even the ST monad doesn't actually eagerly delete STVar's at the end of runST; they are just "normal" heap allocated objects that will get garbage collected when unreachable. Although it seems as though they would necessarily be unreachable at the end of runST, it's a little more complicated with lazy evaluation,
2025-10-19 18:59:09 <Haskeller0x00> because the ST computation may still be "running" as the runST result is lazily evaluated."
2025-10-19 18:59:23 <geekosaur> note that runST and company do not require modifications to the type system! they just make everything polymorphic in an untouchable rank-2 value, which therefore can't escape runST
2025-10-19 18:59:57 <Haskeller0x00> yup, it took me a couple hours, but. I understood how the "s" works.
2025-10-19 19:00:02 × caconym7478798 quits (~caconym@user/caconym) (Quit: bye)
2025-10-19 19:00:43 caconym7478798 joins (~caconym@user/caconym)
2025-10-19 19:01:27 <Haskeller0x00> He (the author) explained that what he meant was regions will live within the same state meaning state won't itself be nested.
2025-10-19 19:02:09 × morj quits (~morj@user/morj) (Quit: Konversation terminated!)
2025-10-19 19:04:10 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-19 19:04:37 <geekosaur> a few other things: (1) even with eager evaluation, GC of values from runST won't necessarily happen immediately; only reference-counting GC implementations do that. so even strict values hang around (which regularly bites people relying on GC to free e.g. Handles and thereby close their associated files)
2025-10-19 19:05:30 <geekosaur> (2) I'm not sure how that statement by one of the authors squares with the assertion in section 1 of the paper that ST isn't sufficient
2025-10-19 19:05:51 <Haskeller0x00> yup, I think that's what he meant with the last sentence in his response.
2025-10-19 19:06:22 <Haskeller0x00> So what he essentially explained was, if I were to have each region as a separate state, I'd be in trouble.
2025-10-19 19:06:49 <Haskeller0x00> but, that does not mean I can have different regions within the same state.
2025-10-19 19:06:54 <Haskeller0x00> *cannot
2025-10-19 19:07:21 <Haskeller0x00> I think that's what he meant by "phantom region parameter".
2025-10-19 19:08:27 <Haskeller0x00> What my understanding has been so far about his response is, the "region" will only be defined in the type system and will not have an actual memory definition.
2025-10-19 19:12:31 × inline quits (~inline@2a02:8071:57a1:1260:504d:3076:81f0:8f9d) (Ping timeout: 250 seconds)
2025-10-19 19:13:12 peterbecich joins (~Thunderbi@172.222.148.214)
2025-10-19 19:13:40 × wootehfoot quits (~wootehfoo@user/wootehfoot) (Quit: Leaving)
2025-10-19 19:14:41 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-10-19 19:15:22 inline joins (~inline@ip-178-202-059-161.um47.pools.vodafone-ip.de)
2025-10-19 19:17:46 × flipflops quits (~cmo@2604:3d09:207f:8000::d1dc) (Ping timeout: 248 seconds)
2025-10-19 19:18:08 <geekosaur> that part is correct, yes, as the "s" in "ST s a" is (effectively) a phantom tag with no data associated
2025-10-19 19:18:18 × jreicher quits (~user@user/jreicher) (Ping timeout: 248 seconds)
2025-10-19 19:18:31 × karenw quits (~karenw@user/karenw) (Ping timeout: 246 seconds)
2025-10-19 19:18:50 jreicher joins (~user@user/jreicher)
2025-10-19 19:19:00 <Haskeller0x00> So, we can do the same for region, no? It can all be essentially just within the same "s"?
2025-10-19 19:19:34 <geekosaur> but "n a region-based language, it is critical to allocate locations in and read locations from an outer region while in the scope of an inner region. For example, an essential idiom in region-based languages is to enter a letregion in which temporary data is allocated, while reading input from and allocating output in an outer region; upon leaving the letregion, the temporary data is reclaimed, but the input and output data are still
2025-10-19 19:19:34 <geekosaur> available."
2025-10-19 19:19:45 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-10-19 19:20:29 <Haskeller0x00> Also, if we read further, they explain blockST and liftST (or at least RGN equivalents of these 2) which have their own little problems, the primary being that it'll only allow chaining in a certain sequence.
2025-10-19 19:20:39 scula joins (~scula@user/scula)
2025-10-19 19:20:43 <geekosaur> (there is no way to, using ST as RGN, give an inner runST the same "s" as an outer one)
2025-10-19 19:21:12 <Haskeller0x00> but there is not "inner" runSt.
2025-10-19 19:21:35 <Haskeller0x00> It is just one single runST. what is "inner" is region. That's what got me lol
2025-10-19 19:21:55 × qqe quits (~qqq@185.54.23.200) (Quit: Lost terminal)
2025-10-19 19:22:28 <geekosaur> let me rephrase that: the whole point of ST being that you can't pass "s" around, you cant have access to both an inner an an outer "s" at the same time
2025-10-19 19:22:50 <geekosaur> the inner "letregion" would be replaced by an inner runST
2025-10-19 19:22:58 <Haskeller0x00> oh?
2025-10-19 19:23:02 <geekosaur> if you din't do that, you can't have nested regions/resources
2025-10-19 19:23:09 <Haskeller0x00> see now that's the part I'm confused about.
2025-10-19 19:23:20 <Haskeller0x00> I understand how the 's' would not be shareable
2025-10-19 19:23:25 <geekosaur> but the paper asserts that doing that is critical to region-based allocation
2025-10-19 19:24:07 × jreicher quits (~user@user/jreicher) (Ping timeout: 246 seconds)
2025-10-19 19:24:09 × inline quits (~inline@ip-178-202-059-161.um47.pools.vodafone-ip.de) (Ping timeout: 252 seconds)
2025-10-19 19:24:16 inline_ joins (~inline@2a02:8071:57a1:1260:d6a:132:a003:3008)
2025-10-19 19:24:19 <geekosaur> you might be able to say "well, just use one bug region and put up with stuff remaining allocated beyond its lifetime", but you'll probably have to redo most f the paper to support that usage instead of the one they're using that assumes nested regions are possible
2025-10-19 19:24:30 <geekosaur> *big region
2025-10-19 19:24:39 tzh joins (~tzh@c-76-115-131-146.hsd1.or.comcast.net)
2025-10-19 19:24:43 <Haskeller0x00> I know :( ... that's why I'm confused about the author's response :(
2025-10-19 19:25:55 × wbrawner quits (~wbrawner@static.56.224.132.142.clients.your-server.de) (Ping timeout: 265 seconds)
2025-10-19 19:25:59 <geekosaur> also I just reached the part of the paper talking blockST/importST/liftST… and why they aren't sufficient either
2025-10-19 19:26:10 wbrawner joins (~wbrawner@static.56.224.132.142.clients.your-server.de)
2025-10-19 19:26:22 × weary-traveler quits (~user@user/user363627) (Remote host closed the connection)
2025-10-19 19:26:23 <geekosaur> so yeh, I'm also confused by that response, as I said earlier. it directly contradicts the paper
2025-10-19 19:26:30 <geekosaur> in at least two places

All times are in UTC.