02:51 <companion_cube> octachron: is it normal that many functions in `List` are still not TRMC? e.g. merge, combine, remove_assq, remove_assoc

02:57 <discocaml> <sixilli> Ik this is super vague, but how do functional languages handle polymorphism like this? I'm trying to achieve something similar but my brain is too deep in OOP

02:57 <discocaml> <sixilli>

02:57 <discocaml> <sixilli> ```ocaml

02:57 <discocaml> <sixilli> let get_area (obj: Shape): float = obj.area()

02:57 <discocaml> <sixilli> ```

02:58 <companion_cube> depends on what tradeoff you want.

02:59 <companion_cube> some runtime overhead: you could use objects to represent shapes

02:59 <companion_cube> fast but not extensible: make shape a sum type, and `get_area` a pattern match

03:01 <discocaml> <sixilli> I think I might need to use objects. I need to create something somewhat generic that can attempt to get a values using a string then return a string, bool, or list of string.

03:02 <discocaml> <sixilli> I think I might need to use objects. I need to create something somewhat generic that can attempt to get a values from a record using a string then return a string, bool, or list of string.

03:03 <companion_cube> the string, bool, or list of string, at least, is a sum type :)

03:04 <companion_cube> but otherwise, maybe objects are the answer, maybe not

03:04 <companion_cube> they're nearly not as pervasive as in C++

03:06 <discocaml> <sixilli> Yeah I'll have to look around some more. Because the number of records will be generated dynamically. So I need a way to pull data from them by field name. I could also generate code to create a hashtbl with key string, then the sum type?

03:07 <companion_cube> if you generate code, a sum type + functions on it is actually pretty great

03:07 <companion_cube> (no need for a hashtable in that case, it can all be done in code)

03:11 <discocaml> <sixilli> I'm still in the early stages but I'm parsing templates -> generating a record so users can put data in the record -> getting the record back and using it to render the template. The render step needs to be generic and not hardcoded, so looking up values is pretty difficult. So far a hash map has made the most sense lol

03:11 <discocaml> <sixilli> I'm still in the early stages but I'm parsing templates -> generating records so users can put data in the record -> getting the record back and using it to render the template. The render step needs to be generic and not hardcoded, so looking up values is pretty difficult. So far a hash map has made the most sense lol

03:11 <companion_cube> you mean like html templates?

03:12 <discocaml> <sixilli> Yee

03:12 <discocaml> <sixilli> I've been diggind through some other projects to see how they handle it. I wanted to build something more user friendly by generating records.

03:13 <discocaml> <sixilli> ```ocaml

03:13 <discocaml> <sixilli> let html_loader = "./templates" [@@deriving html_templating]

03:13 <discocaml> <sixilli>

03:13 <discocaml> <sixilli> (* code that gets generated from some PPX *)

03:13 <discocaml> <sixilli> type my_page_params = { hello: string; world: string; is_admin }

03:13 <discocaml> <sixilli> let render_my_page (params: my_page_params): string =

03:13 <discocaml> <sixilli> let build_ctx params =

03:13 <discocaml> <sixilli> (* todo ??? *)

03:13 <discocaml> <sixilli>

03:13 <discocaml> <sixilli> MyTemplateModule.parse("my_page.html", build_ctx params)

03:13 <discocaml> <sixilli> ```

03:13 <discocaml> <sixilli> idk how possible this is, but this was the code I was trying to generate

03:14 <discocaml> <sixilli> ```ocaml

03:14 <discocaml> <sixilli> let html_loader = "./templates" [@@deriving html_templating]

03:14 <discocaml> <sixilli>

03:14 <discocaml> <sixilli> (* code that gets generated from some PPX *)

03:14 <discocaml> <sixilli> type my_page_params = { hello: string; world: string; is_admin: bool }

03:14 <discocaml> <sixilli> let render_my_page (params: my_page_params): string =

03:14 <discocaml> <sixilli> let build_ctx params =

03:14 <discocaml> <sixilli> (* todo ??? *)

03:14 <discocaml> <sixilli>

03:14 <discocaml> <sixilli> MyTemplateModule.parse("my_page.html", build_ctx params)

03:14 <discocaml> <sixilli> ```

03:14 <discocaml> <sixilli> kinda like ppx_show for html templates

03:17 <companion_cube> ah kind of fun, yeah

03:18 <companion_cube> starting with a ppx is a bit hardcore though :)

03:18 <companion_cube> I wonder, I think I'd probably write one generic render function that takes a hashtable (like you say), and if I had a ppx I'd generate code to go from the custom record of each template, to this hashtable

03:19 <companion_cube> (or alternatively generate a function `the_record -> string -> string option` that serves as lookup)

03:26 <discocaml> <sixilli> Yeah that's exactly what I was thinking. Because the record is much more user friendly. I think the 2nd option gets harder when I need a list. I suppose I could use a sum type for that. 🤔

03:28 <companion_cube> if you want it to be nice to _use_, the record is good I think

03:28 <companion_cube> if you code-generate it that is

03:33 <discocaml> <sixilli> Yeah I think I've now decided that I will let the user use the recored, then when they call the render fn it will map the record to a hash map that will get passed to the parser.

03:34 <companion_cube> 👍

03:36 <discocaml> <sixilli> tyty for talking that through with me

03:36 <discocaml> <sixilli> 🦆

03:37 <companion_cube> quack

05:04 <discocaml> <barconstruction> this might be overkill but maybe you define a module type `Shape`

05:04 <discocaml> <barconstruction> that exposes a type `t` and a function `val area : t -> float`

08:22 <discocaml> <gooby_clown> I think libs often use libsexp for this

08:23 <discocaml> <gooby_clown> Which is just serialization

08:23 <discocaml> <gooby_clown> So that's another option

14:26 <companion_cube> serialization?!

14:29 <discocaml> <octachron> @barconstruction , the subarray change in https://github.com/ocaml/ocaml/pull/12754 seems to fix a lot of the performance issue in your numerical example. I am still investigating if there is something deeper at play.

15:20 <discocaml> <barconstruction> hey thank you very much. i found this gh issue and was wondering if they were related, i appreciate the follow up!

15:20 <discocaml> <barconstruction> @octachron

15:43 <vsiles> hi folks ! I'm witnessing something really strange with Core: https://pastebin.com/KhekNxWk

15:44 <vsiles> Core.String seems to point to Caml.String instead of the String module in Core, making things like Core.String.Map unavailable

15:44 <vsiles> did I miss anything new ?

16:23 <vsiles> looks like I need to do just `Map.find` now... migration pain is on the way

18:49 <Guest97> Hi! do you know libraries/papers that describe how to hide stack memory management with monads? I came up with this pretty basic example `let ( let* ) x f = let ltop = get_stack_pointer () in  let res = f x in clean_stack_up_to_copy ltop res`

18:51 <Guest97> where clean_stack_up_to_copy ltop res cleans the stack from ltop to the connected object res and returns res

20:04 <Guest97> with ctypes, can you create a pointer to a value without allocating a new value with Ctypes.allocate?

20:34 <Guest97> tried this: `let addr = Ctypes.(raw_address_of_ptr (to_voidp v)) in Ctypes.(coerce Ctypes.(ptr void)  (ptr target_type) (ptr_of_raw_address addr))`

20:34 <Guest97> causes segfault when passed to a C function

22:31 <Guest97> mb this to_voidp is wrong