Well, we have the same constraint, as we are trying to write code, that is understandable by students, who may not know OCaml. However, we are also trying to enforce pure functional programming, that, we believe, teaches the right thinking and produces programs that are easier to understand. When you need to write system code or any code that deals with effects, monads become inevitable sooner or later unless you're willing to use the escape hatch of mutability. The monadic code usually scares people (and the Continuation monad usually scared even the bravest). However, there are ways to deal with it. You can use different syntax extensions, like the [ppx_let][1], that is very light, [ppx_monadic][2], that provides a real do-notation so that you can write your code in the true imperative style. You can even rely on camlp4 or camlp5 do provide you a full support for the do-notation. I, myself, do not really like the do-notation (even in Haskell, or F#) because I believe, that it hides the real notion of computation. So, we stick to the regular syntax of OCaml. I'm always explaining the concept of Monad using the imperative C-like language, by pointing that a monad is just a way to parametrize your semicolon operator. So the idea is not really from functional programming and should be understandable by someone who has only an imperative programming background. With all this said, I think, that your code should rely on exceptions, not the monads. Since libguestfs is totally imperative library, that deals with imperative primitives, using OCaml exceptions is a perfectly valid solution. You are already dealing with primitives that bear hidden effects, so your computations are not pure on the first hand, thus adding exceptions will not add anything more to it. The essence of each monad is the `run` function, that evaluates monadic operations (orders) and produces an explicit state. Since you can't really reify the run function in your case, using monads will only obscure things. To make the long story short, you should use monad only with pure code in cases when you can represent effects as an OCaml value. Mixing imperative code with monadic code is the worst thing one can imagine - as you will deal with wolves in lamb's skins, functions that pretend to be pure while in fact, they are inherently effectful. [1]: https://blog.janestreet.com/let-syntax-and-why-you-should-use-it/ [2]: https://bitbucket.org/camlspotter/ppx_monadic On Wed, Oct 25, 2017 at 10:52 AM, Richard W.M. Jones wrote: > On Wed, Oct 25, 2017 at 11:12:26AM +0200, Philippe Veber wrote: > > isn't that a context where error monads do a pretty decent job? > > > > check_some_problem () >>= fun () -> > > check_some_other_problem () >>= fun () -> > > expect_something () >>= fun something -> > > finally_do something > > Right, but the main problem with monads is they scare off ordinary > programmers :-/ > > When writing open source code in OCaml we have two -- conflicting -- > goals. Goal #1 is to write elegant, short, fast, safe code, and OCaml > really wins there. Goal #2 is to attract outside programmers to work > on the project, and that's pretty hard with OCaml code, but we manage > it. But it gets much much harder if we use any concept which strays > too far from imperative/C-like code. You will see if you look through > our codebase that it's pretty imperative and -- quite deliberately -- > avoids doing strange stuff with modules, functors or really anything > which is "excessively functional" (sorry for the loose term, but I > hope you know what I mean :-). > > However when I have the time after my current conference I will try > to rewrite the code I linked to with monads to see if I can make > something which is both simple and readable. > > Thanks, > > Rich. > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >