Newest at the top
| 2025-02-07 11:21:54 +0100 | <tomsmeding> | or perhaps this means that the whole bindings package needs to live inside that module? |
| 2025-02-07 11:21:41 +0100 | <tomsmeding> | neiluj: Ideally you'd need to have a module that defines your wrapping of GEN, which (among other things) defines a compare function so that it satisfies Map.OrderedType. The module's internals are abstract. However, somehow the rest of your library would need to be able to access those internals nevertheless |
| 2025-02-07 11:20:36 +0100 | misterfish | (~misterfis@h239071.upc-h.chello.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 11:20:31 +0100 | <tomsmeding> | neiluj: I see! Then it makes sense. :) |
| 2025-02-07 11:20:20 +0100 | <tomsmeding> | merijn: sorry for being tardy. Yes, we need both styles of TH, hence this being a switch you can also _not_ turn on. But it's probably even better to do this with slice granularity, not module granularity :) |
| 2025-02-07 11:20:12 +0100 | <neiluj> | tomsmeding: precisely, and any module whose signature is a superset of some module signature S can be accepted as an instance of S whenever some function or functor expects an S |
| 2025-02-07 11:19:09 +0100 | <tomsmeding> | (That would be classic object-oriented style, C++/Java style) |
| 2025-02-07 11:18:57 +0100 | <tomsmeding> | an alternate design could be that when defining an ocaml module, you have to specify (by name) which signatures it implements, and then it doesn't implement any others. |
| 2025-02-07 11:18:16 +0100 | <tomsmeding> | i.e. go-style, not C++/Java style? |
| 2025-02-07 11:18:07 +0100 | <tomsmeding> | neiluj: and "compatible" means that the type signatures are the same, and if you want to instantiate a signature with some concrete module you can always do that if it happens to match the types in that signature? |
| 2025-02-07 11:17:30 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 11:17:08 +0100 | <neiluj> | tomsmeding: Set has its own OrderedType, and they are compatible with the one from Map because they share the same signature |
| 2025-02-07 11:17:07 +0100 | <tomsmeding> | users can't do that, precisely because it's an abstract data type |
| 2025-02-07 11:17:02 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 268 seconds) |
| 2025-02-07 11:16:28 +0100 | <tomsmeding> | it's the same in haskell; if I define an abstract data type in a haskell module, and I want other people to be able to compare values of those types (so that they can put them in a Map or Set, for example), it's me who has to write that Ord instance and make it available |
| 2025-02-07 11:15:57 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 11:15:39 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.4.2) |
| 2025-02-07 11:15:31 +0100 | <tomsmeding> | neiluj: then from a Haskell programmer's point of view, I would just define a data type in your bindings, export that as abstract (i.e. don't allow other code to look inside / construct or destruct it), and also provide your users with implementations of OrderedType, etc., to the extent that PARI defines those operations and that you consider it suitable for users to have them |
| 2025-02-07 11:13:59 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-07 11:13:57 +0100 | <neiluj> | tomsmeding: yes, so the C library deals with one single recursive type (called GEN), so that all functions take and return GENs. The C library exports a comparison function which I think does structural equality |
| 2025-02-07 11:13:50 +0100 | <tomsmeding> | (does ocaml do duck-typing on module signatures, where if a module satisfies a signature's body, then it implements the signature?) |
| 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 :) |