Newest at the top
| 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 |
| 2025-02-07 10:33:27 +0100 | <Leary> | hololeap: `foldr cons' [] where { cons' '0' [] = []; cons' c cs = c:cs }` |
| 2025-02-07 10:33:19 +0100 | <tomsmeding> | (We could have specified that TH runs on the host, and GHC would have a much easier job when cross-compiling. But then hacks like $(sizeOf (undefined :: Int)) don't work) |
| 2025-02-07 10:32:55 +0100 | <tomsmeding> | merijn: isn't that there _is_ proper separation, we just chose, by historical accident, to take the side that's awful to support for GHC? |
| 2025-02-07 10:32:33 +0100 | <dminuoso> | Yeah and that's slightly bizarre. |
| 2025-02-07 10:32:04 +0100 | <tomsmeding> | iirc |
| 2025-02-07 10:32:02 +0100 | <tomsmeding> | also if your package depends on C libraries, these are already linked in when interpreting TH -- and it takes the dynamic libraries, even if you link the libraries statically in the package normally |
| 2025-02-07 10:31:42 +0100 | <haskellbridge> | <magic_rb> You can get TH working while cross compiling, its not even _that_ bad to get it working. But plugins are just unsupported period |
| 2025-02-07 10:31:40 +0100 | m5zs7k | (aquares@web10.mydevil.net) (Ping timeout: 244 seconds) |
| 2025-02-07 10:31:06 +0100 | <tomsmeding> | this produces... difficulties |
| 2025-02-07 10:31:06 +0100 | <dminuoso> | When I pondered about TH, I kept thinking that one of the problems of TH is that it's meddled into the linkage of the program too much. |