Newest at the top
| 2025-02-07 11:09:57 +0100 | <tomsmeding> | neiluj: I'm not an ocaml programmer (as you can see), but within your library, isn't the t type known? That is to say, surely it's a monomorphic type _somewhere_, and then just create the Map there? |
| 2025-02-07 11:09:38 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 11:09:24 +0100 | <neiluj> | tomsmeding: yes, that's the one from the built-in standard library |
| 2025-02-07 11:09:15 +0100 | <merijn> | tomsmeding: That lets you have maps with different orderings for the same type |
| 2025-02-07 11:08:52 +0100 | <merijn> | tomsmeding: What we really just need is proper phased TH that lets you specify whether something should run on host or target, because both are valid for different scenarios |
| 2025-02-07 11:08:16 +0100 | <tomsmeding> | funny, that OrderedType is scoped within Map; there is no general Ord-like thing? |
| 2025-02-07 11:08:13 +0100 | alp | (~alp@2001:861:8ca0:4940:d5b5:2163:e0a9:7a7f) |
| 2025-02-07 11:07:22 +0100 | <tomsmeding> | (That is to say, this one https://ocaml.org/manual/5.3/api/Map.Make.html ) |
| 2025-02-07 11:06:41 +0100 | <tomsmeding> | (I seem to recall that ocaml has various standard libraries) |
| 2025-02-07 11:06:31 +0100 | <tomsmeding> | neiluj: is this the proper Map type to look at? https://ocaml.org/docs/maps |
| 2025-02-07 11:06:20 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-02-07 11:00:04 +0100 | <neiluj> | *typeclass |
| 2025-02-07 10:59:13 +0100 | <neiluj> | kind of regretting I didn't go with Haskell for these bindings |
| 2025-02-07 10:58:53 +0100 | <neiluj> | but that would work nicely with Data.Map as it would only require to implement the typecall Ord for that type |
| 2025-02-07 10:58:11 +0100 | <neiluj> | just to give more context, wrote bindings to the Pari/GP C library https://github.com/jtcoolen/ocaml-pari/blob/staging/src/pari.mli#L5. The main type is an abstract polymorphic type 'a t for which I'd like to set up a map with keys of type 'a t. You cannot do that in OCaml, as Map.Make expects a non polymorphic type t for the keys |
| 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 |