Re: [Caml-list] What if exn was not an open type?

[Ivan Gotovchits <ivg@ieee.org>]

[-- Attachment #1: Type: text/plain, Size: 4053 bytes --]

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 <rich@annexia.org>
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
>

[-- Attachment #2: Type: text/html, Size: 5147 bytes --]