02:50 <greenbagels> so reading ocaml tutorials and books a lot of resources seem to say things along the line of "classes / OOP / mutability / etc. have their place in ocaml, but many programmers find they dont need the features that much"

02:52 <greenbagels> i think im too worried about writing "unidomatic code" as a beginner; would multiple module functions neeeding access to some shared "state" variable be sufficient reason to want classes over something like submodules?

03:00 <d_bot> <Ambika E.> No

03:03 <d_bot> <Ambika E.> You can almost always just stick to modules, so don't worry too much about potentially missing the right opportunity to use the OO features

03:07 <gopiandcode> I'd say it's still idiomatic OCaml to have functions take a mutable state parameter as input - just make sure it's reflected appropriately in the type

03:08 <greenbagels> gopiandcode: right, that seemed like the only other sane choice

03:09 <greenbagels> the downside being that throwing mutable state between functions could be verbose to some i guess

03:10 <greenbagels> or exposing state to users that dont always need to know it i guess

03:12 <Corbin> Maybe you need less mutable state than you think.

03:38 <gopiandcode> mutability is somewhat contagious in some sense - unless the mutable state can be encapsulated within the local scopes of your library, the end users will always need to know that the mutability exists, and this should be exposed from the types I think

03:39 <gopiandcode> (I guess there are edge cases when this can be avoided (such as memoization that doesn't affect the functional correctness), but these are exceptions not the rule)

04:22 <greenbagels> i have issues trying to think of a way to avoid mutability in my case; it's a web client where each message from the server is tagged with an id, and a callback that sends keepalives (containing hte latest id received) sleep-waits using lwt

04:23 <greenbagels> so i either need to scrap the model im using entirely or have some way for this infinite recursion callback to communicate with the main handler for incoming data

05:02 <greenbagels> i will rethink the design; maybe i will tackle a bunch of simpler exercises and study some existing code before thinking about my problem some more

05:12 <d_bot> <nave01314> Why would multiple module functions requiring the same mutable state parameter be unidiomatic? For example, Map.find and Map.change both take the map as the first argument.

05:20 <greenbagels> im not saying its unidiomatic, im just wondering why something like using classes to handle mutable state / encapuslation is avoided so much

05:21 <greenbagels> but i guess you can still hide what you want from the user using just the module system; i'm also reading that ocaml's object oriented features are sometimes not super efficient?

10:29 <d_bot> <Bluddy> ocaml is a mostly functional language and mutable state is generally frowned upon

10:30 <d_bot> <Bluddy> classes and objects can be used immutably as well. it's just not so popular due to the fact that there are also performance issues with objects

10:30 <d_bot> <Bluddy> so you end up with a barely used OOP side, and when it's used, it's used for mutable data and only in very limited amounts

10:31 <d_bot> <leviroth> Nobody I know frowns upon mutable state. Where are you getting this generalization?

10:32 <d_bot> <Bluddy> that's the whole point of a functional language

10:32 <d_bot> <Bluddy> you try to avoid mutable state

10:32 <d_bot> <Bluddy> you use it when you need it, but otherwise try to avoid it

10:36 <d_bot> <undu> I tend to use immutable data structures, not having mutable state makes the code eeeasier to reason with

10:37 <d_bot> <undu> mutable state has to exist somewhere, but if i can avoid having mutable state in a module, I'll gladly go for it

10:38 <d_bot> <leviroth> The whole point of OCaml is that you try to avoid mutable state? Surely from another perspective, the point of OCaml is to provide quality functional idioms alongside mutability. And surely the point of OCaml also involves, say, modularity or the type system.

10:47 <d_bot> <Bluddy> OCaml is a functional language first and foremost. And functional languages concern themselves with immutable state. OCaml gives you an escape hatch to use mutable state when you need it (e.g. for performance), but functional paradigms (which heavily involve immutable state) are the focus. You can make a whole program with only mutable state and mutable variables everywhere, but at that point you may as well be using something els

10:49 <d_bot> <Bluddy> The type system also plays along with immutability. If you only use mutation, you'll be returning `unit` everywhere, which isn't very helpful in catching the bugs the type system is supposed to catch.

10:56 <octachron> The relative lack of optimisation for objects mostly matters if you have small method calls in hot loops.

10:57 <octachron> I would rather say that encapsulation and mutable state are already well handled by modules in many situation.

10:58 <octachron> Thus objects end up being the best fitting solution in few cases (for instance, open recursion or extensible data structure defined by their behavior).

11:22 <d_bot> <leviroth> @Bluddy it's certainly not true that mutation means your function must only return `unit`, and even if it were that doesn't mean that you can't benefit from the type system, e.g. in the arguments of the function.

11:22 <d_bot> <leviroth> But this all seems pretty far afield of the original context

11:23 <d_bot> <leviroth> Someone was writing a web client that has to keep track of state sent to it by the server, and they were concerned that it would be unidiomatic to use mutable state in this case.

11:24 <d_bot> <Bluddy> It is unidiomatic. But it may be necessary for performance reasons.

11:24 <d_bot> <leviroth> No, it's not!

11:24 <d_bot> <leviroth> It's just not true that it's unidiomatic to ever use mutable state in OCaml, except that you might have to sacrifice idioms for performance.

11:26 <d_bot> <leviroth> On the contrary it's often immensely painful to have to pass around different chunks of immutable data structures and make sure they are all updated in all the right places, when it's often simpler to just use a hashtable, or a record with mutable fields.

11:26 <d_bot> <Bluddy> there are algorithms that are simpler to implement with mutable state - this is true

11:26 <d_bot> <Bluddy> but the basic idiom is still to try use immutable state where you can

11:27 <d_bot> <leviroth> And I think it's deeply unhelpful when someone has questions about all this and instead of getting advice about the tradeoffs of mutable or immutable approaches for their particular use case, they're met with unsupported blanket assertions about how one approach is "generally frowned upon."

11:27 <d_bot> <Bluddy> just because it's frowned upon in a general sense doesn't mean it can't be useful in particular cases

11:28 <d_bot> <Bluddy> that's what the 'general' part means

11:28 <d_bot> <leviroth> Saying that you should use immutable state "where you can" is giving up the whole game since the question was about whether this *particular* case it's tractable to have an immutable design.

11:28 <d_bot> <Bluddy> do you understand what the word 'generally' means?

11:30 <d_bot> <leviroth> Of course I understand what the word generally means

11:39 <d_bot> <Bluddy> so I don't think there's a real disagreement here. There's a reason I said it's *generally* frowned upon.

11:41 <d_bot> <leviroth> Yes, there is a real disagreement: I think it's unhelpful to make that kind of generalization in the actual context of the conversation.

11:41 <gopiandcode> I wouldn't say the point of OCaml is to avoid mutable state

11:41 <gopiandcode> that would be closer to Haskell

11:42 <gopiandcode> OCaml is a language that allows you to use the best tool for the job

11:42 <gopiandcode> you can use functional code or imperative code depending on which is most appropriate for the problem

11:43 <gopiandcode> for example, a strict purist might avoid using any mutable state at all, and instead use the state monad

11:43 <gopiandcode> this will probably work to an extent, but I wouldn't call it idiomatic code

11:43 <gopiandcode> for one, it would probably be very painfully slow

11:44 <gopiandcode> instead, with OCaml, when the code seems like it makes use of a pervasive state, one can choose to make the state mutable rather than purely functional

11:44 <d_bot> <leviroth> And furthermore, I don't really agree that you should "generally" avoid mutable state for the reasons that gopiandcode is rehearsing right now.

12:15 <d_bot> <Bluddy> here is how the cornell textbook introduces ocaml

12:15 <d_bot> <Bluddy> https://cs3110.github.io/textbook/chapters/intro/present.html

12:27 <d_bot> <Bluddy> haskell avoids mutable state altogether. OCaml frowns on mutable state but accepts it where necessary, mostly for performance, but sometimes also for simplicity. If you show me an OCaml program that's packed with mutable state with no justification for it whatsoever (not performance, not anything), I would tell you it's not idiomatic and you should try to use at least some immutability to gain the benefits of functional programmin

12:27 <d_bot> <Bluddy> You could also program entirely with objects in OCaml and nothing else. Is it idiomatic? No. Is it possible? sure.

12:37 <d_bot> <leviroth> I don't think anyone in this conversation needs to be linked to the introduction of an OCaml textbook

12:38 <d_bot> <leviroth> gopiandcode and I aren't novice OCaml programmers needing basic instruction about what the language is like; we're experienced OCaml programmers whose experience doesn't gel with how you are characterizing the language.

12:39 <d_bot> <Bluddy> that's fine. we can agree to disagree.

12:39 <d_bot> <Bluddy> would you claim that objects everywhere is idiomatic to ocaml?

12:40 <d_bot> <leviroth> no

12:40 <d_bot> <Bluddy> why not?

12:40 <d_bot> <Bluddy> it's fully doable in the language

12:41 <qwr> i'm not sure that you are even disagreeing... it boil basically down to that its unidiomatic to use mutable state where immutable state would result in clearer/less error prone/easier to understand code...

12:45 <qwr> but it makes no sense either to complicate the code with emulating mutation in pure code, where simple ref or mutable field would do

12:46 <qwr> though sometimes it is hard to see alternative, easier solution if you already have one in your mind

12:48 <qwr> (like python programmer might not see how recursion + pattern matching would do, when he thinks about while loop)

12:55 <d_bot> <Bluddy> yep definitely agree with all of that

13:12 <d_bot> <darrenldl> greenbagels: id use hashtable for the mapping from id to states, and make the handler function itself pure ig

13:13 <d_bot> <orbitz> IMO it sounds like you guys are disagreeing on what "idiomatic" means

13:13 <d_bot> <darrenldl> mutable at outer layer is quite common afaik

13:22 <d_bot> <orbitz> There are clearly situtaions where the idiomatic solution to a problem in Ocaml is mutation. We have mutable types with stdlib: bytes, array, queue, hashtbl, bigarray. The Seq stuff requires mutation to accomplish anything as far as I can tell. So it might not be sufficient to say if mutable state in a language is idiomatic, but talk more about the particular scenario. Idiomatic network code is going to have a bunch of mutable

13:24 <d_bot> <Bluddy> so maybe you're right and it is about what idiomatic means.

13:25 <d_bot> <Bluddy> to me, even when you're making mutable code, you should be thinking: is it really important that this be mutable?

13:25 <d_bot> <Bluddy> because the default is immutability

13:25 <d_bot> <Bluddy> now again, this is a general approach, not a specific one

13:25 <d_bot> <Bluddy> it may very well be that given the domain, a mutable approach is best

13:27 <d_bot> <Bluddy> notice the asymmetry though: when writing immutable code, I'm not asking myself if I can write it with mutability

13:28 <d_bot> <Bluddy> I would only do that if certain constraints force me in that direction: either performance or the fact that the alternative mutable algorithm would be far more elegant

15:09 <qwr> accidental mutability usually makes it harder to reason about the code, in porpotion with globality of the mutability (guess why passing arguments in global variables is almost universally shunned)

16:47 <Corbin> Bluddy: I wonder to what degree this entire argument is about the definition of "functional language". My personal opinion is that it's hard to have a consistent definition of "functional language" which includes OCaml and Haskell but excludes Scheme and Python; as a result, we can't really say that functional languages are about mutability.

16:48 <Corbin> Actually, personally, I think "functional language" is a tribal marker. But we could still try to examine the point, which is that a (pure total) function doesn't have a concept of mutation.

16:50 <favonia> Hi all, I'm created the issue https://github.com/ocaml/ocaml/issues/11185 about embedding the unhandled effect in the exception Unhandled. As a programmer I felt the urge to give it a try. While this sounds like a trivial change, I need to hack the primitive 'caml_perform' written in assembly code. I wonder what would be a good resource for me to learn it if I want to?

16:51 <qwr> today most languages have incorporated parts allowing functional programming, so its now more whether it is comfortable to you use functional style (syntax, library) and whether such code is efficiently executed

16:52 <favonia> PS: not the assembly language itself---but the invariants (e.g., calling conventions) maintained by the current runtime system on *all* platforms. I felt I could easily violate some convention there.

16:54 <favonia> (I'm also happy if someone else would do it. It's probably too challenging for me haha.)

20:55 <d_bot> <rawburt> "haskell avoids mutable state altogether" is not a true statement. there are plenty of mutability solutions in haskell. the community trends towards functional state via monads, but there are plenty of mutability options in haskell (IORef, STRef, MVar, etc). i'm not sure if you can build a general purpose language and _not_ have some mutable primitive. even Koka built entirely around algebraic effects has a mutable ref

20:55 <d_bot> <orbitz> Those things are within a monad though

20:56 <d_bot> <orbitz> Happens to be a monad that's difficult to get out of

20:58 <d_bot> <rawburt> true true, good point

21:15 <Corbin> There exist non-functional Turing-complete languages without mutability; my favorite example is Wang tiling. Certainly, implementations of languages are going to tend towards mutability; it'd be a shame not to take advantage of mutable main memory.