Newest at the top
| 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. |
| 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 |