Newest at the top
2025-04-29 17:14:40 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
2025-04-29 17:13:05 +0200 | orcus | (~orcus@mail.brprice.uk) |
2025-04-29 17:12:33 +0200 | dispater | (~dispater@mail.brprice.uk) |
2025-04-29 17:10:44 +0200 | orcus | (~orcus@mail.brprice.uk) (Client Quit) |
2025-04-29 17:10:43 +0200 | dispater | (~dispater@mail.brprice.uk) (Client Quit) |
2025-04-29 17:10:27 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
2025-04-29 17:09:30 +0200 | orcus | (~orcus@mail.brprice.uk) |
2025-04-29 17:09:00 +0200 | dispater | (~dispater@mail.brprice.uk) |
2025-04-29 17:06:00 +0200 | dispater | (~dispater@mail.brprice.uk) (Quit: ZNC 1.8.2 - https://znc.in) |
2025-04-29 17:06:00 +0200 | orcus | (~orcus@mail.brprice.uk) (Quit: ZNC 1.8.2 - https://znc.in) |
2025-04-29 16:58:04 +0200 | Googulator71 | (~Googulato@2a01-036d-0106-4a24-1dc7-297e-fae3-e794.pool6.digikabel.hu) |
2025-04-29 16:57:55 +0200 | yin | (~yin@user/zero) zero |
2025-04-29 16:57:46 +0200 | Googulator71 | (~Googulato@94-21-139-144.pool.digikabel.hu) (Quit: Client closed) |
2025-04-29 16:52:16 +0200 | yin | (~yin@user/zero) (Ping timeout: 252 seconds) |
2025-04-29 16:49:34 +0200 | notdabs | (~Owner@2600:1700:69cf:9000:748c:9883:fc80:2b20) (Client Quit) |
2025-04-29 16:48:56 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
2025-04-29 16:46:31 +0200 | internatetional | (~nate@2001:448a:20a3:c2e5:1ee8:b348:b41a:5570) (Ping timeout: 252 seconds) |
2025-04-29 16:46:27 +0200 | notdabs | (~Owner@2600:1700:69cf:9000:748c:9883:fc80:2b20) |
2025-04-29 16:46:14 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 245 seconds) |
2025-04-29 16:31:40 +0200 | tabaqui | (~tabaqui@167.71.80.236) tabaqui |
2025-04-29 16:16:00 +0200 | jacopovalanzano | (~jacopoval@cpc151911-cove17-2-0-cust105.3-1.cable.virginm.net) (Quit: Client closed) |
2025-04-29 16:14:42 +0200 | Leary | (~Leary@user/Leary/x-0910699) Leary |
2025-04-29 16:13:18 +0200 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
2025-04-29 16:13:12 +0200 | Leary | (~Leary@user/Leary/x-0910699) (Ping timeout: 276 seconds) |
2025-04-29 16:05:21 +0200 | mari-estel | (~mari-este@user/mari-estel) (Remote host closed the connection) |
2025-04-29 15:54:55 +0200 | fp | (~Thunderbi@2001:708:20:1406::1370) (Ping timeout: 276 seconds) |
2025-04-29 15:45:24 +0200 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
2025-04-29 15:40:24 +0200 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 252 seconds) |
2025-04-29 15:33:57 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
2025-04-29 15:33:49 +0200 | ColinRobinson | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
2025-04-29 15:33:18 +0200 | <ski> | but you still don't want to build up more and more context, when doing a long-running loop (e.g. with `IO'), if you can avoid it, and in such cases, reasoning about tail calls can be quite important to prevent space leakage (in the Haskell sense) |
2025-04-29 15:32:01 +0200 | <ski> | a tail-recursive loop, which will always be bulky, not return any part of the result until the whole loop is done |
2025-04-29 15:31:55 +0200 | <ski> | Liamzee : anyway, tail calls and tail recursion is still important in Haskell .. but tends to be a bit less important, due to non-strictness (typically implemented using laziness) making it easier to often describe loops as incremental algorithms, only computing the result piece-by-piece, so that the caller will drive looping over this, demanding more result pieces, for as long as it wants to, as opposed to |
2025-04-29 15:31:36 +0200 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
2025-04-29 15:29:10 +0200 | <ski> | (yes, `case' in Haskell doesn't directly correspond to `case' in Scheme (which is more like a C `switch'), but rather `match', but that doesn't matter too much here, for the comparision) |
2025-04-29 15:28:28 +0200 | <ski> | in Haskell, `C[] ::= [] | C[] E ... E | if C[] then E else E | case C[] of P -> E; ... P -> E | ..' |
2025-04-29 15:27:39 +0200 | <ski> | in Scheme, you have evaluation contexts like `C[] ::= [] | (E ... E C[] E ... E) | (if C[] E E) | (case C[] (P E ... E) ... (P E ... E)) | ..' |
2025-04-29 15:27:27 +0200 | mange | (~user@user/mange) (Quit: Zzz...) |
2025-04-29 15:26:13 +0200 | internatetional_ | (~nate@2001:448a:20a3:c2e5:9930:c729:580e:9aa0) (Ping timeout: 252 seconds) |
2025-04-29 15:25:26 +0200 | internatetional | (~nate@2001:448a:20a3:c2e5:1ee8:b348:b41a:5570) internatetional |
2025-04-29 15:25:07 +0200 | <ski> | in Haskell, it's basically the same, except that the "evaluating procedure call arguments" part is skipped. a call `f x' will not evaluate `x' (but will still evaluate `f' itself, which could cause stack usage) |
2025-04-29 15:24:59 +0200 | internatetional | (~nate@2001:448a:20a3:c2e5:701e:e3ed:2d04:6885) (Ping timeout: 245 seconds) |
2025-04-29 15:24:02 +0200 | <ski> | btw, in Scheme, calling a procedure doesn't push stack, either, but evaluating procedure call arguments (and well as the function expression), and introducing new local variables (e.g. with `let'), or doing branching (like `case',`if',`cond', or e.g. a library pattern-matcher as `match'), does. or, in general, introducing a non-tail context |
2025-04-29 15:21:51 +0200 | internatetional_ | (~nate@2001:448a:20a3:c2e5:9930:c729:580e:9aa0) internatetional |
2025-04-29 15:21:00 +0200 | <ski> | not using stack is not the same as not using call stack |
2025-04-29 15:19:49 +0200 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 260 seconds) |
2025-04-29 15:18:46 +0200 | tromp | (~textual@2001:1c00:3487:1b00:81f6:6a75:5fad:c9b4) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2025-04-29 15:16:49 +0200 | <haskellbridge> | <Liamzee> welp, no shade intended |
2025-04-29 15:16:47 +0200 | <haskellbridge> | <Liamzee> that's interesting, i thought Haskell didn't use stack? |
2025-04-29 15:16:02 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |