Newest at the top
| 2025-02-07 10:57:22 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-02-07 10:56:49 +0100 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Quit: Leaving) |
| 2025-02-07 10:55:36 +0100 | <tomsmeding> | neiluj: for my curiosity, how is this not true in ocaml? |
| 2025-02-07 10:55:10 +0100 | <neiluj> | thanks! |
| 2025-02-07 10:55:05 +0100 | <neiluj> | yes, that would totally work |
| 2025-02-07 10:54:33 +0100 | <tomsmeding> | if that's not what you mean, then please elaborate :) |
| 2025-02-07 10:54:32 +0100 | <neiluj> | true |
| 2025-02-07 10:54:23 +0100 | <tomsmeding> | k is rather polymorphic and abstract here |
| 2025-02-07 10:54:17 +0100 | <yahb2> | Data.Map.lookup ; :: Ord k => k -> Data.Map.Internal.Map k a -> Maybe a |
| 2025-02-07 10:54:17 +0100 | <tomsmeding> | % :t Data.Map.lookup |
| 2025-02-07 10:54:01 +0100 | <neiluj> | (hitting this limitation in OCaml) |
| 2025-02-07 10:53:45 +0100 | <neiluj> | hi! is there a way to index a map by a polymorphic and abstract type? |
| 2025-02-07 10:53:19 +0100 | neiluj | (~julien@90.121.75.121) neiluj |
| 2025-02-07 10:53:19 +0100 | <haskellbridge> | <magic_rb> There would be some fall out yet, but it does need to happen sooner or later in my opinion |
| 2025-02-07 10:53:05 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 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 |