01:22 <discocaml_> <limp.biskit> why would records containing functions be used over bare objects / vice versa?

01:23 <discocaml_> <limp.biskit> objects not created as part of a class

01:31 <discocaml_> <akhilindurti> gotcha. i'm guessing if they built the operator in, they could avoid the value restriction

01:39 <discocaml_> <hockletock> records can be used in pattern matching @ada

01:42 <discocaml_> <hockletock> bare objects would let you reuse one object in contexts that don't have to share type information, just don't re-use method names incompatibly

02:17 <discocaml_> <froyo> records are a lighter-weight option when you don't care about subtyping

02:17 <discocaml_> <froyo> and calling their fields is an indirect function call, rather than a heavier method call

02:17 <discocaml_> <froyo> (methods are looked up first)

02:21 <discocaml_> <froyo> objects can be lighter-weight in a specific style of execution

02:22 <discocaml_> <froyo> where you'd otherwise be copying & reallocating records a lot

02:32 <discocaml_> <limp.biskit> i’m trying to avoid any mutable state anyway using the {< syntax

02:33 <discocaml_> <limp.biskit> so any operation that mutates a value will produce a new object

02:33 <discocaml_> <limp.biskit> i don’t know if that’s related to what you’re talking about

02:41 <discocaml_> <limp.biskit> i’m converting (loosely) a type from being a functorized module to an object and i’m finding that object syntax is clunkier imo (losing out on pipelining and the other stuff you get with plain functions). so i was considering writing wrapper functions in a plain module. at which point records are likely better since i am not using any object syntax in the first place

04:33 <discocaml_> <coolccat> I wonder if a non-programmer ever heard of “OCaml” in a conversation and thought it was an Irish last name

04:36 <companion_cube> OCaml my Caml

10:01 <discocaml_> <froyo> Ada: I believe only the fields of an object get reallocated, not the methods. but objects incur a bit of an overhead on their own. an empty object (`object end`) is eight words if I'm not mistaken.

12:30 <discocaml_> <Kali> apparently even programmers do, i've seen websites that call it O'Caml

13:20 <discocaml_> <holmdunc> I think that was in fact the official way to write it, ages ago

13:22 <discocaml_> <._null._> It appears this is true: https://web.archive.org/web/20020328194845/http://www.ocaml.org:80/

13:30 <rustyne> or at least a common way to abbreviate Objective Caml

13:34 <rustyne> (as the tools where already `ocaml*`, it was a natural abbreviation)

13:34 <rustyne> s/where/were/

13:35 <discocaml_> <holmdunc> At the bottom of that old site it says that the webmaster is Julian Assange 🙂

13:55 <discocaml_> <limp.biskit> should’ve named the mac release MacCaml

14:14 <discocaml_> <deepspacejohn> there was (is?) an unfortunately-named ocaml blockchain thing called "SCaml"

14:16 <discocaml_> <Kali> that's very funny

14:16 <discocaml_> <limp.biskit> actual tagline https://scamlang.dev/

14:16 <discocaml_> <limp.biskit> https://cdn.discordapp.com/attachments/436568060288172044/1255527035808514150/image.png?ex=667d742b&is=667c22ab&hm=b085e3e914f565fba95e147a5a309a6ca073bc2ebb917c889a307320bf86b3f6&

16:04 <discocaml_> <barconstruction> Opam team is teasing us with the first release candidate for opam 2.2, after six pre-releases. I'm so ready for a convenient setup on windows! Dkml worked well for me personally but a friend had problems with it

16:09 <discocaml_> <limp.biskit> dkml was a nightmare for me, but i have very little patience with windows

16:09 <discocaml_> <limp.biskit> opam 2.2 looks great

16:09 <discocaml_> <limp.biskit> i tried out the docker containers a bit and they worked good

19:40 <discocaml_> <endymion_alt> is there a way to get the implementation of a function generated by a ppx?