Newest at the top
| 2024-11-08 14:08:31 +0100 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) (Remote host closed the connection) |
| 2024-11-08 14:08:19 +0100 | mceresa | (~mceresa@user/mceresa) mceresa |
| 2024-11-08 14:07:14 +0100 | BolzmannPain | (~BolzmannP@user/BolzmannPain) (Quit: Client closed) |
| 2024-11-08 14:03:14 +0100 | <yin> | maybe i abuse record updating |
| 2024-11-08 14:01:38 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2024-11-08 14:01:14 +0100 | <yin> | i guess i'm thinking about the performance of product types in general comparing to, say, HashMap |
| 2024-11-08 14:00:21 +0100 | ih1d | (~ih1d@24.139.109.18) (Client Quit) |
| 2024-11-08 13:59:04 +0100 | ih1d | (~ih1d@24.139.109.18) |
| 2024-11-08 13:57:57 +0100 | <Leary> | yin: It's a matter of interface, not representation. With regular product types, you only have positional notation for manipulating contained values. Records just let you specify them with names instead. |
| 2024-11-08 13:57:45 +0100 | <Rembane> | yin: As product types plus some functions. Like the `data` types with many arguments without the record stuff. |
| 2024-11-08 13:57:39 +0100 | <opqdonut> | but I have no idea what GHC actually does |
| 2024-11-08 13:57:13 +0100 | <opqdonut> | I wouldn't expect using or not using record syntax to affect the runtime characteristics |
| 2024-11-08 13:57:06 +0100 | BolzmannPain | (~BolzmannP@user/BolzmannPain) BolzmannPain |
| 2024-11-08 13:56:57 +0100 | poscat | (~poscat@user/poscat) poscat |
| 2024-11-08 13:56:39 +0100 | <yin> | Rembane: yes but how is their structure implemented internally? |
| 2024-11-08 13:54:21 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3309-f88a-dc43-ac5e-6a5b-79bd.rev.sfr.net) alexherbo2 |
| 2024-11-08 13:54:13 +0100 | poscat | (~poscat@user/poscat) (Quit: Bye) |
| 2024-11-08 13:53:22 +0100 | <Rembane> | yin: IIRC it's syntactic sugar for not having to write out all the access functions and save functions for a datatype. |
| 2024-11-08 13:52:24 +0100 | <kqr> | Text.Printf does not come with an instance for Text. When I poke around I see some suggestions to use Data.Text.Format instead. Is this actually preferred? I find very little comparison online. The use case is not large templating but creating a Show instance for a custom numeric type – so I'm hesitant to reach for something that's not in base. |
| 2024-11-08 13:52:04 +0100 | <yin> | philosophically, are records just a data structure that we give the compiler permission to optimize however it sees fit or is there something more to it? |
| 2024-11-08 13:51:33 +0100 | mceresa | (~mceresa@user/mceresa) (Read error: error:0A000119:SSL routines::decryption failed or bad record mac) |
| 2024-11-08 13:47:09 +0100 | poscat | (~poscat@user/poscat) poscat |
| 2024-11-08 13:45:06 +0100 | poscat | (~poscat@user/poscat) (Client Quit) |
| 2024-11-08 13:44:16 +0100 | <Rembane> | Welcome back yin! :/ |
| 2024-11-08 13:43:27 +0100 | <yin> | i thought i got over my hate for record syntax... |
| 2024-11-08 13:43:22 +0100 | poscat | (~poscat@user/poscat) poscat |
| 2024-11-08 13:35:58 +0100 | <yin> | turns out record update syntax is weirder than i thought https://gitlab.haskell.org/ghc/ghc/-/issues/25456 |
| 2024-11-08 13:35:48 +0100 | poscat0x04 | (~poscat@user/poscat) (Ping timeout: 276 seconds) |
| 2024-11-08 13:32:09 +0100 | visilii | (~visilii@85.172.77.90) (Ping timeout: 260 seconds) |
| 2024-11-08 13:28:08 +0100 | sourcetarius | (~sourcetar@user/sourcetarius) sourcetarius |
| 2024-11-08 13:24:14 +0100 | euleritian | (~euleritia@77.22.252.56) |
| 2024-11-08 13:24:03 +0100 | euleritian | (~euleritia@dynamic-176-006-140-137.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-11-08 13:13:20 +0100 | xff0x | (~xff0x@2405:6580:b080:900:833e:a4a2:2f15:5b32) |
| 2024-11-08 13:02:33 +0100 | mulk | (~mulk@pd95146e9.dip0.t-ipconnect.de) mulk |
| 2024-11-08 13:00:23 +0100 | mulk | (~mulk@pd95146e9.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2024-11-08 12:51:53 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-08 12:51:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-11-08 12:45:39 +0100 | euleritian | (~euleritia@dynamic-176-006-140-137.176.6.pool.telefonica.de) |
| 2024-11-08 12:45:21 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 248 seconds) |
| 2024-11-08 12:44:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-08 12:36:52 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2024-11-08 12:31:22 +0100 | vpan | (~vpan@212.117.1.172) |
| 2024-11-08 12:31:13 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-11-08 12:18:56 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2024-11-08 12:18:43 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 2024-11-08 12:15:00 +0100 | chele | (~chele@user/chele) chele |
| 2024-11-08 11:55:28 +0100 | mulk | (~mulk@pd95146e9.dip0.t-ipconnect.de) mulk |
| 2024-11-08 11:51:44 +0100 | mulk | (~mulk@pd95146e9.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2024-11-08 11:50:47 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2024-11-08 11:50:14 +0100 | xff0x | (~xff0x@om126254173224.33.openmobile.ne.jp) (Read error: Connection reset by peer) |