08:55 <discocaml> <xavierm02_> https://github.com/ocaml-multicore/eio/blob/main/doc/rationale.md#dynamic-dispatch

08:55 <discocaml> <xavierm02_> "However, in order for Eio to be widely accepted in the OCaml community, we no longer use of objects and instead use a pair of a value and a function for looking up interfaces."

08:55 <discocaml> <xavierm02_> Does someone know the details of why?

08:55 <discocaml> <xavierm02_> Something more detailed than https://github.com/ocaml-multicore/eio/pull/553

09:06 <Anarchos> what is the relation between OCaml and System F ?

09:15 <discocaml> <xavierm02_> Anarchos: OCaml has some of the polymorphism of System F. And there's a paper "F-ing modules" on the relation between ML modules and System Fomega

09:20 <Anarchos> i was struck of the similarities when discovering system F .

10:53 <discocaml> <reynir1396> @xavierm02_ I don't think there's much more to it than certain people not liking OCaml objects tbh

10:54 <Anarchos> i like objects but could never find a use case !

12:15 <discocaml> <dinosaure> First of all, you need to be aware that the OCaml team doesn't necessarily concentrate all its efforts on the object part of OCaml - mainly because there aren't many of them and time has to be well managed. OCaml's objects, while interesting, are also quite far away from what can be found in the Java or C++ world (and for good reason): this inevitably implies a re-learning when you come from these worlds. Finally, few people in the community

12:26 <adrien> dinosaure: your message was cut after "community"

12:27 <adrien> historically at least, you'd avoir objects when wanting your code to be widely adopted, but you could also make a higher-level API using objects

12:28 <adrien> it's difficult to make a good non-object API based on an object one while you can make a good object one based on a non-object API

12:29 <adrien> (partly due to these weird type errors you can get with objects)

12:58 <discocaml> <gooby_clown> The Eio switch from objects was, as far as I'm aware, a (selfish) push by Jane Street despite the fact they were arguably more straightforward as a solution than what is in use currently

12:59 <discocaml> <dinosaure> arf, discord :/ on my web client I have my full message

13:14 <discocaml> <ada2k> the funny thing, a lot of eio is now fairly simple redirects to method calls

13:15 <discocaml> <ada2k> which i can understand and have done because first class functions are useful, but i don’t think the motivation was to make it slightly easier to use iterators in specific situations

13:16 <discocaml> <ada2k> afaik the motivation was just to hide the object system, even when it’s being used in one of the few entirely ideal use cases for OOP, and much of the push was from JST due to just a silly culture around not using objects

13:17 <discocaml> <ada2k> i think jane street also avoids objects because they don’t play well with many of their compiler forks and optimisation projects. but, as much as i’d like faster objects, specialisation is more important for io calls than fast dispatch

13:18 <discocaml> <ada2k> i’ll continue to lightly rip off Eio’s original object design in my own code 😄

13:48 <companion_cube> I also use objects for io streams tbh

14:04 <discocaml> <gooby_clown> OCaml has an O for a reason, those who dogmatically avoid OOP should write Caml instead

14:05 <discocaml> <otini_> I am in favor of dropping the O 😂 (and keeping objects, I’m fine with them. Caml is just a nicer name)

14:06 <discocaml> <gooby_clown> You might have a point there

15:12 <discocaml> <deepspacejohn> maybe it could just be Irish, O'Caml.

15:38 <reynir> O no

15:58 <discocaml> <qrpnxz> @otini_ but then people may come to believe OCaml is subjective 😔

16:04 <discocaml> <emiletrotignon> The irony being that they are not really interested in eio anyways.

16:05 <Anarchos> emiletrotignon what is eio ?

16:07 <discocaml> <contificate> Yeah, and if objects are dropped entirely, the language would be lighter, so "Caml Light", and then any new special feature could make it "Caml Special Light" and so on

16:11 <discocaml> <emiletrotignon> its an async library for ocaml that uses effects. Others are lwt or async (from janestreet). Lwt and async are pre-effects library so they have a monadic interface.

17:10 <dh`> ...why would you use a monadic interface for something inherently nonmonadic

17:13 <discocaml> <contificate> well, monadic style is a generalisation of CPS, and so it's quite suitable for these kinds of things - if you naturally induce functional sequence points in your program, as in the case with an async/concurrency monad, the `k` you are forced to talk about can be rescheduled by some other event loop

17:15 <discocaml> <contificate> there are all kinds of poor explanations of monads and monadic style online

17:15 <discocaml> <contificate> but my general advice is to get somewhat familiar with basic programming in continuation passing style, and then you can derive many monads by factoring out certain casing logic

17:15 <discocaml> <contificate> like what is monadic bind for option types except some logic to case on dispatch of `k`, dependent on whether you have something or not

17:16 <discocaml> <contificate> the relation to CPS is obvious to most, but you can see it in the types, compare the type of `let f x k = k x;;` with `Option.bind;;`

17:17 <discocaml> <contificate> effects let you reify (delimited) continuations at runtime, in the form of referring to some fiber within the new segmented stack runtime, and so scalable concurrency across domains can use effects and not use monadic style

17:22 <dh`> ...are you seriously arguing that asynchronous, non-sequential operations are naturally sequential?

17:22 <discocaml> <contificate> have you read what I've said or not

17:23 <discocaml> <contificate> if you actively write a style of code that enforces functional sequentialisation, via continuations (as in CPS and monadic style)

17:23 <discocaml> <contificate> then what you can do when you'd otherwise block is not block, but package up `k` in your event loop, wait for the result to become avaialble as you switch and do something else, and then reinvoke `k` with the asynchronously computed value

17:24 <discocaml> <contificate> this is kind of how it works in most languages, actually - except managed runtimes tend to have ways to do this kind of packaging up of the execution context and continuation implicitly

17:25 <discocaml> <contificate> since we didn't have that kind of thing in OCaml, prior to version 5, people would use monads to achieve it in a fairly convenient manner

17:53 <discocaml> <emiletrotignon> i think the thing is that want to write them in a sequential way most of the time, and have the asynchronicity be done for you automatically.

17:54 <discocaml> <emiletrotignon> I think they provide extra functions, but you get very nice syntax with the monadic ones.

18:25 <discocaml> <gooby_clown> A whole program optimising compiler for the said language can be appropriately called Camlton