Newest at the top
| 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. |
| 2025-02-07 10:31:02 +0100 | <tomsmeding> | GHC ensures that TH runs on the target architecture, not the host architecture, when cross compiling |
| 2025-02-07 10:30:59 +0100 | <haskellbridge> | <magic_rb> Ghc plugins are worse :) |
| 2025-02-07 10:30:50 +0100 | <merijn> | No proper separation of host vs target in TH |
| 2025-02-07 10:30:39 +0100 | <merijn> | It's a mess, which is why cross compilation and TH work so nightmarish |
| 2025-02-07 10:30:36 +0100 | <tomsmeding> | if you're cross-compiling or have external-interpreter, it's black magic |
| 2025-02-07 10:30:26 +0100 | <tomsmeding> | TH is run through bytecode in ghci-style, indeed |
| 2025-02-07 10:30:21 +0100 | <merijn> | dminuoso: Don't ask |
| 2025-02-07 10:30:15 +0100 | <merijn> | but much faster than complex type level computing |
| 2025-02-07 10:30:03 +0100 | <merijn> | dminuoso: TH is kinda slow compared to regular compilation |
| 2025-02-07 10:30:01 +0100 | <tomsmeding> | dminuoso: exactly, it's funny because TH is known to be not-fast, but then constraint propagation is just devastatingly slow |
| 2025-02-07 10:29:47 +0100 | <dminuoso> | Now that we're actually talking about it, how is TH executed anyway? Is that via bytecode? |
| 2025-02-07 10:29:12 +0100 | <dminuoso> | Not sure why TH should be slow to begin with. |
| 2025-02-07 10:29:05 +0100 | <dminuoso> | tomsmeding: Compared to programming propagation into generics and type system? Uh. |