Newest at the top
| 2024-06-17 10:02:01 +0200 | machinedgod | (~machinedg@node-1w7jr9yjxg4b9uiwhc1g848x6.ipv6.telus.net) |
| 2024-06-17 09:53:33 +0200 | euleritian | (~euleritia@dynamic-176-006-194-173.176.6.pool.telefonica.de) |
| 2024-06-17 09:53:03 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds) |
| 2024-06-17 09:48:53 +0200 | solaire | (~solaire@syn-024-165-026-201.res.spectrum.com) |
| 2024-06-17 09:47:37 +0200 | solaire | (~solaire@syn-024-165-026-201.res.spectrum.com) (Ping timeout: 268 seconds) |
| 2024-06-17 09:46:53 +0200 | rosco | (~rosco@175.136.155.137) (Quit: Lost terminal) |
| 2024-06-17 09:43:47 +0200 | dcoutts_ | (~duncan@oxfd-27-b2-v4wan-164228-cust163.vm42.cable.virginm.net) (Ping timeout: 264 seconds) |
| 2024-06-17 09:37:56 +0200 | solaire | (~solaire@syn-024-165-026-201.res.spectrum.com) |
| 2024-06-17 09:36:16 +0200 | solaire | (~solaire@syn-024-165-026-201.res.spectrum.com) (Ping timeout: 256 seconds) |
| 2024-06-17 09:23:16 +0200 | xff0x | (~xff0x@2405:6580:b080:900:3ca7:5236:8f09:cdd0) (Ping timeout: 255 seconds) |
| 2024-06-17 09:17:59 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-06-17 09:16:10 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 268 seconds) |
| 2024-06-17 09:15:13 +0200 | <danse-nr3> | so i gather referential transparency is part of denotational semantics while evaluation strategy is not? |
| 2024-06-17 09:14:36 +0200 | <Leary> | This is one area where Haskell's beauty is kinda working against us---purity and referential transparency give rise to endless meaning-preserving transformations that the compiler is free to use in optimisation. |
| 2024-06-17 09:14:16 +0200 | <danse-nr3> | thanks probie, seems to confirm your criteria is a valid one, and easy to internalize |
| 2024-06-17 09:13:47 +0200 | <danse-nr3> | thanks Leary... arguably there is a collapse of semantics there, or maybe evaluation is not part of denotational semantics |
| 2024-06-17 09:13:23 +0200 | <probie> | If we have `f a b = let thing = a + b in \c -> thing + c` and `g = f 3 4`, we've made a thunk for `g`, which if reduced to whnf would be `\c -> thing + c` where `thing` is a thunk containing `3 + 4` |
| 2024-06-17 09:12:02 +0200 | <Leary> | danse-nr3: It's mostly a matter of understanding GHC's evaluation strategy and the optimisations it's free to make. For the former you can read up on STG, I guess, but I don't really have a good source for the latter. There are some good SPJ talks and lexi-lambda videos on GHC optimisations, and the -f flags in the User's Guide are a decent reference. |
| 2024-06-17 09:11:43 +0200 | califax | (~califax@user/califx) |
| 2024-06-17 09:11:23 +0200 | <probie> | If we have `f a b c = let thing = a + b in thing + c` and `g = f 3 4`, we've made a thunk for `g`, which if reduced to whnf would be `\c -> let thing = 3 + 4 in thing + c`. However, there is no thunk for `thing` yet |
| 2024-06-17 09:11:01 +0200 | <danse-nr3> | this seems tricky territory anyways. Besides probie's useful criteria, learning resources are welcome |
| 2024-06-17 09:10:56 +0200 | kuribas | (~user@ptr-17d51eokk4x6v7fmbmr.18120a2.ip6.access.telenet.be) |
| 2024-06-17 09:10:23 +0200 | henry40408 | (~henry4040@175.182.111.183) |
| 2024-06-17 09:09:54 +0200 | henry40408 | (~henry4040@175.182.111.183) (Quit: Ping timeout (120 seconds)) |
| 2024-06-17 09:09:20 +0200 | <danse-nr3> | so since as i said there is a passed argument, i guess my thunks already exist |
| 2024-06-17 09:08:55 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-06-17 09:08:48 +0200 | <danse-nr3> | thanks probie, having a thunk so that it can be reused, sounds like a simple criteria that can easily be learned |
| 2024-06-17 09:07:55 +0200 | <probie> | danse-nr3: If you write it naively, the thunk you're talking about won't exist until your function has all its arguments, so it can't possibly be shared. You need something like Axman6's suggestion to make it work |
| 2024-06-17 09:07:54 +0200 | <danse-nr3> | in my case, the expensive operations turn into a non-strict data type that is passed as an argument in the partial application, if that changes anything. So i assume that if a field is needed multiple times it will still get calculated only once? |
| 2024-06-17 09:07:44 +0200 | madhavanmi | (~madhavanm@2409:40f4:1a:21b5:8000::) (Quit: Quit) |
| 2024-06-17 09:04:59 +0200 | califax | (~califax@user/califx) |
| 2024-06-17 09:04:35 +0200 | philopsos1 | (~caecilius@user/philopsos) |
| 2024-06-17 09:03:26 +0200 | <danse-nr3> | *would work |
| 2024-06-17 09:03:00 +0200 | <danse-nr3> | i thoughts thunks will work so that an evaluated value gets reused regardless |
| 2024-06-17 09:02:15 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-06-17 09:01:57 +0200 | euleritian | (~euleritia@dynamic-176-006-194-173.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-06-17 09:01:12 +0200 | euleritian | (~euleritia@dynamic-176-006-194-173.176.6.pool.telefonica.de) |
| 2024-06-17 09:00:35 +0200 | <danse-nr3> | thanks Leary. Do you know about any doc i could read to understand this better? |
| 2024-06-17 08:59:57 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-06-17 08:59:52 +0200 | euleritian | (~euleritia@dynamic-176-003-072-224.176.3.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-06-17 08:59:13 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-06-17 08:58:23 +0200 | <Leary> | danse-nr3: It's up to the whims of the optimiser whether or not to inline your lets, whether or not to float them out, etc. Since it's clever you'll usually see the better outcomes, but if you want to be sure then you need to /make/ sure. The way to get certain sharing is to write let before you take arguments or constraints and NOINLINE the binding. |
| 2024-06-17 08:54:28 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-06-17 08:53:56 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-06-17 08:52:26 +0200 | <danse-nr3> | i thought non-strict evaluation would be enough |
| 2024-06-17 08:51:49 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-189-95.fiber.dynamic.sonic.net) (Ping timeout: 246 seconds) |
| 2024-06-17 08:51:46 +0200 | <danse-nr3> | thanks axman, you get close to my question. Do i need to assign something with `let` or something else for my assumption to be true? |
| 2024-06-17 08:51:40 +0200 | <Axman6> | That may depend on how it's written - what I've written above should avoid any repeated calculateion (assuming c's type doesn't change bettween different calls) |
| 2024-06-17 08:51:01 +0200 | <danse-nr3> | my intuition is that the expensive computation would not be repeated for each varying `c` |
| 2024-06-17 08:51:01 +0200 | <Axman6> | foo a b = let expensive = ... a ... b in \c -> theRest? |