caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Ashish Agarwal <agarwal1975@gmail.com>
To: "Daniel Bünzli" <daniel.buenzli@erratique.ch>
Cc: caml list <caml-list@inria.fr>
Subject: Re: [Caml-list] SDL2 bindings, testers and feedback welcome
Date: Tue, 17 Dec 2013 12:05:00 -0500	[thread overview]
Message-ID: <CAMu2m2KyPwte=NP8wg9=33mnnVywfNKAnEWO_D2KtsqbDWihBg@mail.gmail.com> (raw)
In-Reply-To: <4DDEBB7487B641C0834F09D522EA9918@erratique.ch>

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

On Tue, Dec 17, 2013 at 1:11 AM, Daniel Bünzli
<daniel.buenzli@erratique.ch>wrote:

* I used an 'a result = [ `Error | `Ok of 'a ] rather than an exception
>

1. The `Error case doesn't give any information about what the error is, so
this is equivalent to 'a option. I recommend 'a option as a return type
only when there can be only a single error. For example, I think it's okay
for Map.find to return None since it clearly means the item was not found.

2. If you have `Error carry a value, you have Core's ('ok, 'err) Result.t
(ignoring for the moment that you have polymorphic variants, which is
good). Then the question becomes what will 'err be in each specific case.
The important criteria is that the types you choose must unify, or else it
will be very difficult to compose functions into bigger programs. One
option is to always make 'err = string. This is lightweight, let's you
provide informative messages, and simplifies your type to contain a single
type variable. This is similar to Core's Or_error, but instead of string,
they define Error.t which has some other benefits.

3. If you want to enable robust error handling, you get tempted to define
'err as a more specialized type. Adding the criteria that each instance of
'err must unify, you end up using polymorphic variants, e.g. `Error of [>
`not_found | `timed_out ]. We used this approach in some production code,
but I'm starting to feel it is not worth the hassle. It is very hard to
maintain.

4. So we're back to option 2, which doesn't allow robust error handling
because the error type isn't rich enough. Thus, the question is why is it
any better than raising exceptions. It is not making your code any safer
because you're forced to program monadically, where you systematically
ignore every error, just like if all your functions were raising
exceptions. In the end, the only difference between option 2 and
exception-ful style is that your type signature documents the possibility
of an error. It only says that "some" error occurs. You still have to
define what this error is about in your text documentation. In exchange for
this, you've complicated all of your type signatures and forced monadic
programming everywhere. In the end, raising exceptions seems fine to me.
You can define multiple exceptions to increase the chance that specific
errors can be handled when needed.

Disclaimer: my opinion about this changes every day.


Other comments:

* What is the T in Tsdl? I don't see any T on the SDL website.
* Your type `barray` would be better named `big_array`. In this case,
`bigarray` would also be okay since it would be consistent with the module
Bigarray to which this type refers.

I don't like random single letters in names, which is also a problem in
your Vg and Gg project names. Thanks for all your great libraries!

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

  parent reply	other threads:[~2013-12-17 17:05 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-17  6:11 Daniel Bünzli
2013-12-17  7:02 ` Anthony Tavener
2013-12-17 14:17 ` Florent Monnier
2013-12-17 15:14   ` Daniel Bünzli
2013-12-18  6:54   ` Erkki Seppala
2013-12-18  8:05     ` Anthony Tavener
2013-12-18  9:24       ` Daniel Bünzli
2013-12-18  8:18     ` Florent Monnier
2013-12-22 10:01       ` Kakadu
2013-12-30 13:28         ` Vu Ngoc San
2013-12-17 17:05 ` Ashish Agarwal [this message]
2013-12-17 17:47   ` Daniel Bünzli
2013-12-17 18:57     ` Ashish Agarwal
2013-12-17 19:45       ` Anthony Tavener
2013-12-18 15:40         ` Ashish Agarwal
2013-12-18 18:02           ` Yotam Barnoy
2013-12-18 19:53             ` Daniel Bünzli
2013-12-18 22:29               ` Ashish Agarwal
2013-12-18 22:45                 ` Daniel Bünzli
2013-12-17 20:26       ` Daniel Bünzli
2013-12-18  1:13         ` Francois Berenger
2013-12-18  6:44           ` Erkki Seppala
2013-12-18  9:21           ` Daniel Bünzli
2013-12-19  1:11             ` Florent Monnier
2013-12-19  6:39       ` Florent Monnier
2013-12-17 19:29     ` Erkki Seppala
2013-12-19  5:20 ` Florent Monnier
2013-12-19  5:27   ` Florent Monnier
2013-12-19  7:13   ` Daniel Bünzli
2013-12-19 12:38     ` Florent Monnier
2014-02-12 10:43 ` Daniel Bünzli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMu2m2KyPwte=NP8wg9=33mnnVywfNKAnEWO_D2KtsqbDWihBg@mail.gmail.com' \
    --to=agarwal1975@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=daniel.buenzli@erratique.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).