Newest at the top
| 2025-02-07 10:45:03 +0100 | <tomsmeding> | tbh -XTemplateHaskellRunsOnHost is maybe just the thing that fixes most problems for least effort |
| 2025-02-07 10:44:55 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 10:44:42 +0100 | <tomsmeding> | compiling TH slices to native code instead of bytecode is something that isn't visible from userland, so that doesn't need a proposal, just a motivated ghc hacker |
| 2025-02-07 10:44:36 +0100 | <haskellbridge> | <magic_rb> Cross compilation is becoming ever more important and TH (and plugins to a much worse degree) are blocking progress |
| 2025-02-07 10:43:50 +0100 | <haskellbridge> | <magic_rb> I think we all agree that something needs to be done with TH and i also think all the somethings are quite close to each other. Someone just needs to write down a proposal |
| 2025-02-07 10:43:35 +0100 | <tomsmeding> | right, there's some engineering required to make this happen in practice, but in terms of compilation and linking etc., it's not more difficult -- the work is "just" in adding flags to ghc and some logic in the build process to allow building shared libraries also for subsets of the module tree |
| 2025-02-07 10:42:54 +0100 | <int-e> | That said I'm *for* separating TH imports from runtime imports. But it feels like a thing that you could do without dramatically changing TH. |
| 2025-02-07 10:42:43 +0100 | <haskellbridge> | <magic_rb> Ig so, dunno how hard ghc makes that "just" |
| 2025-02-07 10:42:39 +0100 | <dminuoso> | The convenience of just packing TH next to program code and importing in both directions comes at the price of convenience when using TH... |
| 2025-02-07 10:42:12 +0100 | <tomsmeding> | you can just _not_ compile whatever modules depend on the module that contains the TH function definition, and then compile that to a library |
| 2025-02-07 10:41:40 +0100 | <haskellbridge> | <magic_rb> Which is what proc macros become, shared objects afaik |
| 2025-02-07 10:41:29 +0100 | <int-e> | While for Haskell that's a module. |
| 2025-02-07 10:41:23 +0100 | <haskellbridge> | <magic_rb> Its harder to spew out a module into .so than a crate |
| 2025-02-07 10:40:56 +0100 | <int-e> | which is not so different either; crates are rust's compilation units |
| 2025-02-07 10:40:51 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-07 10:40:39 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 268 seconds) |
| 2025-02-07 10:40:37 +0100 | <haskellbridge> | <magic_rb> *drop the "To you" dunno how that happenef |
| 2025-02-07 10:40:05 +0100 | <haskellbridge> | <magic_rb> Because GHC really wants it to be "a integrated part of your program". Compare rustc and haskell. To you a proc macro it must be defined in a different crate. While TH has to be define in a different module |
| 2025-02-07 10:40:02 +0100 | <dminuoso> | For all its slices. |
| 2025-02-07 10:39:53 +0100 | <tomsmeding> | would every slice indicate their own dependencies? Or would a packaeg indicate TH deps for all its slices? |
| 2025-02-07 10:39:14 +0100 | <dminuoso> | That communicates with GHC via some protocol |
| 2025-02-07 10:39:03 +0100 | <dminuoso> | Sometimes I dont get why TH is this problematic. Like, why are we not forced to just specify separate dependencies for TH (C and Haskell), and then it becomes just a dumb Haskell program that is executed in the middle of parsing... |
| 2025-02-07 10:39:02 +0100 | <haskellbridge> | <magic_rb> Ah, havent written rust in a few years, good to knoe |
| 2025-02-07 10:38:45 +0100 | <int-e> | nope it's a third party crate |
| 2025-02-07 10:38:39 +0100 | <tomsmeding> | well "copy the impl and idea" sounded a bit more expansive than this :p |
| 2025-02-07 10:38:35 +0100 | <haskellbridge> | <magic_rb> int-e isnt that a built in crate? |
| 2025-02-07 10:38:17 +0100 | <haskellbridge> | <magic_rb> Yeah thats what i meant :) just called it ProcMacros |
| 2025-02-07 10:37:53 +0100 | <tomsmeding> | that sounds like it wouldn't be worth making a new language extension for. Just add {-# LANGUAGE TemplateHaskellRunsOnHost #-} or something. :P |
| 2025-02-07 10:37:40 +0100 | <int-e> | then explain why rust has the horror that is `syn` |
| 2025-02-07 10:37:40 +0100 | <haskellbridge> | <magic_rb> And being compiled |
| 2025-02-07 10:37:37 +0100 | <hololeap> | Leary: that's so simple it makes me think I've been overthinking this |
| 2025-02-07 10:37:29 +0100 | <tomsmeding> | much better just because they run on the host? |
| 2025-02-07 10:37:23 +0100 | <haskellbridge> | <magic_rb> int-e so do proc macros |
| 2025-02-07 10:37:15 +0100 | <haskellbridge> | <magic_rb> So yes macro_rules! Is nicer than proc macros but their proc macros are much better than our template haskell |
| 2025-02-07 10:36:57 +0100 | <tomsmeding> | ah |
| 2025-02-07 10:36:55 +0100 | <int-e> | at least TH gives you a syntax tree |
| 2025-02-07 10:36:47 +0100 | m5zs7k | (aquares@web10.mydevil.net) m5zs7k |
| 2025-02-07 10:36:45 +0100 | <haskellbridge> | <magic_rb> No they define it as running on the host not the target and also they compile them down to machine code |
| 2025-02-07 10:36:42 +0100 | tomsmeding | never used rust proc macros |
| 2025-02-07 10:36:20 +0100 | <tomsmeding> | isn't rust proc macros essentially TH, whereas macro_rules! is the one that is "nicer"? |
| 2025-02-07 10:35:58 +0100 | <haskellbridge> | <magic_rb> And just deprecate TH (never removing it probably, but throw a big fat warning) |
| 2025-02-07 10:35:40 +0100 | <haskellbridge> | <magic_rb> Maybe we ought to make a new language feature called "ProcMacros" and then copy the impl and idea verbatim from Rust |
| 2025-02-07 10:35:30 +0100 | <dminuoso> | Nice. |
| 2025-02-07 10:34:57 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-02-07 10:34:53 +0100 | <tomsmeding> | much nicer than mine |
| 2025-02-07 10:34:44 +0100 | <lambdabot> | "1203" |
| 2025-02-07 10:34:42 +0100 | <hololeap> | > let f = foldr cons' [] where { cons' '0' [] = []; cons' c cs = c:cs } in f "120300" |
| 2025-02-07 10:33:48 +0100 | <tomsmeding> | nice |
| 2025-02-07 10:33:32 +0100 | <dminuoso> | tomsmeding: Regarding speed, when we switched from generic FromJSON/ToJSON to TH (some 100 instances perhaps), we brought down compilation speed from 5 minutes to roughly 20s in our large project. |
| 2025-02-07 10:33:31 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |