Newest at the top
2024-10-06 19:28:52 +0200 | <davean> | Sequence is WAY off vector performance. |
2024-10-06 19:28:49 +0200 | <Inst> | hmmm, you can just newtype vector for dynamic vectors, you don't need any additional information in order to implement a dynamic vector |
2024-10-06 19:28:45 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) (Quit: Konversation terminated!) |
2024-10-06 19:27:45 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
2024-10-06 19:25:55 +0200 | <int-e> | (Even when you consider amortized cost, persistence is a big obstacle to combining arrays and mutation. Okasaki-like tricks will work.) |
2024-10-06 19:25:06 +0200 | <Inst> | Sequence is built on fingertrees |
2024-10-06 19:24:21 +0200 | <int-e> | of course not |
2024-10-06 19:22:10 +0200 | <Inst> | yeah but iirc it's not based on bytearray, right? |
2024-10-06 19:21:59 +0200 | <int-e> | Data.Seq is a thing too |
2024-10-06 19:21:48 +0200 | <Inst> | davean: you can define a bidirectional dynamic vector, amortized O(1) cons |
2024-10-06 19:21:35 +0200 | <davean> | You can sorta get close amortised, but that requires reusing memory |
2024-10-06 19:21:09 +0200 | <Rembane> | Inst: Are you thinking of Data.Vector? |
2024-10-06 19:21:06 +0200 | <davean> | ... you can't have O(1) cons |
2024-10-06 19:20:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
2024-10-06 19:20:43 +0200 | <Inst> | iirc the newbie rule of thumb is "prefer vectors unless you need laziness", but vector doesn't have O(1) cons |
2024-10-06 19:20:24 +0200 | <Inst> | btw, why doesn't Haskell have dynamic vectors? |
2024-10-06 19:19:09 +0200 | <Rembane> | davean: Oh. That sounds way too hard. |
2024-10-06 19:18:57 +0200 | <davean> | Rembane: Some of the best Haskellers I know tries that, and as a team failed. |
2024-10-06 19:18:48 +0200 | <Rembane> | davean: ^^ |
2024-10-06 19:18:23 +0200 | <dolio> | So, like, maybe you could use linear types to design some methodology of using unsafe operations, and very carefully implement something on top of the unsafe operations that provided some kind of typical performance increase. But the linearity stuff is not inherently doing the things that perform better in known ways. |
2024-10-06 19:18:23 +0200 | <davean> | HAVE FUN! |
2024-10-06 19:18:21 +0200 | <davean> | Rembane: Try writing like just a merge step of a merge sort with liner types, consider the edge cases. |
2024-10-06 19:13:48 +0200 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
2024-10-06 19:13:21 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
2024-10-06 19:13:07 +0200 | <dolio> | I haven't looked closely, but the problem seems to be that it wasn't designed to address the usual, known uses of linear types. |
2024-10-06 19:12:49 +0200 | <Rembane> | davean: Got it! |
2024-10-06 19:11:39 +0200 | <davean> | Rembane: broken? No. The source of the issues using it? Yes |
2024-10-06 19:11:09 +0200 | <Rembane> | davean: Do you imply that the theory is broken? Or have I misunderstood you? |
2024-10-06 19:10:45 +0200 | <Rembane> | Are we back in the libraries + language again? |
2024-10-06 19:10:19 +0200 | <davean> | You know ... except libraries can't patch theory |
2024-10-06 19:10:17 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) athan |
2024-10-06 19:09:53 +0200 | <Inst> | they're essentially: "we built stuff into GHc, everything else is the problem of the library makers" |
2024-10-06 19:09:40 +0200 | <Inst> | from what I hear of the linear Haskell people |
2024-10-06 19:08:51 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
2024-10-06 19:08:22 +0200 | <Rembane> | Did it result in any good papers? |
2024-10-06 19:06:12 +0200 | <Inst> | but they'd rather dodge rather than say: 'hi, if you're competent for working on GHC, plz halp" |
2024-10-06 19:05:45 +0200 | <Inst> | like, they're desperate to get it merged, but definitely don't have the resources to develop properly, etc? |
2024-10-06 19:05:26 +0200 | <Inst> | ehhh, could be a cultural issue for where they're coming from? |
2024-10-06 19:05:04 +0200 | tabemann | (~tabemann@2600:1700:7990:24e0:8858:4365:4e70:4256) |
2024-10-06 19:04:51 +0200 | tabemann | (~tabemann@2600:1700:7990:24e0:bc5d:8bdb:179f:73b1) (Remote host closed the connection) |
2024-10-06 19:04:34 +0200 | <davean> | You can for example, admit you don't have an answer yet |
2024-10-06 19:04:20 +0200 | <davean> | No, no, nothing requires refusing to answer a question and claiming you did |
2024-10-06 19:03:46 +0200 | <Inst> | once again, it's that Haskell needs more funding and resources |
2024-10-06 19:03:26 +0200 | <davean> | I was really disapointed in the Linear Haskell stuff, these questions were brought up before merge, they dogged constantly and claimed they answered them while refusing to. Quite sad. |
2024-10-06 19:03:21 +0200 | <Inst> | fundamentalist in fake python: simple haskell advocate who wants to get rid of explicit >>= and >> usage to make the codebase easier to approach |
2024-10-06 19:02:17 +0200 | <Inst> | that's a lot of haskell, no? Begging for someone to submit a pull request on Github |
2024-10-06 19:01:37 +0200 | <davean> | having tried to use it, it doesn't touch the IO domain at all really. Never solved any of the problems required |
2024-10-06 19:01:09 +0200 | <davean> | Inst: ... yah I think you're very wrong. |
2024-10-06 19:00:48 +0200 | <Inst> | for the last task you'd imagine they'd move to linear haskell to precisely control timings |
2024-10-06 19:00:34 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 265 seconds) |