Newest at the top
| 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. |
| 2025-02-07 10:28:39 +0100 | <dminuoso> | tomsmeding: See, as far as I'm concerned it can just tell me "Could not match <expr1> with <expr2>" and then below in the context tell me stuff about <expr1> and <expr2> |
| 2025-02-07 10:28:31 +0100 | <tomsmeding> | dminuoso: also it's funny that you say that TH is *much* faster. TH is not known for its speediness |
| 2025-02-07 10:27:46 +0100 | <tomsmeding> | This is not trivial to solve |
| 2025-02-07 10:27:43 +0100 | <tomsmeding> | but you perhaps _do_ want to reduce GServant -- but perhaps also keep the original around, or something? |
| 2025-02-07 10:27:29 +0100 | <tomsmeding> | if there's a FilePath around, you probably want that to stay a FilePath -- and you don't want String to turn into [Char] |
| 2025-02-07 10:27:16 +0100 | <hololeap> | yeah dminuoso's was my first implementation, but I wanted to see if I could do it with a right fold |
| 2025-02-07 10:27:12 +0100 | <tomsmeding> | on the other hand, GHC has a tricky job in deciding whether, and how far, to reduce type families and synonyms in type errors |
| 2025-02-07 10:27:10 +0100 | Googulator | (~Googulato@81.183.235.203) (Ping timeout: 240 seconds) |
| 2025-02-07 10:26:55 +0100 | <tomsmeding> | yes, I agree that this is rather useless |
| 2025-02-07 10:26:42 +0100 | <dminuoso> | Just that these two type expressions did not match. |
| 2025-02-07 10:26:34 +0100 | <dminuoso> | tomsmeding: But GHC didnt even tell us about that. |
| 2025-02-07 10:26:31 +0100 | <tomsmeding> | ah! |
| 2025-02-07 10:26:26 +0100 | <tomsmeding> | but yes dminuoso's suggestion has a lot of readability merit :p |
| 2025-02-07 10:26:25 +0100 | <dminuoso> | tomsmeding: I was just holding :k! wrong yesterday, it did resolve to some nonsense. |
| 2025-02-07 10:26:12 +0100 | <tomsmeding> | it works because once it switches to Just, it never becomes Nothing any more |
| 2025-02-07 10:26:12 +0100 | Sgeo_ | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-02-07 10:25:57 +0100 | <hololeap> | hm that does seem to work |
| 2025-02-07 10:25:43 +0100 | <dminuoso> | Just tossing it out there, since "improve" can go either way. |
| 2025-02-07 10:25:41 +0100 | <lambdabot> | Just "1203" |
| 2025-02-07 10:25:40 +0100 | <hololeap> | > let f = foldr (\c -> maybe (if c == '0' then Nothing else Just [c]) (Just . (c:))) Nothing in f "120300" |