Newest at the top
| 2025-02-07 11:34:42 +0100 | alp | (~alp@2001:861:8ca0:4940:c543:753a:35f:61ff) |
| 2025-02-07 11:34:26 +0100 | alp | (~alp@2001:861:8ca0:4940:d783:3ed4:b3b2:7c8f) (Remote host closed the connection) |
| 2025-02-07 11:33:00 +0100 | alp | (~alp@2001:861:8ca0:4940:d783:3ed4:b3b2:7c8f) |
| 2025-02-07 11:32:44 +0100 | alp | (~alp@2001:861:8ca0:4940:41b4:15ba:b9c5:e001) (Remote host closed the connection) |
| 2025-02-07 11:32:20 +0100 | akegalj | (~akegalj@141-136-207-93.dsl.iskon.hr) (Ping timeout: 244 seconds) |
| 2025-02-07 11:32:20 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:3bd7:f04:27ee:5a69) ubert |
| 2025-02-07 11:32:05 +0100 | <tomsmeding> | somehow :) |
| 2025-02-07 11:31:57 +0100 | <tomsmeding> | I think you can do the same in ocaml |
| 2025-02-07 11:31:46 +0100 | <tomsmeding> | in haskell, you can't satisfy that Ord constraint unless you know what the 'k' type is, monomorphically, or unless you have that 'k' as a parameter yourself and get the Ord instance from your caller |
| 2025-02-07 11:31:24 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-02-07 11:31:19 +0100 | alp | (~alp@2001:861:8ca0:4940:41b4:15ba:b9c5:e001) |
| 2025-02-07 11:31:02 +0100 | alp | (~alp@2001:861:8ca0:4940:d5b5:2163:e0a9:7a7f) (Remote host closed the connection) |
| 2025-02-07 11:30:04 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 11:27:53 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 11:27:35 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) misterfish |
| 2025-02-07 11:27:01 +0100 | <tomsmeding> | the types look different, but as you say, ocaml is the one that's more flexible, not haskell |
| 2025-02-07 11:26:44 +0100 | <tomsmeding> | I'm not sure it can! That's my point |
| 2025-02-07 11:26:36 +0100 | <neiluj> | sure, thanks! just wanted to see if haskell could solve my problem more easily, and it seems so :) |
| 2025-02-07 11:26:16 +0100 | <tomsmeding> | wherever you export your t, also make sure that module exports a compare function |
| 2025-02-07 11:25:56 +0100 | <neiluj> | plus it's more explicit, so easier to know which function gets called |
| 2025-02-07 11:25:54 +0100 | <tomsmeding> | you might need to visit some ocaml-specific forum to ask for more specific guidance. But I think you can get what you want in ocaml :) |
| 2025-02-07 11:25:35 +0100 | <tomsmeding> | right |
| 2025-02-07 11:25:34 +0100 | <neiluj> | for that type |
| 2025-02-07 11:25:28 +0100 | <neiluj> | given a type t, in ocaml, i can implement to instances of Ord with different comparison functions |
| 2025-02-07 11:24:48 +0100 | <neiluj> | well ocaml functors are more flexible as you can implement multiple instances of a module type for some type, while in haskell you'd need a newtype |
| 2025-02-07 11:24:05 +0100 | <neiluj> | instead of f :: Ord t => t -> t (where the Ord is implicit in the function call) |
| 2025-02-07 11:22:57 +0100 | <neiluj> | for ex: val f : (type t) (module Ord with type t = t) -> t -> t |
| 2025-02-07 11:22:34 +0100 | <tomsmeding> | in other words, I don't see anything yet here that you fundamentally can't do in ocaml but you can do in haskell |
| 2025-02-07 11:22:20 +0100 | <neiluj> | in a sense, you can emulate typeclasses in ocaml with functors, but you have to explicitly specify the module signature, while haskell does that for you with typeclasses |
| 2025-02-07 11:22:18 +0100 | notzmv | (~umar@user/notzmv) (Remote host closed the connection) |
| 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 |