Newest at the top
| 2026-04-09 19:29:13 +0000 | ChanServ | +v haskellbridge |
| 2026-04-09 19:29:13 +0000 | haskellbridge | (~hackager@96.28.224.214) hackager |
| 2026-04-09 19:28:41 +0000 | <EvanR> | but yeah I could see how jensen's device exploits basically lazy evaluation with side effects? |
| 2026-04-09 19:27:31 +0000 | <EvanR> | sometimes I think that 3 different names might be 3 different things, especially since algol predates GHC by a minute |
| 2026-04-09 19:26:59 +0000 | <tomsmeding> | but "call by name" is intended to be the semantics encompassing all operational behaviours that are semantically equivalent to that one, including call-by-need as GHC does |
| 2026-04-09 19:26:51 +0000 | uli-fem | (~uli-fem@115.128.112.118) (Ping timeout: 255 seconds) |
| 2026-04-09 19:26:30 +0000 | <tomsmeding> | which is incredibly pointless as an actual operational implementation |
| 2026-04-09 19:26:17 +0000 | <tomsmeding> | the typical operational presentation I've seen of "call by name" is "`(\x -> e1) e2` reduces to `e1[e2/x]`", i.e. function application is just inlining of the argument _term_ into the function body |
| 2026-04-09 19:25:24 +0000 | <tomsmeding> | I think "call by name" means "lazy evaluation" |
| 2026-04-09 19:23:03 +0000 | <EvanR> | https://en.wikipedia.org/wiki/Jensen's_device |
| 2026-04-09 19:22:39 +0000 | haskellbridge | (~hackager@96.28.224.214) (Read error: Connection reset by peer) |
| 2026-04-09 19:22:39 +0000 | <EvanR> | going by this gem https://en.wikipedia.org/wiki/Jensen%27s_device |
| 2026-04-09 19:22:33 +0000 | uli-fem | (~uli-fem@115.128.112.118) |
| 2026-04-09 19:20:46 +0000 | <EvanR> | call by name on the other hand seems to step outside the subject of evaluation |
| 2026-04-09 19:20:40 +0000 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
| 2026-04-09 19:19:10 +0000 | mulk | (~mulk@pd95147f8.dip0.t-ipconnect.de) mulk |
| 2026-04-09 19:17:50 +0000 | <tomsmeding> | so I'd say still call by value, just with some syntax for passing a non-null pointer |
| 2026-04-09 19:17:26 +0000 | <tomsmeding> | but still eager evaluation |
| 2026-04-09 19:17:19 +0000 | <tomsmeding> | C++ has references which get you pass-by-reference |
| 2026-04-09 19:17:05 +0000 | <tomsmeding> | C is definitely call by value |
| 2026-04-09 19:16:43 +0000 | <EvanR> | C and Java both being presented as call by value only, and not just call by value sometimes |
| 2026-04-09 19:16:42 +0000 | <monochrom> | Sometimes I say "pass by reference, pass by value" when it's only about cloning the argument vs passing an address. |
| 2026-04-09 19:16:41 +0000 | <tomsmeding> | those things mean the same to me, in any case |
| 2026-04-09 19:16:13 +0000 | <EvanR> | that might explain a lot of confusing expositions I've seen |
| 2026-04-09 19:15:25 +0000 | <EvanR> | you claim call by value is synonymous with eager evaluation |
| 2026-04-09 19:14:53 +0000 | <tomsmeding> | call by value is |
| 2026-04-09 19:14:53 +0000 | <monochrom> | call by value and call by name are. |
| 2026-04-09 19:14:33 +0000 | <EvanR> | are any of these evaluation strategies other than call by need |
| 2026-04-09 19:13:46 +0000 | PaulMartensen | (15a119e437@2001:bc8:1210:2cd8::3bc) (Remote host closed the connection) |
| 2026-04-09 19:13:42 +0000 | acarrico | (~acarrico@2606:1440:605:2500:48b4:afd0:aa39:9b2f) |
| 2026-04-09 19:13:29 +0000 | <tomsmeding> | (I also still have to properly read about CBPV) |
| 2026-04-09 19:13:17 +0000 | <tomsmeding> | isn't CBPV not really an evaluation strategy but more of an IR design |
| 2026-04-09 19:09:00 +0000 | <monochrom> | Yeah the newest one is push-value. I still have to read about it. |
| 2026-04-09 19:08:24 +0000 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) DetourNetworkUK |
| 2026-04-09 19:08:17 +0000 | <EvanR> | call by value, call by reference, call by name, call by need, call by push-value (??) |
| 2026-04-09 19:07:31 +0000 | PaulMartensen | (15a119e437@2001:bc8:1210:2cd8::3bc) |
| 2026-04-09 19:07:12 +0000 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) (Read error: Connection reset by peer) |
| 2026-04-09 19:06:55 +0000 | uli-fem | (~uli-fem@115.128.112.118) (Ping timeout: 264 seconds) |
| 2026-04-09 19:06:40 +0000 | Guest62 | (~Guest62@p200300ca8f313400f8e75d167df70e33.dip0.t-ipconnect.de) (Quit: Client closed) |
| 2026-04-09 19:06:01 +0000 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2026-04-09 19:05:48 +0000 | <monochrom> | Source: https://youtu.be/SVYBJlCmRxE?si=xnWBiK-4i8tNUkbC (Computerphile channel) |
| 2026-04-09 19:02:29 +0000 | PaulMartensen | (15a119e437@2001:bc8:1210:2cd8::3bc) (Ping timeout: 244 seconds) |
| 2026-04-09 19:02:23 +0000 | uli-fem | (~uli-fem@115.128.112.118) |
| 2026-04-09 18:58:13 +0000 | PaulMartensen | (15a119e437@2001:bc8:1210:2cd8::3bc) |
| 2026-04-09 18:56:28 +0000 | Typosit | (b41a81e702@2001:bc8:1210:2cd8::494) (Remote host closed the connection) |
| 2026-04-09 18:53:53 +0000 | Typosit | (b41a81e702@2001:bc8:1210:2cd8::494) |
| 2026-04-09 18:53:40 +0000 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2026-04-09 18:53:33 +0000 | uli-fem | (~uli-fem@115.128.112.118) (Ping timeout: 255 seconds) |
| 2026-04-09 18:53:30 +0000 | PaulMartensen | (15a119e437@2001:bc8:1210:2cd8::3bc) (Ping timeout: 268 seconds) |
| 2026-04-09 18:52:53 +0000 | <tomsmeding> | lol |