From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 2D3007F70F for ; Tue, 17 Dec 2013 18:05:23 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of agarwal1975@gmail.com) identity=pra; client-ip=209.85.216.171; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="agarwal1975@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of agarwal1975@gmail.com designates 209.85.216.171 as permitted sender) identity=mailfrom; client-ip=209.85.216.171; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="agarwal1975@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qc0-f171.google.com) identity=helo; client-ip=209.85.216.171; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="postmaster@mail-qc0-f171.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0DAH+DsFLRVdirlGdsb2JhbABZhBe4aIEXCBYOAQEBAQcLCwkSKoImAQEEQAEbHQEDDAYFCzsiAREBBQEcBhOHbwEDEaR/jFqDCY0tChknDWSGGhEBBQyPBgeENgSJQ45TkCcYKYR1Hg X-IPAS-Result: Ai0DAH+DsFLRVdirlGdsb2JhbABZhBe4aIEXCBYOAQEBAQcLCwkSKoImAQEEQAEbHQEDDAYFCzsiAREBBQEcBhOHbwEDEaR/jFqDCY0tChknDWSGGhEBBQyPBgeENgSJQ45TkCcYKYR1Hg X-IronPort-AV: E=Sophos;i="4.95,502,1384297200"; d="scan'208";a="41462418" Received: from mail-qc0-f171.google.com ([209.85.216.171]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 17 Dec 2013 18:05:22 +0100 Received: by mail-qc0-f171.google.com with SMTP id c9so5226012qcz.30 for ; Tue, 17 Dec 2013 09:05:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=S0M6ZEgVKxEuYeLcs4bSBknPAHcB0fu7t7iSFKfVmvk=; b=Af7e52BK5YWAE+jh0yt9B7k1bBqVwgyO/jRILDXL/17y0EBqe+vTT66YxtPow4fzLh +oGKdywkNUQd651elNoXOKYimtqKJcwTIR2UR3YzIvh1OtkVwHupOrP41pnHCgs4DSIh zCFiGJAAiyjm6XIB+gFpHOu2rpHSUgsYwPEKZs/GEh8jv2FbmOWDjJugX7gNi1ek3b3N HrVg5/vH4iZD0NTy/SzSIU2ca+YhHR2q+JYhknlZ+ja/Q0qZaNZP3ux9DJJ2v7KvjpxQ Xy8az1w9bTk7hVcO15l6LktGWUl1nx3ZIqXek12OXjAy9OSYrz2JXrvbw1iTxwcqPCKz 4yTw== X-Received: by 10.49.52.102 with SMTP id s6mr45127316qeo.60.1387299920961; Tue, 17 Dec 2013 09:05:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.8.8 with HTTP; Tue, 17 Dec 2013 09:05:00 -0800 (PST) In-Reply-To: <4DDEBB7487B641C0834F09D522EA9918@erratique.ch> References: <4DDEBB7487B641C0834F09D522EA9918@erratique.ch> From: Ashish Agarwal Date: Tue, 17 Dec 2013 12:05:00 -0500 Message-ID: To: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Cc: caml list Content-Type: multipart/alternative; boundary=047d7bea3996fc693004edbdeeda Subject: Re: [Caml-list] SDL2 bindings, testers and feedback welcome --047d7bea3996fc693004edbdeeda Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Dec 17, 2013 at 1:11 AM, Daniel B=FCnzli wrote: * I used an 'a result =3D [ `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 =3D 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! --047d7bea3996fc693004edbdeeda Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 17, 2013 at 1:11 AM, Daniel B=FCnzli <daniel.buenzli@er= ratique.ch> wrote:

* I used an 'a result =3D [ `Error | `Ok of 'a ] rather than an exc= eption

1. The `Error case doesn't g= ive 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 re= turn 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 polym= orphic variants, which is good). Then the question becomes what will 'e= rr be in each specific case. The important criteria is that the types you c= hoose must unify, or else it will be very difficult to compose functions in= to bigger programs. One option is to always make 'err =3D 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 b= enefits.

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 va= riants, e.g. `Error of [> `not_found | `timed_out ]. We used this approa= ch in some production code, but I'm starting to feel it is not worth th= e hassle. It is very hard to maintain.

4. So we're back to option 2, which doesn't all= ow 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 m= aking your code any safer because you're forced to program monadically,= where you systematically ignore every error, just like if all your functio= ns were raising exceptions. In the end, the only difference between option = 2 and exception-ful style is that your type signature documents the possibi= lity of an error. It only says that "some" error occurs. You stil= l have to define what this error is about in your text documentation. In ex= change for this, you've complicated all of your type signatures and for= ced monadic programming everywhere. In the end, raising exceptions seems fi= ne to me. You can define multiple exceptions to increase the chance that sp= ecific errors can be handled when needed.

Disclaimer: my opinion about this changes every day.


Other comments:

<= div>* 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 li= ke random single letters in names, which is also a problem in your Vg and G= g project names. Thanks for all your great libraries!
--047d7bea3996fc693004edbdeeda--