03:59 <discocaml> <bluddy5> Youre not going to be able to compete with highly optimized c++. Your best chance is to try oxcaml.

09:02 <discocaml> <lukstafi> I just had a "brilliant" idea (quotes because either it turn out false for mundane reasons or ironic reasons) -- I add a type parameter to the main datatype of my framework so that users can attach domain-specific meaning hints that will show up in function signatures, and in some cases will get statically verified. I will not otherwise do anything with this type -- no preservation nor alternation by the framework operations. Technically, I w

09:11 <discocaml> <lukstafi> Ah, `mutable phantom_info : 'a list` actually, better for disjunctive types.

09:19 <discocaml> <lukstafi> Could that have some annoyances of the sort "type variable escapes scope"?

09:22 <discocaml> <lukstafi> Quick, someone dissuade me

09:26 <discocaml> <lukstafi> Ah, so if I have a binary function that disambiguates the arguments via the phantom type, one would need to write `f x (erase_phantom x)` sometimes, but that seems like a low price.

09:29 <discocaml> <lukstafi> These phantoms would intentionally mean no guarantee, they would just be mnemonics.

12:54 <discocaml> <lukstafi> I'll try this out, but without the `mutable` part (which should remove the worry about escaping variables as all will be polymorphic).

13:20 <discocaml> <deepspacejohn> You mean something similar to this?

13:20 <discocaml> <deepspacejohn> ```ocaml

13:20 <discocaml> <deepspacejohn> module M : sig

13:20 <discocaml> <deepspacejohn> type 'a t

13:20 <discocaml> <deepspacejohn> val make : unit -> 'a t

13:21 <discocaml> <deepspacejohn> val do_something : 'a t -> 'a t -> unit

13:21 <discocaml> <deepspacejohn> end = struct

13:21 <discocaml> <deepspacejohn> type 'a t = unit

13:21 <discocaml> <deepspacejohn> let make () = ()

13:21 <discocaml> <deepspacejohn> let do_something () () = ()

13:21 <discocaml> <deepspacejohn> end

13:21 <discocaml> <deepspacejohn>

13:21 <discocaml> <deepspacejohn> let x : int M.t = M.make ()

13:21 <discocaml> <deepspacejohn> let y : string M.t = M.make ()

13:21 <discocaml> <deepspacejohn> let () = M.do_something x y (* type error *)

13:21 <discocaml> <deepspacejohn> ```

13:21 <discocaml> <deepspacejohn> I've used a technique like this before when writing a DSL so the user could add arbitrary types to certain values.

13:23 <discocaml> <deepspacejohn> As far as using a phantom type goes, not the mutable option/list parts.

14:56 <discocaml> <lukstafi> Yes. Except the use case I have in mind is `val do_something : `source t -> `dest t -> unit` -- i.e. like argument labels (I have secret reasons to not just use labels)

15:02 <discocaml> <lukstafi> With the `mutable` field you provide more enforcement, the values cannot be multiple types so if they get reused they need annotations that are like labels: `do_something (source x) (dest y)` where `let source x = { x with phantom_info = `source}`

15:06 <discocaml> <lukstafi> A third option would be (without `mutable`) to generate non-polymorphic values from `make` and then all "label-using" places need to be "labeled".

17:44 <discocaml> <myrlhex> Is there a way to pin system-wide? I made a change to dune and would like to use my copy of dune until my code gets mainlined.

17:51 <discocaml> <deepspacejohn> If by system-wide you mean pinning on all switches, then no. Pins are per-switch.

17:52 <discocaml> <deepspacejohn> Or the alternate answer is yes, if you pin it on the global switch and just use that.

17:59 <discocaml> <myrlhex> Right, thanks. I guess if I want to do the latter ergonomically, I'll have to add that to my `.bashrc`? Since the `default` switch's `bin` doesn't seem to exist in `PATH` after loading the local switch's env.

18:07 <discocaml> <deepspacejohn> Yes, although that's also the default way that OPAM works, so it normally would have already updated your `.bashrc` when it was installed. I think running `opam init` might update it too.

18:21 <discocaml> <myrlhex> Thanks lol. Turns out that I wasn't sourcing the opam init script correctly because it was in `.profile` and that doesn't play well with VS Code. And yep, I both see the local switch and the global switch in my path now. Thanks again!

18:21 <discocaml> <deepspacejohn> No problem!