Newest at the top
| 2025-02-07 10:50:52 +0100 | <tomsmeding> | technically, there would be no hackage split: each module could really decide for itself where to execute its splices. But practically, you do need to watch out |
| 2025-02-07 10:50:13 +0100 | <tomsmeding> | viral is indeed the wrong word, I was confused for a bit |
| 2025-02-07 10:49:48 +0100 | <tomsmeding> | because that was (is) the default |
| 2025-02-07 10:49:41 +0100 | <tomsmeding> | but this is rather tricky if you unknowingly make use of functions from other packages that we written with "execution on the target" in mind |
| 2025-02-07 10:49:11 +0100 | <tomsmeding> | which only makes a difference if you're cross-compiling |
| 2025-02-07 10:48:55 +0100 | <tomsmeding> | dminuoso: make all splices in this module run on the host instead of the target. |
| 2025-02-07 10:48:36 +0100 | <dminuoso> | tomsmeding: What does that fictional extension do? |
| 2025-02-07 10:46:49 +0100 | <tomsmeding> | oh, hah, -XTemplateHaskellRunsOnHost would be viral -- yes, that would be a problem |
| 2025-02-07 10:46:09 +0100 | <dminuoso> | The proposal probably isn't even the biggest difficulty. Somebody needs to engineer this into GHC, and for adoption to occur it needs to land in cabal (all parts of it). And there's lengthy discussions about whether to keep two concurrent TH infrastructures or the amount of breakage across hackage if new boundaries between host and target (imports and linkage) were introduced. |
| 2025-02-07 10:46:07 +0100 | <haskellbridge> | <magic_rb> (i will also complain about our c binding generation story, which is worse than rusts -- and also not being able to pass "Storable a" on the stack to a function...) |
| 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"? |