2024/06/17

Newest at the top

2024-06-17 11:54:05 +0200madhavanmi(~madhavanm@2409:40f4:10f2:43ac:8000::)
2024-06-17 11:46:41 +0200noumenon(~noumenon@113.51-175-156.customer.lyse.net) (Quit: Leaving)
2024-06-17 11:31:01 +0200danse-nr3(~danse-nr3@151.37.148.51)
2024-06-17 11:30:51 +0200danse-nr3(~danse-nr3@151.37.209.49) (Ping timeout: 272 seconds)
2024-06-17 11:28:11 +0200lxsameer(~lxsameer@Serene/lxsameer)
2024-06-17 11:27:46 +0200tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz)
2024-06-17 11:24:15 +0200ft(~ft@p3e9bcb39.dip0.t-ipconnect.de) (Quit: leaving)
2024-06-17 11:22:27 +0200philopsos1(~caecilius@user/philopsos) (Ping timeout: 264 seconds)
2024-06-17 11:15:02 +0200econo_(uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity)
2024-06-17 11:04:27 +0200segfaultfizzbuzz(~segfaultf@23-93-189-95.fiber.dynamic.sonic.net) (Ping timeout: 264 seconds)
2024-06-17 10:55:40 +0200__monty__(~toonn@user/toonn)
2024-06-17 10:52:51 +0200dcoutts_(~duncan@oxfd-27-b2-v4wan-164228-cust163.vm42.cable.virginm.net)
2024-06-17 10:50:53 +0200chiselfuse(~chiselfus@user/chiselfuse)
2024-06-17 10:49:37 +0200chiselfuse(~chiselfus@user/chiselfuse) (Remote host closed the connection)
2024-06-17 10:46:49 +0200target_i(~target_i@user/target-i/x-6023099)
2024-06-17 10:44:37 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4)
2024-06-17 10:39:22 +0200chele(~chele@user/chele)
2024-06-17 10:38:46 +0200cfricke(~cfricke@user/cfricke)
2024-06-17 10:32:16 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-06-17 10:31:58 +0200euleritian(~euleritia@dynamic-176-006-194-173.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
2024-06-17 10:27:11 +0200gehmehgehgmg
2024-06-17 10:26:53 +0200dcoutts_(~duncan@oxfd-27-b2-v4wan-164228-cust163.vm42.cable.virginm.net) (Ping timeout: 272 seconds)
2024-06-17 10:26:47 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
2024-06-17 10:26:08 +0200gehmehgeh(~user@user/gehmehgeh)
2024-06-17 10:24:57 +0200sawilagar(~sawilagar@user/sawilagar)
2024-06-17 10:22:43 +0200oo_miguel(~Thunderbi@78-11-181-16.static.ip.netia.com.pl)
2024-06-17 10:21:17 +0200dcoutts_(~duncan@oxfd-27-b2-v4wan-164228-cust163.vm42.cable.virginm.net)
2024-06-17 10:19:39 +0200segfaultfizzbuzz(~segfaultf@23-93-189-95.fiber.dynamic.sonic.net)
2024-06-17 10:08:31 +0200rosco(~rosco@175.136.155.137)
2024-06-17 10:02:01 +0200machinedgod(~machinedg@node-1w7jr9yjxg4b9uiwhc1g848x6.ipv6.telus.net)
2024-06-17 09:53:33 +0200euleritian(~euleritia@dynamic-176-006-194-173.176.6.pool.telefonica.de)
2024-06-17 09:53:03 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds)
2024-06-17 09:48:53 +0200solaire(~solaire@syn-024-165-026-201.res.spectrum.com)
2024-06-17 09:47:37 +0200solaire(~solaire@syn-024-165-026-201.res.spectrum.com) (Ping timeout: 268 seconds)
2024-06-17 09:46:53 +0200rosco(~rosco@175.136.155.137) (Quit: Lost terminal)
2024-06-17 09:43:47 +0200dcoutts_(~duncan@oxfd-27-b2-v4wan-164228-cust163.vm42.cable.virginm.net) (Ping timeout: 264 seconds)
2024-06-17 09:37:56 +0200solaire(~solaire@syn-024-165-026-201.res.spectrum.com)
2024-06-17 09:36:16 +0200solaire(~solaire@syn-024-165-026-201.res.spectrum.com) (Ping timeout: 256 seconds)
2024-06-17 09:23:16 +0200xff0x(~xff0x@2405:6580:b080:900:3ca7:5236:8f09:cdd0) (Ping timeout: 255 seconds)
2024-06-17 09:17:59 +0200euphores(~SASL_euph@user/euphores)
2024-06-17 09:16:10 +0200peterbecich(~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 +0200califax(~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