10:03 <discocaml> <ozirm> Hi! I suspect what I need is impossible, but I'll ask anyway: is there a way to constrain a type variable to a set of concrete types? For example, I know that we can do `type 'a my_list = 'a list constraint 'a = (_ * _)` to make sure only pairs are valid inhabitants of `'a`, but is it possible to constrain `'a` to only unify with say `int` or `string`? Are there any other ways to achieve this that's not too boilerplate-heavy? I know it's possibl

11:10 <discocaml> <andreypopp> Why is discuss in read only mode?

12:01 <discocaml> <octachron> @ozirm : GADTs can be used to descrbie a finite set of type: `type 'a c = Int:int c`, `type 'a l = 'a c * 'a list`.

12:08 <discocaml> <ozirm> @octachron: interesting, it's similar to tagging the list, except in this case we provide a witness of that type. I tried defining `type 'a l = 'b list constraint 'a = 'b c`, but it seems that the type-checker does not look into the possible constructors of `c`. That is, having `type 'a c = Int : int c | Bool : bool c`, I can still instantiate `let l : _ l = ["s"; "b"]`, for example.

12:20 <discocaml> <ozirm> To give you some context I'm trying to model structural "union types" from the WebIDL spec where they are represented as `(float or boolean)`, for example. Preferably, I'd like to avoid wrapping these values to avoid any overhead in the bindings. So in essence, I'd like to be able to write a "partially" polymorphic function like `val f : 'float_or_boolean -> _`.

12:45 <discocaml> <hockletock> you couldn't distinguish `false` and `true` from the tiny float values represented by 000....001 and 000...011 without at least wrapping the boolean

12:47 <discocaml> <hockletock> wrapping the value*

12:49 <discocaml> <_ggole> NaN-boxing is possible for that particular case, but that doesn't seem like a great idea

13:20 <discocaml> <ozirm> @hockletock float and bool are just examples. So it would have to work for the general case.

13:23 <discocaml> <leviroth> How are you planning to use these lists without some sort of tag to say what type the elements are?

13:59 <discocaml> <ozirm> These values are used to generate opaque javascript values. This means that it's totally safe to just pass them to the low-level runtime.

14:07 <discocaml> <ozirm> Consider this example of browser DOM bindings: https://github.com/servo/servo/blob/4ec61c2cdc46d73a3047f4f7e2454465e022420c/components/script/dom/webidls/EventTarget.webidl#L14

14:07 <discocaml> <ozirm>

14:07 <discocaml> <ozirm> I read the webidl files and generate OCaml modules that provide bindings to the described API for js_of_ocaml. In the above case, the `addEventListener` function needs to accept either a `AddEventListenerOptions` or a boolean for the `options` argument. Currently I'm wrapping these with poly variants, so the actual argument type becomes ``[`AddEventListenerOptions of AddEventListenerOptions.t | `Boolean of bool]``. This is ok, but ideally I'd pr

14:33 <discocaml> <deepspacejohn> An opaque value you pass to external code seems like a good use case for abstract types. If you want to avoid wrapping them in a polyvariant but still want the structural `or` logic that polyvariants provide, one option may be to cast them to an abstract type that's parameterized by a phantom polyvariant. https://ocaml.org/play#code=dHlwZSBhZGRFdmVudExpc3RlbmVyT3B0aW9ucyA9IHtmb286IHN0cmluZ30KCm1vZHVsZSBNIDogc2lnCiAgdHlwZSAnYSB0CiAgdmFsIG

14:37 <discocaml> <hockletock> fr: discocaml turns code blocks into tinyurls of playground sessions

14:39 <companion_cube> it's just matterbridge, I'm not going to modify it 😅

15:08 <discocaml> <ozirm> @deepspacejohn: that's pretty cool. I tried something similar with just `type t` for each union type and smart constructors, as in your suggestion. The tricky bit is that generating individual modules for each type that uses `or` is very cumbersome. The name of that module would be derived from each or-case ending up looking like `Node_or_trusted_script_or_dom_string`. And to call the function `Foo.append (Node_or_trusted_script_or_dom_string.do

15:09 <discocaml> <ozirm> Another option, is to duplicate functions and specialize them for each `or` type as in `Foo.append_node`, `Foo.append_dom_string`, etc. Which is nicer, but would also blow up if there's multiple `or` types in the arguments.

16:05 <discocaml> <deepspacejohn> It seems like using polyvariants would eliminate the need to create a module for each possible combination of constructors? Since you would just need one ``val dom_string : string -> [> `Dom_string ] t``

16:10 <discocaml> <deepspacejohn> Since `Node_or_trusted_script_or_dom_string.dom_string` and `Foo_or_bar_or_dom_string.dom_string` would both return the same ``[> `Dom_string ] t`` type.

17:03 <discocaml> <ozirm> You're right. With a smart constructor for each type, the polyvar becomes a phantom type instead of being an explict tag. I'll try that. Thank you!

22:56 <discocaml> <ozirm> As an unrelated follow up to my previous question, I'm struggling to understand why the following code does not typecheck: ``module A : sig val f : [< `A | `B ] -> unit end = struct let f x = ignore [ x; `C ] end``. Is there a safe way to make `x` unify with additional variants?

22:59 <discocaml> <ozirm> For instance, this open variant version on it's own ``let f (x : [> `A | `B ]) = ignore [ x; `C ]``, does typecheck. But if constrained with a module signature it fails.

23:30 <discocaml> <Kali> you flipped the order, did you mean to do that?

23:30 <discocaml> <Kali> the first was < and now you used >

23:33 <discocaml> <leviroth> This compiles: ``module A : sig val f : [< `A | `B ] -> unit end = struct let f x = ignore [ (x :> [ `A | `B | `C ]); `C ] end``

23:35 <discocaml> <ozirm> @ilo_kali yes, since I'm confused by both not typechecking 🙂

23:39 <discocaml> <ozirm> @therewolf Nice, thanks. In my real example, I have many additional tags, I guess I'll have to find a way to track them.