| 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) |