| 2025-07-03 00:02:47 +0200 | Xe | (~Xe@perl/impostor/xe) Xe |
| 2025-07-03 00:03:16 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 00:03:32 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 00:03:40 +0200 | wbooze | (~inline@ip-005-146-196-116.um05.pools.vodafone-ip.de) (Ping timeout: 252 seconds) |
| 2025-07-03 00:06:18 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Read error: Connection reset by peer) |
| 2025-07-03 00:07:37 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-07-03 00:08:36 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-07-03 00:15:20 +0200 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 00:15:40 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 276 seconds) |
| 2025-07-03 00:15:45 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 276 seconds) |
| 2025-07-03 00:19:18 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 00:19:38 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 00:20:57 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 276 seconds) |
| 2025-07-03 00:21:52 +0200 | j1n37- | (~j1n37@user/j1n37) (Ping timeout: 268 seconds) |
| 2025-07-03 00:22:19 +0200 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2025-07-03 00:22:34 +0200 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2025-07-03 00:24:17 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-07-03 00:26:47 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 00:29:16 +0200 | Nosrep | (~jimothy@user/nosrep) (Remote host closed the connection) |
| 2025-07-03 00:30:07 +0200 | Nosrep | (~jimothy@user/nosrep) Nosrep |
| 2025-07-03 00:31:08 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 00:32:47 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 00:35:05 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 00:35:32 +0200 | glguy | (glguy@libera/staff/glguy) (Remote host closed the connection) |
| 2025-07-03 00:35:40 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 00:37:01 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-07-03 00:39:49 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-07-03 00:41:41 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 00:41:53 +0200 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 248 seconds) |
| 2025-07-03 00:42:24 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2025-07-03 00:45:30 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 00:46:26 +0200 | sadkeyvanfar | (~sadkeyvan@user/sadkeyvanfar) sadkeyvanfar |
| 2025-07-03 00:48:54 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 00:50:51 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 00:52:13 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 00:53:18 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 00:56:10 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 00:57:34 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-07-03 00:58:46 +0200 | sadkeyvanfar | (~sadkeyvan@user/sadkeyvanfar) (Quit: Client closed) |
| 2025-07-03 01:00:53 +0200 | r-sta | (~r-sta@cpc142694-benw13-2-0-cust901.16-2.cable.virginm.net) |
| 2025-07-03 01:01:01 +0200 | <r-sta> | ok i have a question |
| 2025-07-03 01:01:26 +0200 | <r-sta> | so my prof was explaining to me how a graphically turing complete language works |
| 2025-07-03 01:01:46 +0200 | <r-sta> | but i was wondering if it has to be graphically complete in the sense of a graph or just a list |
| 2025-07-03 01:02:06 +0200 | <r-sta> | like, if the graph leafs have pointers to elsewhere in the graph, isnt that just the same as if it were a list? |
| 2025-07-03 01:03:08 +0200 | <r-sta> | like, cant you just have a list where the values can be either `a' or `Cursor [] a' |
| 2025-07-03 01:03:24 +0200 | <EvanR> | there are variations on defining a turing machine, then there's many ways to implement them which will be equivalent |
| 2025-07-03 01:03:36 +0200 | <r-sta> | hmm? |
| 2025-07-03 01:03:44 +0200 | <EvanR> | what's your turing machine |
| 2025-07-03 01:03:49 +0200 | <r-sta> | no, i mean like, isnt it the same to have the list instead of the graph? |
| 2025-07-03 01:04:02 +0200 | <r-sta> | EvanR, its not turing complete, its grphically turing complete |
| 2025-07-03 01:04:16 +0200 | <EvanR> | graphically turing complete |
| 2025-07-03 01:04:17 +0200 | <r-sta> | my question is if it needs the graph or if the list is the same |
| 2025-07-03 01:04:28 +0200 | <r-sta> | like, if I dont understand the difference |
| 2025-07-03 01:04:43 +0200 | <EvanR> | any finite graph can be described by an adjacency list |
| 2025-07-03 01:05:05 +0200 | <r-sta> | i think thats the point where i get confused. like if you can just "linearze" the graph somehow |
| 2025-07-03 01:05:27 +0200 | <EvanR> | sure |
| 2025-07-03 01:05:42 +0200 | <EvanR> | you number the nodes in the graph and use that in the list |
| 2025-07-03 01:05:48 +0200 | <r-sta> | but then, im not sure if thats the same definition as just regular turing complete, not graphically turing complete |
| 2025-07-03 01:06:20 +0200 | <EvanR> | well what's graphically turing complete |
| 2025-07-03 01:06:29 +0200 | <r-sta> | EvanR: i dont think it needs the adjacency matrix at type level, it just has Either values or itself at different positions |
| 2025-07-03 01:07:01 +0200 | potatoe | (~potatoe@157-131-120-242.fiber.dynamic.sonic.net) |
| 2025-07-03 01:07:04 +0200 | <r-sta> | iiuc the adjacency data is equivalent to the structure directing index in the deconstructed version |
| 2025-07-03 01:07:25 +0200 | <r-sta> | like, pattern matching on the subsequent constructors |
| 2025-07-03 01:07:47 +0200 | <r-sta> | with (Int,Int) for the tree branch depth and hight |
| 2025-07-03 01:08:24 +0200 | <r-sta> | [(Int,Int),a)] instead of whatever the type would be with the adjacency matrix at type level |
| 2025-07-03 01:08:38 +0200 | <r-sta> | (iirc if you exponentiate it it checks for cycles) |
| 2025-07-03 01:08:50 +0200 | <r-sta> | (so you get the graph cuts) |
| 2025-07-03 01:08:53 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 01:09:02 +0200 | <EvanR> | so what are you asking |
| 2025-07-03 01:09:28 +0200 | <r-sta> | basically i think it means by this graphically turing complete thing that the list is just the same as the graph |
| 2025-07-03 01:09:52 +0200 | <r-sta> | so i just have like, Graph a = Zipper (Either a (Graph a)) |
| 2025-07-03 01:10:20 +0200 | <EvanR> | zipper is equivalent to a list |
| 2025-07-03 01:10:34 +0200 | <r-sta> | and it ends up looking weird because there are no branches but the comonadic convolution cursor somehow captures this |
| 2025-07-03 01:10:55 +0200 | <EvanR> | times the cursor |
| 2025-07-03 01:11:00 +0200 | <r-sta> | EvanR: sure, but now its also weirdly equivalent to a graph somehow |
| 2025-07-03 01:11:28 +0200 | <EvanR> | a list newtype which can contain itself |
| 2025-07-03 01:11:31 +0200 | <r-sta> | seems like a kind of turing tape version of the graphical turing completeness |
| 2025-07-03 01:11:39 +0200 | <EvanR> | might even be a graph at runtime |
| 2025-07-03 01:12:03 +0200 | <EvanR> | if the knots are tied |
| 2025-07-03 01:12:21 +0200 | <r-sta> | like, normally it would be like Graph a = Tree (Either a (Graph a)) where Tree a = Either a [Tree a] |
| 2025-07-03 01:12:31 +0200 | <r-sta> | and you can see the branches |
| 2025-07-03 01:12:36 +0200 | <r-sta> | they just sort of collapse!? |
| 2025-07-03 01:13:02 +0200 | <r-sta> | idk if there is like a monad agnosticism theorem or something at the heart of it |
| 2025-07-03 01:13:03 +0200 | <EvanR> | to show two types are isomorphic just write the from and to functions |
| 2025-07-03 01:13:10 +0200 | <EvanR> | and show they compose into get id |
| 2025-07-03 01:13:39 +0200 | <r-sta> | derp, sorry, that definition should have a bunch of zippers sorry |
| 2025-07-03 01:14:00 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-07-03 01:14:07 +0200 | <r-sta> | one for the list of branches, and then, like, one for the depth zipping vertically down the tree |
| 2025-07-03 01:14:29 +0200 | ft | (~ft@p4fc2a518.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2025-07-03 01:14:36 +0200 | <r-sta> | so at the leafs its either a value or the "graph pointer" (this horizontal and vertical zipper) |
| 2025-07-03 01:15:02 +0200 | <r-sta> | i guess they are not strictly isomorphic since in the lists only version its like... you cant point to a branch point? |
| 2025-07-03 01:15:44 +0200 | Square2 | (~Square@user/square) (Quit: Leaving) |
| 2025-07-03 01:16:02 +0200 | Square | (~Square@user/square) (Remote host closed the connection) |
| 2025-07-03 01:16:15 +0200 | <r-sta> | there is a version of a deconstructed geti zipper where you have GraphZipper a = ([((Int,Int),a)],(Graph a)) |
| 2025-07-03 01:16:22 +0200 | Square | (~Square@user/square) Square |
| 2025-07-03 01:16:35 +0200 | <r-sta> | i guess that might be equivalent, because then you only ever point to the leaf values |
| 2025-07-03 01:17:11 +0200 | <r-sta> | it just seems weird how the (Int,Int) and the Int seem equivalent |
| 2025-07-03 01:17:23 +0200 | <r-sta> | like, in a list i only need to say where the value is in the list with an Int |
| 2025-07-03 01:17:38 +0200 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-07-03 01:17:56 +0200 | <r-sta> | hmm... i suppose with the GraphZipper above, i would only need some Int number of forward deconstruction opperations |
| 2025-07-03 01:18:04 +0200 | malte | (~malte@mal.tc) (Remote host closed the connection) |
| 2025-07-03 01:18:37 +0200 | <r-sta> | its just weird how its the same if there is [a] in the backward part of the zipper, or [((Int,Int),a)] for the data retained if its a graph |
| 2025-07-03 01:18:42 +0200 | <r-sta> | i dont get how thats redundant |
| 2025-07-03 01:19:04 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 01:19:05 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-07-03 01:19:14 +0200 | <r-sta> | like, maybe the runtime representation is less effecient somehow |
| 2025-07-03 01:19:48 +0200 | <r-sta> | it would have to do more zipper opperations since it cant zipper through one of the upper branches and save itself some thunks |
| 2025-07-03 01:20:27 +0200 | malte | (~malte@mal.tc) malte |
| 2025-07-03 01:20:30 +0200 | <r-sta> | i always wonder if that internal representation is used in the compiler somehow since the programs form a graph monad |
| 2025-07-03 01:20:55 +0200 | <r-sta> | like, is that saving being done under the hood somehow |
| 2025-07-03 01:21:04 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds) |
| 2025-07-03 01:21:05 +0200 | ljdarj1 | ljdarj |
| 2025-07-03 01:21:09 +0200 | <r-sta> | using dereferencing and variable binding in some super awesome way |
| 2025-07-03 01:21:15 +0200 | malte | (~malte@mal.tc) (Remote host closed the connection) |
| 2025-07-03 01:21:57 +0200 | <r-sta> | ( i was always trying to express the top level program monad as a fancy datatype but getting messed up with singletons ) |
| 2025-07-03 01:22:41 +0200 | <r-sta> | ( like, that the program would automatically factor into an overall datatype which could then be algorithmically refactored ) |
| 2025-07-03 01:23:33 +0200 | <r-sta> | yeah, i guess refactoring would be faster on the graph version because of that point about thunks above |
| 2025-07-03 01:23:34 +0200 | <potatoe> | sorry, I'm kind of new, and I'm trying to understand 'let', so I read that it lets us create "local" expressions, but how does that really work? as in, lets say I have this: take 5 $ 0:z in z, is there another way to write this without the 'in'? |
| 2025-07-03 01:23:36 +0200 | <r-sta> | i think i get it |
| 2025-07-03 01:23:49 +0200 | <r-sta> | cheers! |
| 2025-07-03 01:23:52 +0200 | r-sta | (~r-sta@cpc142694-benw13-2-0-cust901.16-2.cable.virginm.net) (Quit: Client closed) |
| 2025-07-03 01:24:01 +0200 | EvanR | blinks |
| 2025-07-03 01:24:02 +0200 | malte | (~malte@mal.tc) malte |
| 2025-07-03 01:24:23 +0200 | <ski> | potatoe : there is no `let' there |
| 2025-07-03 01:24:39 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 01:24:52 +0200 | <potatoe> | oops sorry, take 5 $ let z = 0:z in z |
| 2025-07-03 01:25:16 +0200 | <EvanR> | for this to work, haskell has to use lazy evaluation |
| 2025-07-03 01:25:21 +0200 | <ski> | you could say `take 5 (fix (0 :))' |
| 2025-07-03 01:25:33 +0200 | <ski> | fix f = x |
| 2025-07-03 01:25:36 +0200 | <ski> | where |
| 2025-07-03 01:25:37 +0200 | <potatoe> | I ended up trying to understand fix first but then realized I didn't properly understand 'let' |
| 2025-07-03 01:25:39 +0200 | <ski> | x = f x |
| 2025-07-03 01:25:46 +0200 | <EvanR> | the infinite list z doesn't get fully constructed before evaluating the next step |
| 2025-07-03 01:25:55 +0200 | <potatoe> | I mean, I was trying to understand fix* and ended up with this question |
| 2025-07-03 01:26:22 +0200 | <EvanR> | semantically you can think of z as 0:0:0:0:... an infinite number of zeros |
| 2025-07-03 01:26:23 +0200 | <ski> | `let' in your case builds a cyclic list, whose tail points back to the same cons cell |
| 2025-07-03 01:26:27 +0200 | <EvanR> | then you can just take 5 of them |
| 2025-07-03 01:27:12 +0200 | <ski> | it's also possible to define `fix' non-recursively, using self-application |
| 2025-07-03 01:28:03 +0200 | <ski> | pretty sure that would not give a cyclic list here, though, rather expanding to new cons cells, as many as you need |
| 2025-07-03 01:28:17 +0200 | <potatoe> | right, so if the expression is take 5 $ ... in z, can I think of it as take 5 from z? |
| 2025-07-03 01:28:24 +0200 | <potatoe> | or is that not the right way to think about it |
| 2025-07-03 01:28:30 +0200 | <potatoe> | for the let in z pattern? |
| 2025-07-03 01:29:28 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-07-03 01:29:48 +0200 | <EvanR> | the value of let x = y in z is the value of z evaluated with x defined as y in its environment |
| 2025-07-03 01:29:53 +0200 | <EvanR> | so yes |
| 2025-07-03 01:30:03 +0200 | <ski> | yes, `take 5 (let ... in z)' is the same as `let ... in take 5 z' |
| 2025-07-03 01:30:04 +0200 | <EvanR> | outside this expression there's no x |
| 2025-07-03 01:30:21 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 01:30:23 +0200 | <potatoe> | excellent, thank you |
| 2025-07-03 01:30:36 +0200 | <potatoe> | now im going to try to understand fix, so im going to hang out in here |
| 2025-07-03 01:30:37 +0200 | <EvanR> | consider the evaluation rules for each kind of expression |
| 2025-07-03 01:30:42 +0200 | <EvanR> | there's not that many |
| 2025-07-03 01:31:16 +0200 | <EvanR> | then they can be combined in infinite ways |
| 2025-07-03 01:32:39 +0200 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2025-07-03 01:32:56 +0200 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2025-07-03 01:35:20 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-07-03 01:37:40 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2025-07-03 01:41:14 +0200 | acidjnk | (~acidjnk@p200300d6e70b6621f429b1307fbc5ebd.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2025-07-03 01:41:50 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 01:42:27 +0200 | <potatoe> | EvanR: "value of let x = y in z is the value of z evaluated with x defined as y in its environment" is really helpful, which I suppose also explains why if I do let f = (\x -> 0:x) f in f it wont be lazy but rather force evaluation of the infinite list |
| 2025-07-03 01:43:35 +0200 | <EvanR> | that doesn't look well typed |
| 2025-07-03 01:43:43 +0200 | <EvanR> | which is a problem prior to what it means |
| 2025-07-03 01:43:50 +0200 | <EvanR> | maybe |
| 2025-07-03 01:44:27 +0200 | <EvanR> | wait |
| 2025-07-03 01:44:34 +0200 | <potatoe> | hmm, why do you say so? it works in ghci (which of course does not mean its correct I just want to learn mroe) |
| 2025-07-03 01:44:41 +0200 | <EvanR> | you're right. But no, it's also lazy |
| 2025-07-03 01:44:48 +0200 | <EvanR> | you can test it like this |
| 2025-07-03 01:45:48 +0200 | <c_wraith> | You need to be a bit more precise than "lazy" in this case. |
| 2025-07-03 01:45:56 +0200 | <EvanR> | well just take 5 from that |
| 2025-07-03 01:46:07 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 01:46:26 +0200 | <potatoe> | yep, let f = ... f in take 5 f does take only 5 |
| 2025-07-03 01:46:35 +0200 | <c_wraith> | that's kind of uninteresting, though |
| 2025-07-03 01:46:47 +0200 | <EvanR> | so... the infinite list didn't get fully constructed (freeze up) |
| 2025-07-03 01:46:53 +0200 | <c_wraith> | actually it does |
| 2025-07-03 01:46:55 +0200 | <potatoe> | c_wraith: what do you mean by you need to be more precise? |
| 2025-07-03 01:47:12 +0200 | <c_wraith> | See, the thing about that construction is that it literally creates a circular linked list |
| 2025-07-03 01:47:20 +0200 | <EvanR> | implementation detail |
| 2025-07-03 01:47:32 +0200 | <c_wraith> | This whole thing is about implementation details |
| 2025-07-03 01:47:47 +0200 | <EvanR> | it's not clear what potatoe is interested in, so I guess that's where more precise comes in |
| 2025-07-03 01:47:47 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 01:49:00 +0200 | <potatoe> | well I suppose I'm not really communicating well here but I guess what I was saying is, I understand that what I asked for was an infinite evaluation, and it doesnt mean that its not "lazy" |
| 2025-07-03 01:49:02 +0200 | <c_wraith> | An expression is neither lazy nor non-lazy. It may be evaluated or unevaluated, but "lazy" is a property of functions. |
| 2025-07-03 01:49:18 +0200 | <EvanR> | I don't think you asked for an infinite evaluation |
| 2025-07-03 01:49:32 +0200 | <EvanR> | trying to print out the whole infinite list I guess does |
| 2025-07-03 01:49:47 +0200 | <EvanR> | which is what's ultimately driving the lazy evaluation |
| 2025-07-03 01:50:46 +0200 | <c_wraith> | I suppose it's more accurate to say "lazy" is a property which means that an expression be evaluated or not. |
| 2025-07-03 01:51:05 +0200 | <c_wraith> | Which is different from whether a particular expression *has* been evaluated |
| 2025-07-03 01:51:18 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-07-03 01:51:23 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 01:51:23 +0200 | <EvanR> | evaluated and how much |
| 2025-07-03 01:51:25 +0200 | <c_wraith> | err. means that an expression *can be* evaluated or not |
| 2025-07-03 01:51:28 +0200 | <EvanR> | fully, partially |
| 2025-07-03 01:51:35 +0200 | <c_wraith> | eh. nested laziness. |
| 2025-07-03 01:51:42 +0200 | <c_wraith> | That's not separate. :) |
| 2025-07-03 01:51:49 +0200 | <EvanR> | often we use "evaluated" to mean WHNF |
| 2025-07-03 01:52:17 +0200 | <c_wraith> | indeed. that's what the most primitive use of case does. |
| 2025-07-03 01:52:19 +0200 | <EvanR> | which might leaves lazy stuff unevaluated! |
| 2025-07-03 01:52:21 +0200 | <potatoe> | right, I mean, by typing that into ghci I asked it to print it out, hence evaluate |
| 2025-07-03 01:53:10 +0200 | <EvanR> | compare and constrast, (let z = 0:z in z) `seq` "cool" |
| 2025-07-03 01:53:32 +0200 | <EvanR> | which won't print it out |
| 2025-07-03 01:55:52 +0200 | <c_wraith> | but it's worth pointing out that there are two possible definitions of fix |
| 2025-07-03 01:56:18 +0200 | <c_wraith> | fix f = f (fix f) or fix f = let x = f x in x |
| 2025-07-03 01:56:35 +0200 | <c_wraith> | they have the same denotation |
| 2025-07-03 01:56:51 +0200 | <c_wraith> | But in GHC they have different operational behavior |
| 2025-07-03 01:56:57 +0200 | <c_wraith> | and that's why one is chosen over the other |
| 2025-07-03 01:57:44 +0200 | <c_wraith> | the key difference is operational, so it depends on implementation details |
| 2025-07-03 01:58:19 +0200 | <c_wraith> | And the important detail is that a let expression shares the same thunk between uses |
| 2025-07-03 01:58:50 +0200 | <c_wraith> | uses of the bound variable, that is |
| 2025-07-03 02:00:52 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 02:01:06 +0200 | <ski> | @let newtype Santa a = MkSanta {runSanta :: Santa a -> a} |
| 2025-07-03 02:01:07 +0200 | <lambdabot> | Defined. |
| 2025-07-03 02:01:15 +0200 | <ski> | > let fix f = g `runSanta` g where g = MkSanta (\g -> f (g `runSanta` g)) in take 4 (fix (0 :)) |
| 2025-07-03 02:01:17 +0200 | <lambdabot> | [0,0,0,0] |
| 2025-07-03 02:01:25 +0200 | glguy | (glguy@libera/staff/glguy) glguy |
| 2025-07-03 02:01:53 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 02:02:16 +0200 | <c_wraith> | So when the value recursion in x happens, it refers to the previously-allocated thunk instead of evaluating f again |
| 2025-07-03 02:03:18 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 02:03:26 +0200 | <c_wraith> | So like (fix (0:)) creates a (:) node that points to itself, instead of pointing to a new (fix (0:)) expression |
| 2025-07-03 02:03:51 +0200 | jespada | (~jespada@r179-25-246-58.dialup.adsl.anteldata.net.uy) (Ping timeout: 252 seconds) |
| 2025-07-03 02:05:11 +0200 | <c_wraith> | and yes, this is complicated. Best to sit down and draw some pictures. GHC uses graph reduction as its evaluation mechanism. Drawing pictures actually gives you a decent idea how it works. |
| 2025-07-03 02:06:59 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-07-03 02:08:00 +0200 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2025-07-03 02:08:17 +0200 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2025-07-03 02:15:26 +0200 | rat-with-hat | (~rat-with-@24-113-114-97.wavecable.com) (Ping timeout: 272 seconds) |
| 2025-07-03 02:17:42 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 02:18:21 +0200 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2025-07-03 02:18:37 +0200 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2025-07-03 02:22:41 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-07-03 02:23:41 +0200 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2025-07-03 02:23:57 +0200 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2025-07-03 02:24:53 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 02:28:37 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 02:32:28 +0200 | trickard | (~trickard@cpe-53-98-47-163.wireline.com.au) (Ping timeout: 245 seconds) |
| 2025-07-03 02:33:02 +0200 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) |
| 2025-07-03 02:33:29 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 02:36:11 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Ping timeout: 252 seconds) |
| 2025-07-03 02:37:24 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2025-07-03 02:40:14 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-07-03 02:41:26 +0200 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2025-07-03 02:42:55 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-07-03 02:43:06 +0200 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod |
| 2025-07-03 02:45:38 +0200 | notzmv | (~umar@user/notzmv) notzmv |
| 2025-07-03 02:51:31 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 02:51:40 +0200 | xff0x | (~xff0x@2405:6580:b080:900:d5d3:9c03:a2c:5492) (Ping timeout: 276 seconds) |
| 2025-07-03 02:53:59 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 02:56:18 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 248 seconds) |
| 2025-07-03 02:56:18 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-07-03 02:57:32 +0200 | Square3 | (~Square4@user/square) Square |
| 2025-07-03 03:01:02 +0200 | Square | (~Square@user/square) (Ping timeout: 272 seconds) |
| 2025-07-03 03:01:34 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 03:06:27 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 03:06:54 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 03:08:51 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-07-03 03:10:04 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 03:11:34 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer) |
| 2025-07-03 03:11:44 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-07-03 03:14:42 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-07-03 03:17:18 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 244 seconds) |
| 2025-07-03 03:18:17 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 03:19:11 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2025-07-03 03:22:40 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 03:24:29 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 03:25:35 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 03:27:28 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-07-03 03:28:34 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 03:34:55 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 03:36:42 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 03:37:18 +0200 | mud | (~mud@user/kadoban) (Remote host closed the connection) |
| 2025-07-03 03:37:43 +0200 | mud | (~mud@user/kadoban) kadoban |
| 2025-07-03 03:37:44 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 03:38:27 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 03:39:50 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-07-03 03:40:22 +0200 | trickard_ | trickard |
| 2025-07-03 03:42:25 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 03:43:45 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-07-03 03:46:01 +0200 | notzmv | (~umar@user/notzmv) (Read error: Connection reset by peer) |
| 2025-07-03 03:46:35 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 03:46:52 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 03:50:34 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 03:53:50 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 03:54:00 +0200 | <monochrom> | A good test of laziness in lists is `take 1` for example. |
| 2025-07-03 03:56:57 +0200 | <c_wraith> | if the list has a length > 1 |
| 2025-07-03 03:58:41 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-07-03 03:58:45 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 04:08:09 +0200 | <probie> | > take 1 (42 : reverse [1..]) -- seems lazy to me |
| 2025-07-03 04:08:10 +0200 | <lambdabot> | [42] |
| 2025-07-03 04:08:36 +0200 | <monochrom> | It is lazy to me. |
| 2025-07-03 04:09:41 +0200 | <EvanR> | laziness. You know it when you see it |
| 2025-07-03 04:12:49 +0200 | <probie> | > let lazyishReverse xs = [ys !! n | let ys = reverse xs, n <- zipWith const [0..] xs] in (lazyishReverse [1..5], length (take 42 (lazyishReverse [1..]))) |
| 2025-07-03 04:12:50 +0200 | <lambdabot> | ([5,4,3,2,1],42) |
| 2025-07-03 04:17:28 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 245 seconds) |
| 2025-07-03 04:17:33 +0200 | tabaqui | (~tabaqui@167.71.80.236) (Ping timeout: 276 seconds) |
| 2025-07-03 04:19:35 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-07-03 04:20:28 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 04:20:37 +0200 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 248 seconds) |
| 2025-07-03 04:24:56 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 04:27:10 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 272 seconds) |
| 2025-07-03 04:27:40 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 04:31:04 +0200 | td_ | (~td@i53870938.versanet.de) (Ping timeout: 260 seconds) |
| 2025-07-03 04:32:24 +0200 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 2025-07-03 04:32:30 +0200 | td_ | (~td@i53870926.versanet.de) td_ |
| 2025-07-03 04:32:35 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-07-03 04:36:21 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 04:37:37 +0200 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 276 seconds) |
| 2025-07-03 04:40:37 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 04:42:37 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-07-03 04:43:28 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 04:48:06 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 04:48:21 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-07-03 04:51:34 +0200 | hughjfchen | (~hughjfche@vmi2417424.contaboserver.net) (Quit: WeeChat 4.4.3) |
| 2025-07-03 04:53:22 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 04:55:17 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 248 seconds) |
| 2025-07-03 05:00:03 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 05:00:51 +0200 | kimjetwav | (~user@2607:fea8:25a3:a100:794c:5924:b309:3338) (Read error: Connection reset by peer) |
| 2025-07-03 05:01:22 +0200 | kimjetwav | (~user@2607:fea8:25a3:a100:9a03:8363:4504:2e7) kimjetwav |
| 2025-07-03 05:01:23 +0200 | <c_wraith> | now... find a way to do that that isn't O(n^2) |
| 2025-07-03 05:01:46 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 05:04:01 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 05:04:15 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2025-07-03 05:06:52 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-07-03 05:07:49 +0200 | aforemny_ | (~aforemny@2001:9e8:6cd6:3b00:1625:89f0:f9af:ca56) aforemny |
| 2025-07-03 05:08:20 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 05:09:36 +0200 | aforemny | (~aforemny@i577B12B5.versanet.de) (Ping timeout: 272 seconds) |
| 2025-07-03 05:13:21 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-07-03 05:21:09 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Ping timeout: 244 seconds) |
| 2025-07-03 05:21:25 +0200 | ensyde | (~ensyde@c-73-147-64-74.hsd1.va.comcast.net) ensyde |
| 2025-07-03 05:23:12 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-07-03 05:24:04 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 05:25:07 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2025-07-03 05:26:07 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-07-03 05:29:14 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-07-03 05:31:24 +0200 | Goodbye_Vincent1 | (cyvahl@freakshells.net) Goodbye_Vincent |
| 2025-07-03 05:33:15 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 05:36:42 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
| 2025-07-03 05:37:33 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 05:39:51 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 05:40:07 +0200 | hughjfchen | (~hughjfche@vmi2417424.contaboserver.net) hughjfchen |
| 2025-07-03 05:40:09 +0200 | hughjfchen | (~hughjfche@vmi2417424.contaboserver.net) (Client Quit) |
| 2025-07-03 05:41:28 +0200 | hughjfchen | (~hughjfche@vmi2417424.contaboserver.net) hughjfchen |
| 2025-07-03 05:45:09 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-07-03 05:50:25 +0200 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 05:51:44 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 260 seconds) |
| 2025-07-03 05:54:52 +0200 | j1n37- | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 05:55:38 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 05:57:17 +0200 | <probie> | > let lazyishLinearReverse xs = go xs (reverse xs) where { go [] _ = []; go (_:ys) ~(z:zs) = z: go ys zs } in (lazyishLinearReverse [1..5], length (take 42 (lazyishLinearReverse [0..]))) |
| 2025-07-03 05:57:18 +0200 | <lambdabot> | ([5,4,3,2,1],42) |
| 2025-07-03 05:57:43 +0200 | pavonia | (~user@user/siracusa) siracusa |
| 2025-07-03 05:58:24 +0200 | wbooze | (~inline@ip-005-146-197-240.um05.pools.vodafone-ip.de) Inline |
| 2025-07-03 05:58:26 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 05:58:29 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 06:00:37 +0200 | <c_wraith> | nice |
| 2025-07-03 06:02:51 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-07-03 06:05:14 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 06:05:53 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-07-03 06:05:53 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 06:05:55 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer) |
| 2025-07-03 06:09:33 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-07-03 06:13:42 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 06:18:59 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-07-03 06:24:00 +0200 | hughjfchen | (~hughjfche@vmi2417424.contaboserver.net) (Quit: WeeChat 4.6.3) |
| 2025-07-03 06:25:04 +0200 | hughjfchen | (~hughjfche@vmi2417424.contaboserver.net) hughjfchen |
| 2025-07-03 06:26:39 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 06:28:21 +0200 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod |
| 2025-07-03 06:29:29 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 06:32:07 +0200 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 06:33:11 +0200 | j1n37- | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 06:33:28 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 265 seconds) |
| 2025-07-03 06:34:26 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-07-03 06:36:03 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 06:39:43 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 06:44:38 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 06:45:17 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 06:45:41 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 06:46:54 +0200 | trickard | (~trickard@cpe-53-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-07-03 06:47:08 +0200 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) |
| 2025-07-03 06:48:49 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 06:50:52 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-07-03 06:51:02 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-07-03 06:52:05 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 06:55:05 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 06:57:44 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 07:01:05 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 07:01:06 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 07:06:33 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-07-03 07:08:52 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 07:09:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 07:14:07 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 07:14:22 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-07-03 07:21:36 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 07:21:49 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-07-03 07:23:42 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 07:25:04 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 07:30:01 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-07-03 07:37:32 +0200 | kuribas` | (~user@ptr-17d51ep9vpquipzlo4q.18120a2.ip6.access.telenet.be) kuribas |
| 2025-07-03 07:40:34 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 248 seconds) |
| 2025-07-03 07:40:51 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 07:47:18 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 07:47:39 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-07-03 07:56:29 +0200 | hsw_ | (~hsw@106.104.103.23) hsw |
| 2025-07-03 07:56:49 +0200 | Lears | (~Leary@user/Leary/x-0910699) Leary |
| 2025-07-03 07:56:59 +0200 | tinjamin4 | (~tinjamin@banshee.h4x0r.space) (Read error: Connection reset by peer) |
| 2025-07-03 07:56:59 +0200 | jaror | (~jaror@5070ACC7.static.ziggozakelijk.nl) (Read error: Connection reset by peer) |
| 2025-07-03 07:56:59 +0200 | Leary | (~Leary@user/Leary/x-0910699) (Read error: Connection reset by peer) |
| 2025-07-03 07:57:02 +0200 | hc | (~hc@mail.hce.li) (Read error: Connection reset by peer) |
| 2025-07-03 07:57:05 +0200 | tinjamin4 | (~tinjamin@banshee.h4x0r.space) |
| 2025-07-03 07:57:09 +0200 | jaror | (~jaror@5070ACC7.static.ziggozakelijk.nl) |
| 2025-07-03 07:57:16 +0200 | hc | (~hc@mail.hce.li) hc |
| 2025-07-03 07:57:36 +0200 | a_fantom | (~fantom@33be818f.skybroadband.com) |
| 2025-07-03 07:57:42 +0200 | FANTOM | (~fantom@33be818f.skybroadband.com) (Ping timeout: 244 seconds) |
| 2025-07-03 07:57:42 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 244 seconds) |
| 2025-07-03 07:58:13 +0200 | Natch | (~natch@c-92-34-15-120.bbcust.telenor.se) (Ping timeout: 244 seconds) |
| 2025-07-03 07:58:44 +0200 | hsw | (~hsw@106.104.103.23) (Ping timeout: 244 seconds) |
| 2025-07-03 07:58:47 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) kritzefitz |
| 2025-07-03 07:58:54 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 08:01:49 +0200 | Natch | (~natch@c-92-34-15-120.bbcust.telenor.se) |
| 2025-07-03 08:03:59 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-07-03 08:07:44 +0200 | mud | (~mud@user/kadoban) (Remote host closed the connection) |
| 2025-07-03 08:08:10 +0200 | mud | (~mud@user/kadoban) kadoban |
| 2025-07-03 08:10:16 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 08:15:16 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-07-03 08:19:45 +0200 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 08:20:26 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 244 seconds) |
| 2025-07-03 08:23:45 +0200 | Nosrep | (~jimothy@user/nosrep) (Ping timeout: 248 seconds) |
| 2025-07-03 08:24:46 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer) |
| 2025-07-03 08:25:29 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2025-07-03 08:25:59 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 08:28:21 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-07-03 08:32:34 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-07-03 08:32:53 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-07-03 08:40:47 +0200 | tromp | (~textual@2001:1c00:3487:1b00:9da2:b619:bd71:a1b5) |
| 2025-07-03 08:44:02 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 08:49:23 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-07-03 08:49:24 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2025-07-03 08:50:58 +0200 | rat-with-hat | (~rat-with-@24-113-114-97.wavecable.com) |
| 2025-07-03 08:51:49 +0200 | j1n37- | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 08:52:09 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 08:59:34 +0200 | hsw_ | (~hsw@106.104.103.23) (Quit: Leaving) |
| 2025-07-03 08:59:45 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 08:59:53 +0200 | hsw | (~hsw@106.104.103.23) hsw |
| 2025-07-03 09:00:03 +0200 | caconym7 | (~caconym@user/caconym) (Quit: bye) |
| 2025-07-03 09:00:42 +0200 | caconym7 | (~caconym@user/caconym) caconym |
| 2025-07-03 09:03:17 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 09:04:40 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 09:05:25 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-07-03 09:11:16 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-03 09:14:23 +0200 | wbooze | (~inline@ip-005-146-197-240.um05.pools.vodafone-ip.de) (Ping timeout: 252 seconds) |
| 2025-07-03 09:16:33 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-07-03 09:21:43 +0200 | Square | (~Square@user/square) Square |
| 2025-07-03 09:22:43 +0200 | wbooze | (~inline@ip-005-146-197-196.um05.pools.vodafone-ip.de) Inline |
| 2025-07-03 09:23:40 +0200 | trickard_ | trickard |
| 2025-07-03 09:25:00 +0200 | <[exa]> | is there some good clean way to make an applicative optparser that can guess something like "file format" from suffix of an option or take a hint, and fail still in the parsing phase if it decides that the file format is not known? |
| 2025-07-03 09:25:39 +0200 | Square3 | (~Square4@user/square) (Ping timeout: 276 seconds) |
| 2025-07-03 09:26:22 +0200 | <[exa]> | e.g. as with pandoc: `-o something.md` knows I want markdown, `-o something -t markdown` knows the format to be markdown because I told it so, but just `-o something` should die |
| 2025-07-03 09:26:50 +0200 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-07-03 09:28:56 +0200 | acidjnk | (~acidjnk@p200300d6e70b6621f429b1307fbc5ebd.dip0.t-ipconnect.de) acidjnk |
| 2025-07-03 09:31:03 +0200 | kuribas` | (~user@ptr-17d51ep9vpquipzlo4q.18120a2.ip6.access.telenet.be) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.3)) |
| 2025-07-03 09:31:10 +0200 | shaeto | (~Shaeto@94.25.234.117) |
| 2025-07-03 09:31:34 +0200 | kuribas | (~user@ptr-17d51ep9vpquipzlo4q.18120a2.ip6.access.telenet.be) kuribas |
| 2025-07-03 09:34:24 +0200 | m1dnight | (~m1dnight@d8D861908.access.telenet.be) (Ping timeout: 260 seconds) |
| 2025-07-03 09:39:46 +0200 | Guest54 | (~Guest54@67.218.116.66) |
| 2025-07-03 09:45:23 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 244 seconds) |
| 2025-07-03 09:48:22 +0200 | tromp | (~textual@2001:1c00:3487:1b00:9da2:b619:bd71:a1b5) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-07-03 09:49:50 +0200 | <haskellbridge> | <Axman6> /me another day, another failed attempt to understand python package management and feeling like topping oneself would be an easier option |
| 2025-07-03 09:55:19 +0200 | Guest54 | (~Guest54@67.218.116.66) (Quit: Client closed) |
| 2025-07-03 09:56:19 +0200 | <[exa]> | Axman6: just don't |
| 2025-07-03 09:57:43 +0200 | <[exa]> | the ecosystem is so dragged into all directions (and legacy) and so shaped to just somehow survive everything that has been thrown at it that there's nothing to really understand, just tech debt |
| 2025-07-03 09:58:54 +0200 | <tomsmeding> | [exa]: that sounds like wanting to do control flow in the applicative based on values inside |
| 2025-07-03 09:59:01 +0200 | <tomsmeding> | i.e. the thing that you can't do in an applicative but can do in a monad |
| 2025-07-03 09:59:08 +0200 | <kuribas> | Axman6: Did you try "uv"? |
| 2025-07-03 09:59:15 +0200 | <[exa]> | tomsmeding: yeah trying to dodge precisely that |
| 2025-07-03 09:59:46 +0200 | <tomsmeding> | at some point there's a primitive parser on strings that can do anything, if you could hook in there it could work |
| 2025-07-03 10:00:08 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 10:00:09 +0200 | <kuribas> | I didn't follow the whole discussion, but I often find an applicative wrapped in a monad handy... |
| 2025-07-03 10:00:55 +0200 | <[exa]> | currently I found I can do `option (eitherReader guessSuffix)` and fall back to it from `MyVal <$> option fmt (long "format") <*> strOption (long "input")` |
| 2025-07-03 10:03:02 +0200 | Lears | Leary |
| 2025-07-03 10:03:21 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 276 seconds) |
| 2025-07-03 10:04:52 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 10:05:16 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-07-03 10:06:16 +0200 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-07-03 10:08:25 +0200 | tabaqui | (~tabaqui@167.71.80.236) tabaqui |
| 2025-07-03 10:09:49 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-07-03 10:21:48 +0200 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) (Quit: WeeChat 4.5.1) |
| 2025-07-03 10:22:15 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-07-03 10:23:11 +0200 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) NinjaTrappeur |
| 2025-07-03 10:25:50 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-07-03 10:26:41 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer) |
| 2025-07-03 10:30:24 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-07-03 10:30:50 +0200 | trickard | (~trickard@cpe-53-98-47-163.wireline.com.au) (Remote host closed the connection) |
| 2025-07-03 10:30:52 +0200 | <[exa]> | ok looks like it either doesn't backtrack or failover properly |
| 2025-07-03 10:32:48 +0200 | <[exa]> | of I do (schematically): `(MyVal <$> optionA <*> optionB) <|> optionA_that_guesses_whole_MyVal` and only supply option A, it complains that it's missing option B |
| 2025-07-03 10:33:20 +0200 | <[exa]> | and if I flip the alternatives, it generally ignores the optionB and uses it only if there |
| 2025-07-03 10:33:22 +0200 | <[exa]> | there |
| 2025-07-03 10:33:33 +0200 | <[exa]> | (whoops my keyboard is acting funny) |
| 2025-07-03 10:34:05 +0200 | <[exa]> | ...only if the guessy optionA fails to guess |
| 2025-07-03 10:34:20 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2025-07-03 10:39:26 +0200 | <__monty__> | [exa]: Problem is that the left parser doesn't backtrack, so there's no recovery. Wrapping the left side in `try` should work. |
| 2025-07-03 10:40:03 +0200 | <[exa]> | there's try? |
| 2025-07-03 10:40:38 +0200 | <[exa]> | maybe I fail at finding stuff |
| 2025-07-03 10:40:46 +0200 | euphores | (~SASL_euph@user/euphores) euphores |
| 2025-07-03 10:41:03 +0200 | <__monty__> | @hoogle try |
| 2025-07-03 10:41:03 +0200 | <[exa]> | I think there's none |
| 2025-07-03 10:41:03 +0200 | <lambdabot> | Control.Exception try :: Exception e => IO a -> IO (Either e a) |
| 2025-07-03 10:41:03 +0200 | <lambdabot> | Control.Exception.Base try :: Exception e => IO a -> IO (Either e a) |
| 2025-07-03 10:41:03 +0200 | <lambdabot> | System.Directory.Internal.Prelude try :: Exception e => IO a -> IO (Either e a) |
| 2025-07-03 10:41:11 +0200 | <__monty__> | Well, it's none of those. |
| 2025-07-03 10:41:24 +0200 | <[exa]> | anyway the issue is that the left parser actually fails, but it doesn't even try the option after <|> |
| 2025-07-03 10:42:33 +0200 | <__monty__> | The Megaparsec docs explain, https://hackage.haskell.org/package/megaparsec-9.3.0/docs/Text-Megaparsec.html#v:try |
| 2025-07-03 10:43:11 +0200 | <__monty__> | The left parser doesn't fail to consume any input whatsoever, so the alternative can never be tried. |
| 2025-07-03 10:43:19 +0200 | <tomsmeding> | __monty__: this is optparse-applicative |
| 2025-07-03 10:43:56 +0200 | <tomsmeding> | in a monadic parser this whole issue doesn't arise :) |