00:16 <companion_cube> Tbh I think functors are a niche feature

07:25 <discocaml> <bluddy5> yep. I have yet to find a practical application where ocaml has the edge using modules and functors. I think most OCaml programmers would happily trade functors for typeclasses.

10:06 <discocaml> <lukstafi> I disagree with "most".

10:19 <discocaml> <limp.biskit> coming from a more OOP background, there are many cases where i don't see modules as any more 'elegant' than objects, just better integrated with ocaml. both excessive functors and java-style inheritance are unpleasant imo

12:14 <discocaml> <contextfreebeer> It's a bit weird to call functors a niche feature, that's a bit like saying C++ templates are a niche feature. Niche in the sense that user code can often avoid writing them, but only because of libraries that do it for the users. Similarly it's hard to imagine an ocaml project that doesn't *use* functors

12:15 <discocaml> <contextfreebeer> But opt-in "typeclasses" via modular implicits could be nice

12:19 <discocaml> <bluddy5> Every project in OCaml tries to remove functor usage as much as it can. They're just too heavy, and there's been nothing practical demonstrated in OCaml that can't be done in other languages without them.

12:21 <discocaml> <bluddy5> Normally I would avoid using such sweeping words as 'nothing' and 'every', but honestly I can't think of anything.

12:29 <discocaml> <bluddy5> Not to say that they're not useful, but as an alternative to typeclasses, they just don't match up.

12:31 <discocaml> <Kali> i've only ever seen functors exposed in stdlibs for map/set stuff

12:31 <discocaml> <Kali> i don't think i've seen them used anywhere else

12:32 <discocaml> <Kali> to the user of a library i mean; they might be used internally

12:34 <discocaml> <sim642> I maintain a static program analyzer and it's functors all the way down

12:36 <discocaml> <contextfreebeer> I'm confused, how do you create any ordered container without a functor parameterized over an ordered type? isn't that practical? also it's super nice to be able to define the ordering any way you wish imo

12:36 <discocaml> <contextfreebeer> and it feels like there a ton of libraries that expose functors, not just map/set in the stdlib

12:37 <discocaml> <contextfreebeer> ok, compared to typeclasses, maybe, that's definitely debatable, I can see arguments on both sides

12:39 <discocaml> <contextfreebeer> for example to stick with ordered types, the typeclass solution would allow only one type of ordering for any type in any given context, so it's less flexible, but arguably that flexibility is unneeded most of the time

12:40 <discocaml> <Kali> doesn't haskell have functor-like behavior for typeclasses through its minimal required implementation or something anyway?

12:42 <discocaml> <Kali> in fact those are often better than functors since they can have multiple different implementations for the same result, whereas you would need separate functors for each minimum requirement

12:46 <discocaml> <Kali> "minimal complete definition" if you want the exact term hackage uses

12:48 <discocaml> <Kali> for instance (pun not intended) an instance of a Data.Eq typeclass can be expressed in terms of a `==` function or a `/=` function

12:50 <discocaml> <Kali> but you would need to manually select which functor to use for ocaml

13:00 <discocaml> <Kali> i feel like the common argument against typeclasses is that you can't have two instances of the same type but 1. that situation is really not that common 2. just make a newtype if you actually must

13:03 <discocaml> <lukstafi> I use functors in `ppx_minidebug` for configuration, but I migrated to using functions with default arguments to setup the functor application. I use a functor in `ocannl` to convert "no-device" CPU-based backends (currently only gccjit) into a "core=device" multicore backends.

13:07 <discocaml> <lukstafi> I'm assuming your argument against functors does not extend to first-class modules? (I'm using them too for code parametrized wrt. backend.)

13:15 <discocaml> <bluddy5> Yeah first class modules are much better, though they could be made lighter.

13:20 <discocaml> <holmdunc> I was more comfortable using functors in SML, because there's not a big buffet of other language to have to think about whether to use or ignore

13:20 <discocaml> <lukstafi> Functors have their obvious applicability: converting one "computational service" (collection of types and functions that operate on them) into another one, where the conversion requires some wrapping. I wonder why you don't encounter that in your projects. If the conversion does not require wrapping then class inheritance would work.

