00:00 <discocaml> <Kali> yeah, i still use 4.14 since there's no reason for me to upgrade

00:06 <discocaml> <._null._> (The improvements to the compiler and the LSP ?)

00:09 <discocaml> <Kali> i do not use the lsp

00:09 <discocaml> <Kali> what is better about the compiler?

00:09 <discocaml> <Kali> i was under the impression that there was much higher memory usage due to effects support

00:09 <discocaml> <._null._> That I can notice, mostly error messages

00:09 <discocaml> <._null._> I'm not claiming anything about the compiled programs

00:11 <discocaml> <._null._> Has the crash with mutating fields in a when-clause been ported to 4.14 ? It's pretty irrelevant in real code, but it's a thing

00:11 <discocaml> <._null._> fix for the crash*

00:23 <discocaml> <deepspacejohn> The stdlib has had a bunch of little improvements

00:24 <discocaml> <._null._> Right, there's TRMC, dynarrays and all around more functions

00:53 <companion_cube> TRMC is a bigger deal than I initially thought, tbh

11:00 <discocaml> <uberpyro181> Hasn't there been an annotation around for that for a while now?

11:00 <discocaml> <uberpyro181> is TRMC automatic or something or is this more recent than i remember

12:19 <discocaml> <gooby_diatonic> I think he just dismissed it as irrelevant until now

12:26 <discocaml> <deepspacejohn> it was added to the compiler in 4.14 but the stdlib didn't start using it until after 5 or 5.1 I think.

20:42 <dh`> I am using 4.14 because (a) coq doesn't officially support 5 yet and (b) stdlib changes in Random mean that one project requires a flag day

20:43 <dh`> neither of which is a stopper exactly but they create inertia

20:44 <discocaml> <._null._> It's more like one feature of Rocq that few people use doesn't work in OCaml 5

20:55 <dh`> doesn't really matter what the issue is, just that it exists

20:56 <discocaml> <barconstruction> Today I learned about the nostdlib and nopervasives compiler flags. It made me realize you could do

20:56 <discocaml> <barconstruction> "Haskell in OCaml". Specifically what I mean by this is a guarantee that all IO operations are regulated through a monad. My idea is as follows: First create a library MyStdlib which is a shim over the original stdlib but with a more restrictive interface that doesn't expose IO stuff. Then develop all your code in library B which is all parametrized over an IO module exposing a monad interface. B exposes a single "main" lazy value at

21:01 <discocaml> <barconstruction> I don't know if flambda is sufficiently aggressive to remove the overhead of this stuff for typical IO operations.

21:11 <dh`> why would you _want_ to do that?

21:29 <discocaml> <Kali> i have thought about that before but never ended up doing it

21:29 <discocaml> <Kali> alternatively only permitting io operations as effects

21:30 <discocaml> <Kali> although the lack of effect information in types would make this idea less interesting

21:34 <discocaml> <barconstruction> I am teaching a friend OCaml and I've been gradually introducing more "functional" concepts over the course of 3 months or so. He is comfortable with List.map and pattern matching so I wanted to demonstrate sophisticated usage of higher order functions. We implemented the option monad and I showed him how this lets you avoid uncaught exceptions without adding too much boilerplate. Next I had him implement his own Lazy.t using a variant

21:42 <dh`> sure, but that's an exercise

21:46 <discocaml> <barconstruction> I answered your question.

22:14 <discocaml> <uberpyro181> implementing the IO monad sounds sort of dry and hard to motivate

22:14 <discocaml> <uberpyro181> I think the most important thing for newcomers to get used to is fold

22:14 <discocaml> <uberpyro181> especially `List.fold_left`

22:15 <discocaml> <uberpyro181> people from imperative paradigms have a reflex to reach for a `for` loop that is sort of difficult to break

22:16 <discocaml> <uberpyro181> for loops with accumulators in general can be simulated with folds

22:47 <discocaml> <contificate> I'd hit them with things like zippers, persistent data structures, accumulating closures, CPS (which should've came before monads), etc.

23:20 <discocaml> <uberpyro181> hi

23:20 <discocaml> <uberpyro181> yeah I think my university course focused on persistent data structures pretty hard early on, just to get used to mutable state

23:21 <discocaml> <uberpyro181> the second assignment had a game where a bunch of functions were `stuff -> state -> state` to get used to immutable state, then after that was implementing okasaki trees

23:21 <discocaml> <uberpyro181> the second or third assignment had a game where a bunch of functions were `stuff -> state -> state` to get used to immutable state, then after that was implementing okasaki trees

23:22 <discocaml> <uberpyro181> the second or third assignment had us implementing a game where a bunch of functions were `stuff -> state -> state` to get used to immutable state, then after that was implementing okasaki trees

23:24 <dh`> barconstruction: fair enough, I guess I meant something like "why would you want to do that for serious"

23:24 <dh`> (especially since haskell is available for exercises)

23:25 <companion_cube> Even if you want an IO monad, why would you ever make it lazy?

23:29 <discocaml> <yawaramin> referential transparency

23:56 <dh`> the laziness in haskell lets you write new control-flow operators, and that does have some value

23:56 <dh`> but, really, especially for exercises if you want haskell it's there