Newest at the top
| 2024-06-23 21:42:40 +0200 | <c_wraith> | You can work inside all those constraints and come up with pretty effective systems. But it's something you need to design around, to some extent. You can't just drop in support. |
| 2024-06-23 21:41:21 +0200 | <c_wraith> | Even if the definition is identical. Nominal typing includes the identity of the defining module. |
| 2024-06-23 21:40:51 +0200 | <c_wraith> | And that includes types - any module getting loaded at run time is a brand new module. data types inside it are not the same as data types from a module that may share the same name. |
| 2024-06-23 21:39:18 +0200 | <c_wraith> | You need to architect your API around module boundaries that support loading new code and replacing the old code with the new code. |
| 2024-06-23 21:38:20 +0200 | <c_wraith> | In some sense "reloading" is a misnomer. It's loading new modules, not replacing existing ones. And yes, the relevant minimum scope is modules. |
| 2024-06-23 21:36:32 +0200 | <c_wraith> | even at -O0, GHC can be slow enough that hot reloading is a notable performance hit. This one is a real practical issue, putting upper bounds on the size of the code you can work with |
| 2024-06-23 21:35:28 +0200 | <c_wraith> | You can't reload code coming from a package. Also note a huge deal, but worth making note of |
| 2024-06-23 21:35:23 +0200 | soverysour | (~soverysou@user/soverysour) (Ping timeout: 264 seconds) |
| 2024-06-23 21:34:31 +0200 | <c_wraith> | the GHC api doesn't support concurrent use. Not a *huge* deal, but you need to ensure that it's only used serially |
| 2024-06-23 21:33:53 +0200 | <c_wraith> | There are a few limitations you need to worry about. |
| 2024-06-23 21:33:35 +0200 | <c_wraith> | I've done hot code reloading in GHC. |
| 2024-06-23 21:32:05 +0200 | <EvanR> | can the types change or not during a hot reload |
| 2024-06-23 21:31:57 +0200 | <EvanR> | I'm curious how hot code reloading should work with static types |
| 2024-06-23 21:31:09 +0200 | <EvanR> | it's easy in an interpreted language, functional or not |
| 2024-06-23 21:28:17 +0200 | soverysour | (~soverysou@user/soverysour) |
| 2024-06-23 21:16:38 +0200 | soverysour | (~soverysou@user/soverysour) (Ping timeout: 252 seconds) |
| 2024-06-23 21:15:01 +0200 | philopsos1 | (~caecilius@user/philopsos) (Ping timeout: 268 seconds) |
| 2024-06-23 21:13:27 +0200 | dcoutts | (~duncan@185.201.60.218) (Ping timeout: 264 seconds) |
| 2024-06-23 21:12:22 +0200 | soverysour | (~soverysou@user/soverysour) |
| 2024-06-23 21:12:22 +0200 | soverysour | (~soverysou@81.196.150.219) (Changing host) |
| 2024-06-23 21:12:21 +0200 | soverysour | (~soverysou@81.196.150.219) |
| 2024-06-23 21:10:12 +0200 | DreamDeckup | (~DreamDeck@bras-base-lprrpq1404w-grc-06-184-145-181-233.dsl.bell.ca) |
| 2024-06-23 21:08:39 +0200 | DreamDeckUp | (~DreamDeck@184.145.181.233) (Remote host closed the connection) |
| 2024-06-23 21:06:56 +0200 | <yin> | hypothetically, hot reloading (changing the code and seeing its effects while the program is running, without reloading it) should be simpler to achieve in a purely functional language, shouldn't it? |
| 2024-06-23 21:06:11 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-06-23 21:02:42 +0200 | wbooze | (~wbooze@2a02:908:1244:9a20:dadb:a586:6c1f:5f08) |
| 2024-06-23 21:02:00 +0200 | DreamDeckUp | (~DreamDeck@184.145.181.233) |
| 2024-06-23 21:01:50 +0200 | wbooze | (~wbooze@2a02:908:1244:9a20:5ad6:6249:8d15:f48) (Remote host closed the connection) |
| 2024-06-23 20:53:26 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 268 seconds) |
| 2024-06-23 20:51:01 +0200 | dcoutts | (~duncan@185.201.60.218) |
| 2024-06-23 20:46:46 +0200 | p3n | (~p3n@217.198.124.246) |
| 2024-06-23 20:45:46 +0200 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-06-23 20:40:15 +0200 | soverysour | (~soverysou@user/soverysour) (Ping timeout: 260 seconds) |
| 2024-06-23 20:39:11 +0200 | deveng | fernando-basso |
| 2024-06-23 20:39:07 +0200 | emm | (~emm@user/edmeme) |
| 2024-06-23 20:37:47 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 264 seconds) |
| 2024-06-23 20:36:43 +0200 | RandomOverlord | (~RandomOve@2603-9009-05f0-8210-c1b1-94c2-fafe-f5cb.inf6.spectrum.com) (Ping timeout: 272 seconds) |
| 2024-06-23 20:35:52 +0200 | tomek1 | (~tomek@109-206-217-73.host.skynet.net.pl) (Quit: WeeChat 3.8) |
| 2024-06-23 20:34:06 +0200 | tomek1 | (~tomek@109-206-217-73.host.skynet.net.pl) |
| 2024-06-23 20:29:41 +0200 | erty | (~user@user/aeroplane) (Ping timeout: 256 seconds) |
| 2024-06-23 20:29:10 +0200 | aaronv | (~aaronv@user/aaronv) |
| 2024-06-23 20:16:19 +0200 | RandomOverlord | (~RandomOve@2603-9009-05f0-8210-c1b1-94c2-fafe-f5cb.inf6.spectrum.com) |
| 2024-06-23 20:14:07 +0200 | aaronv | (~aaronv@user/aaronv) (Ping timeout: 260 seconds) |
| 2024-06-23 20:12:15 +0200 | falafel | (~falafel@2a0c:5a87:3103:ec01::62b8) (Ping timeout: 264 seconds) |
| 2024-06-23 20:12:05 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2024-06-23 20:11:23 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 272 seconds) |
| 2024-06-23 20:10:42 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2024-06-23 20:01:13 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-06-23 19:58:09 +0200 | philopsos1 | (~caecilius@user/philopsos) |
| 2024-06-23 19:57:16 +0200 | philopsos1 | (~caecilius@user/philopsos) (Quit: Lost terminal) |