13:22 <discocaml> <deepspacejohn> I like using first-class modules but they're limited by the fact that their types can't have parameters. (e.g. `sig type 'a t end` isn't possible) it's the most common reason why I don't use them.

13:22 <discocaml> <holmdunc> I was more comfortable using functors in SML, because there's not a big buffet of other language features to have to think about whether to use or ignore

13:28 <discocaml> <lukstafi> There's a complication with first-class modules that sometimes you need to repackage them. And in the functions you often need the a variant of this pattern: `let f (type t) (module M : M_type with type t = t) ...`

13:28 <discocaml> <lukstafi> There's a complication with first-class modules that sometimes you need to repackage them. And in the functions you often need a variant of this pattern: `let f (type t) (module M : M_type with type t = t) ...`

13:30 <discocaml> <eval.apply> it is possible, just adds boilerplate https://github.com/yallop/higher

15:10 <companion_cube> @contextfreebeer I think C++ templates that are not just the equivalent of generics, are also a niche feature, yes

15:10 <companion_cube> Niche as in, it can be very useful, but somewhat rarely

15:10 <companion_cube> First class modules are also kind of niche :p

15:11 <companion_cube> They're very useful but only because people don't like using objects. Remove functors and first class modules, use objects more, and you more or less end up with F#

15:12 <companion_cube> Anyway in the broader ecosystem of FP languages it's quite clear that typeclasses are the more popular alternative, no new language is, to my knowledge, adding functors

16:27 <discocaml> <limp.biskit> ocaml's object system is definitely less weird than f#

16:28 <discocaml> <limp.biskit> i guess thats the more or less but its definitely a big more or less

16:28 <discocaml> <limp.biskit> f# also sprinkles classes around stdlib and most libraries for c# compat

18:32 <discocaml> <akhilindurti> is there a nested fold in any of the ocaml stdlibs?

18:34 <discocaml> <contextfreebeer> like a fold inside of a fold?

18:34 <discocaml> <akhilindurti> like if i have two lists, and i want to compare each element of list 1 with each element of list 2 before putting it into the resultant list

18:35 <discocaml> <akhilindurti> yeah but i would just have to do something like `nested_fold list1 list2 fun el1 el2 acc -> ...`

18:35 <discocaml> <akhilindurti> so not a fold2, just to be clear

18:35 <discocaml> <akhilindurti> since that's pairwise and not quadratic

18:36 <discocaml> <contextfreebeer> `iter` allows you to get a cartesian product of two iterators, and you can then fold over an iterator of tuples, but I'm not totally sure what you want so maybe that won't work for you

18:36 <discocaml> <akhilindurti> basically i'm trying to union two lists

18:37 <discocaml> <contextfreebeer> oh, like a set union?

18:37 <discocaml> <akhilindurti> yeah, although i'd like to preserve order

18:37 <discocaml> <contextfreebeer> `CCList` from containers allows you to do that directly

18:38 <discocaml> <contextfreebeer> not sure if it preserves the order, I guess it should

18:38 <discocaml> <akhilindurti> oh it seems `base` also has a `Cartesian_product` module

18:39 <discocaml> <akhilindurti> i'll see if that works, since i'm using base rn

18:39 <discocaml> <akhilindurti> thanks!

19:17 <Anarchos> akhilindurti split/combine ?

19:47 <discocaml> <akhilindurti> my solution ended up being

19:47 <discocaml> <akhilindurti> ```ocaml

19:47 <discocaml> <akhilindurti> and union_rows env (row_a: record_ty) (row_b: record_ty) : record_ty =

19:47 <discocaml> <akhilindurti> List.dedup_and_sort (row_a @ row_b) ~compare:(fun (f1,t1) (f2,t2) ->

19:47 <discocaml> <akhilindurti> if f1 = f2 then (unify env t1 t2; 0)

19:47 <discocaml> <akhilindurti> else Poly.compare (f1,t1) (f2,t2))

19:47 <discocaml> <akhilindurti> ```

19:47 <discocaml> <akhilindurti> my solution ended up being to use `List.dedup_and_sort`