Newest at the top
| 2026-04-09 19:52:44 +0000 | <acarrico> | I entered the channel in the middle of the conversation. Just thought I'd point out Dolstra's paper since it seemed relevant. But its a great topic for people to think about, in part because it does open up those ideas. Ultimately you realize that you don't want a default strategy, but you kind of need one to avoid going insane with verbosity. |
| 2026-04-09 19:51:14 +0000 | <tomsmeding> | but clearly you have a different meaning in mind, which is related but not quite the same :p |
| 2026-04-09 19:50:55 +0000 | <tomsmeding> | the way I was originally explained call by name is how I just explained it here, which only useful as a semantics, not as an implementation |
| 2026-04-09 19:50:17 +0000 | <tomsmeding> | this conversation exemplifies the original reason why this topic was brought up though: the terms "call by name" / "call by need" / "call by value" etc. mean multiple different things at different levels of abstraction, and different people use different ones |
| 2026-04-09 19:49:28 +0000 | <acarrico> | Guh, that seems like too much magic. |
| 2026-04-09 19:48:20 +0000 | <acarrico> | The strategy is very useful when you want to intern your values anyway for some reason, usually to support fast equality checking and sets and so forth. |
| 2026-04-09 19:48:10 +0000 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2026-04-09 19:47:46 +0000 | <tomsmeding> | right, selective recomputation is a thing that optimising compilers of functional languages have to deal with, and it's tricky to do properly (i.e. without accidentally pessimising) |
| 2026-04-09 19:46:52 +0000 | <monochrom> | Oleg once complained about memoizing a really long list taking too much memory. I think he believed that the list can be easily recomputed, not worth memoizing. |
| 2026-04-09 19:46:09 +0000 | <acarrico> | Anyway, it is an interesting paper. |
| 2026-04-09 19:45:47 +0000 | <tomsmeding> | right |
| 2026-04-09 19:45:41 +0000 | <acarrico> | tomsmeding: In some sense it is just a very easy implementation strategy that happens to work very well for that DSL. |
| 2026-04-09 19:45:27 +0000 | <tomsmeding> | it's the "duplicate all the work yolo" of plain call-by-name that I claim to be useless |
| 2026-04-09 19:45:09 +0000 | <tomsmeding> | call by need is obviously useful, haskell has it |
| 2026-04-09 19:45:09 +0000 | <acarrico> | tomsmeding: I would tend to call by need the "thunk" strategy, which is a bit different. |
| 2026-04-09 19:44:54 +0000 | <tomsmeding> | but, depending on how it's implemented, possibly slower than a direct, mutating call-by-need implementation |
| 2026-04-09 19:44:28 +0000 | <tomsmeding> | call by name + memoisation is call by need |
| 2026-04-09 19:44:18 +0000 | <acarrico> | A call by name strategy with interning and a memoized evaluator. |
| 2026-04-09 19:44:18 +0000 | <monochrom> | reuse-vs-cloning is the same debate as recompute-vs-caching i.e. waste time vs waste space :) |
| 2026-04-09 19:44:09 +0000 | <tomsmeding> | call by need is the thing that's lazy and computes stuff at most once |
| 2026-04-09 19:43:52 +0000 | <acarrico> | Every thing is "interned" or "hash consed" |
| 2026-04-09 19:43:49 +0000 | <tomsmeding> | call by name does not share work |
| 2026-04-09 19:43:39 +0000 | <acarrico> | You do share work due to maixmal laziness. |
| 2026-04-09 19:43:11 +0000 | <tomsmeding> | they want it to be impossible to share any work? |
| 2026-04-09 19:42:37 +0000 | <acarrico> | tomsmeding: Anyone who uses NixOS/Nixpkgs cares about call by name as an operational behavior, see Eelco Dolstra's paper "Maximal Laziness". |
| 2026-04-09 19:34:54 +0000 | <monochrom> | Fortunately he added a sentence "this kind of thing is nicer in Haskell" :) |
| 2026-04-09 19:33:48 +0000 | <monochrom> | For example Lawrence Paulson in "ML for the Working Programmer"! |
| 2026-04-09 19:33:22 +0000 | <EvanR> | yep that's inefficient |
| 2026-04-09 19:32:44 +0000 | <monochrom> | People who simulate (with infelicity, you'll see!) lazy evaluation in SML or Scheme by converting my example to (\f -> f () + f()) (\_ -> 2*2) |
| 2026-04-09 19:31:52 +0000 | <EvanR> | I figured this was all operational semantics |
| 2026-04-09 19:31:38 +0000 | redshuffle | (~quassel@45.43.70.75) |
| 2026-04-09 19:31:31 +0000 | redshuffle | (~quassel@45.43.70.75) (Remote host closed the connection) |
| 2026-04-09 19:31:20 +0000 | <tomsmeding> | yes and who on earth cares about call by name as an operational behaviour |
| 2026-04-09 19:30:16 +0000 | <monochrom> | lazy evaluation is call by need. call by name differs from that by cloning instead of reuse. call by need: (\x -> x + x) (2*2) --> let x=2*2 in x + x. call by name: (2*2) + (2*2) |
| 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 |