Newest at the top
| 2025-02-07 11:13:00 +0100 | <tomsmeding> | does Set have its own OrderedType? Are they compatible? |
| 2025-02-07 11:12:52 +0100 | <tomsmeding> | merijn: re maps with different orderings for the same type: sure, but I was just surprised that it was Map.OrderedType, not Stdlib.OrderedType or whatever |
| 2025-02-07 11:12:14 +0100 | <tomsmeding> | (or however you generally instantiate such OrderedType modules) |
| 2025-02-07 11:11:58 +0100 | <tomsmeding> | alternatively, in ocaml, wherever you define this abstract type t (as a non-abstract type, which you then later presumably export as abstract), also give a 'compare' function? |
| 2025-02-07 11:11:42 +0100 | <neiluj> | there's no general Ord-like thing, but you can see that all *.OrderedType (Set,Map) module signatures are alike |
| 2025-02-07 11:11:31 +0100 | CiaoSen | (~Jura@2a05:5800:220:3300:ca4b:d6ff:fec1:99da) (Quit: CiaoSen) |
| 2025-02-07 11:11:01 +0100 | <tomsmeding> | (furthermore, the orphan rules dictate that such an instance ought to be defined in the same module as where the type itself is defined) |
| 2025-02-07 11:10:36 +0100 | <tomsmeding> | in Haskell, that Ord typeclass instance also needs to come from somewhere, and you can only define such an instance if you actually know what type you have in hand (of course) |
| 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!) |