Newest at the top
| 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. |
| 2025-05-07 08:06:24 +0200 | <haskellbridge> | <maerwald> Not a joke at all |
| 2025-05-07 08:06:11 +0200 | <JuanDaugherty> | is that a joke? what mechanism do you suggest for affecting haskell compile at that level? |
| 2025-05-07 08:06:08 +0200 | <haskellbridge> | <Bowuigi> Liamzee paradigm switches are useful and can make code clearer, but imperative is usually not the best one to switch to lol |
| 2025-05-07 08:06:01 +0200 | <haskellbridge> | <sm> is there a Good subset or variant of it ? that we could rebrand with a cool name like comptime ! |
| 2025-05-07 08:05:03 +0200 | <haskellbridge> | <maerwald> Real bad |
| 2025-05-07 08:04:52 +0200 | <haskellbridge> | <sm> TH BAD, mmkay... ? |
| 2025-05-07 08:04:34 +0200 | <haskellbridge> | <sm> oh must we |
| 2025-05-07 08:04:24 +0200 | <haskellbridge> | <maerwald> Ok, let's discuss bad idea: Template Haskell |
| 2025-05-07 08:04:05 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-05-07 07:58:55 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-07 07:58:47 +0200 | <haskellbridge> | <Liamzee> ultimately, how things work is that people come up with ideas, other people try them, people figure out how and where they're a bad idea, and use them within limits |
| 2025-05-07 07:58:39 +0200 | <EvanR> | antidisestablishmentarians |
| 2025-05-07 07:57:55 +0200 | <JuanDaugherty> | the enemies of and parasites on doing |
| 2025-05-07 07:57:05 +0200 | <JuanDaugherty> | trashing groups is OK, like capitalist knuckleheads |
| 2025-05-07 07:55:47 +0200 | haskellbridge | sm makes a pot of tea and passes a plate of cakes around |
| 2025-05-07 07:55:31 +0200 | <JuanDaugherty> | well mean is OK just do it on principles not personalities |