Newest at the top
| 2025-05-07 08:17:19 +0200 | <dminuoso> | That's the sole reason. |
| 2025-05-07 08:17:17 +0200 | <JuanDaugherty> | a nix fart |
| 2025-05-07 08:17:16 +0200 | <dminuoso> | maerwald: I use nix because NixOS is the sanest way to manage hundreds of servers. |
| 2025-05-07 08:16:55 +0200 | <haskellbridge> | <maerwald> dminuoso: so you use nix but don't care about reproducibility xD |
| 2025-05-07 08:16:43 +0200 | <dminuoso> | And not confuse build and runtime at every step of the way. |
| 2025-05-07 08:16:21 +0200 | <haskellbridge> | <maerwald> Bowuigi: send the IO through an LLM prompt? |
| 2025-05-07 08:16:20 +0200 | <dminuoso> | What I really want is to declare template-haskell-depends and template-haskell-libraries in my foo.cabal. |
| 2025-05-07 08:15:23 +0200 | <dminuoso> | In practice if we look at the average user, the biggest issues about TH is linkage/cross-compilation related. |
| 2025-05-07 08:15:10 +0200 | <haskellbridge> | <sm> that seems to be the usual consensus when it's discussed dminuoso , I guess it's just another of those things that'll happen if ever there's money / need / focus for it |
| 2025-05-07 08:14:44 +0200 | <haskellbridge> | <Bowuigi> So what you need is a way to fake effect execution maerwald |
| 2025-05-07 08:14:00 +0200 | <dminuoso> | Where large parts of IO are just removed. |
| 2025-05-07 08:13:50 +0200 | <dminuoso> | And we could address this by offering a limited TH set and a language pragma |
| 2025-05-07 08:13:38 +0200 | <haskellbridge> | <sm> I care that it's doing something useful for me, I care in that I'd love it to be better so it doesn't limit the tools (and so people don't constantly complain about it ... so boring.... :) :) |
| 2025-05-07 08:13:06 +0200 | <dminuoso> | Yes, there may be snowflake users that may look at it differently. |
| 2025-05-07 08:12:48 +0200 | <haskellbridge> | <maerwald> ;) |
| 2025-05-07 08:12:46 +0200 | <haskellbridge> | <maerwald> you mean you don't care about it |
| 2025-05-07 08:12:36 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-07 08:12:29 +0200 | <dminuoso> | maerwald: In large I dont expect this to actually be meaningful. |
| 2025-05-07 08:12:26 +0200 | haskellbridge | sm is another one depending on TH all the time, I don't mess with it and it doesn't mess with me. But I know it's limiting the capabilities of the tools/language/platforms |
| 2025-05-07 08:12:13 +0200 | <haskellbridge> | <maerwald> unless you reproduce the entire environment |
| 2025-05-07 08:12:10 +0200 | <JuanDaugherty> | and as always a depth of experience issue |
| 2025-05-07 08:12:05 +0200 | <haskellbridge> | <maerwald> well, it causes problems with reproducible build artifacts |
| 2025-05-07 08:11:43 +0200 | <JuanDaugherty> | dminuoso, yeah |
| 2025-05-07 08:11:40 +0200 | <dminuoso> | It's a philosophical issue. |
| 2025-05-07 08:11:33 +0200 | <dminuoso> | It's just not a practical issue that ever concerns users. |
| 2025-05-07 08:11:27 +0200 | <dminuoso> | in all my years, I have never heard a single user complain "I dont know whether this TH splice is doing network access" |
| 2025-05-07 08:11:23 +0200 | <haskellbridge> | <maerwald> compile time being unpredictable is GARBAGE |
| 2025-05-07 08:11:14 +0200 | <haskellbridge> | <maerwald> runtime being "unpredictable" is one thing and kinda expected |
| 2025-05-07 08:11:07 +0200 | <JuanDaugherty> | *intruding |
| 2025-05-07 08:11:03 +0200 | <dminuoso> | JuanDaugherty: I dont believe this to ever be an issue. |
| 2025-05-07 08:10:53 +0200 | <JuanDaugherty> | *expectation |
| 2025-05-07 08:10:26 +0200 | <dminuoso> | Which ultimately is a documentation issue. |
| 2025-05-07 08:10:07 +0200 | <dminuoso> | It sounds like a hidden advertisement for effect systems. |
| 2025-05-07 08:10:02 +0200 | <haskellbridge> | <Bowuigi> Are those TH problems or staging problems? Or both? |
| 2025-05-07 08:09:55 +0200 | <dminuoso> | The argument is about as silly as saying "Dont use anything IO, we dont know what this is doing" |
| 2025-05-07 08:09:49 +0200 | <JuanDaugherty> | omg, rust? rly? |
| 2025-05-07 08:09:48 +0200 | <haskellbridge> | <sm> maybe TH needs bluefin! |
| 2025-05-07 08:09:31 +0200 | <dminuoso> | If we look at rust, its not as compile-time code is innately bad on the basis of not knowing what it may do. |
| 2025-05-07 08:09:20 +0200 | <JuanDaugherty> | *ism |
| 2025-05-07 08:09:12 +0200 | <JuanDaugherty> | maximalist on parade |
| 2025-05-07 08:09:07 +0200 | <dminuoso> | Every time I look at it, the main headaches surrounding TH relate to mixing runtime and compile-time dependencies and linkage. |
| 2025-05-07 08:08:58 +0200 | <haskellbridge> | <maerwald> the problem is you can't really know what TH is doing... is it "pure" and maybe just does some templating? Does it run code on the build machine? Does it depend on the environment? Is it reproducible? |
| 2025-05-07 08:08:43 +0200 | <JuanDaugherty> | or alternatively not properly separated |
| 2025-05-07 08:08:27 +0200 | <JuanDaugherty> | also dev thing intrruding in ops |
| 2025-05-07 08:08:08 +0200 | <JuanDaugherty> | that's work, and not make work; work the elimination of which is based on unreasonable expection |
| 2025-05-07 08:07:47 +0200 | <dminuoso> | maerwald: I feel like there is such a simple solution to all of this. Separate TH dependency set (plus a bit of cabal-wiring, so you get a th-depends section), and voila - problems start to disappear! |
| 2025-05-07 08:07:05 +0200 | <JuanDaugherty> | so? |
| 2025-05-07 08:06:49 +0200 | <haskellbridge> | <maerwald> TH causes lots of problems with bootstrapping, cross compiling and breaks certain invariants |
| 2025-05-07 08:06:45 +0200 | <JuanDaugherty> | i c |
| 2025-05-07 08:06:26 +0200 | <dminuoso> | Compiler plugins. |