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 3F19B7EC6E for ; Tue, 17 Dec 2013 18:47:50 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of daniel.buenzli@erratique.ch) identity=pra; client-ip=74.55.86.74; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="daniel.buenzli@erratique.ch"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of daniel.buenzli@erratique.ch) identity=mailfrom; client-ip=74.55.86.74; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="daniel.buenzli@erratique.ch"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@smtp.webfaction.com) identity=helo; client-ip=74.55.86.74; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="postmaster@smtp.webfaction.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkBAPOMsFJKN1ZKnGdsb2JhbABZg0KDWLVngTUOAQEBAQEGDQkJFCiCJQEBAQMBI1YFCwsYAgIjAwICRgEQBhMIh3QIBAmweJhcF4Epi2+BRzMHgm41gRMEmUaEfheOew X-IPAS-Result: AmkBAPOMsFJKN1ZKnGdsb2JhbABZg0KDWLVngTUOAQEBAQEGDQkJFCiCJQEBAQMBI1YFCwsYAgIjAwICRgEQBhMIh3QIBAmweJhcF4Epi2+BRzMHgm41gRMEmUaEfheOew X-IronPort-AV: E=Sophos;i="4.95,502,1384297200"; d="scan'208";a="41468956" Received: from mail6.webfaction.com (HELO smtp.webfaction.com) ([74.55.86.74]) by mail3-smtp-sop.national.inria.fr with ESMTP; 17 Dec 2013 18:47:48 +0100 Received: from [172.20.10.2] (170-225.197-178.cust.bluewin.ch [178.197.225.170]) by smtp.webfaction.com (Postfix) with ESMTP id 795F72246485; Tue, 17 Dec 2013 17:47:46 +0000 (UTC) Date: Tue, 17 Dec 2013 18:47:42 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Ashish Agarwal Cc: caml list Message-ID: <1C9496037B6149EC970D65C3BFA490F7@erratique.ch> In-Reply-To: References: <4DDEBB7487B641C0834F09D522EA9918@erratique.ch> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [Caml-list] SDL2 bindings, testers and feedback welcome Le mardi, 17 d=C3=A9cembre 2013 =C3=A0 18:05, Ashish Agarwal a =C3=A9crit : > On Tue, Dec 17, 2013 at 1:11 AM, Daniel B=C3=BCnzli wrote: >=20=20 > > * I used an 'a result =3D [ `Error | `Ok of 'a ] rather than an excepti= on >=20=20 > 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. >=20=20 > 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 i= mportant 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 info= rmative messages, and simplifies your type to contain a single type variabl= e. This is similar to Core's Or_error, but instead of string, they define E= rror.t which has some other benefits. >=20=20 > 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, b= ut I'm starting to feel it is not worth the hassle. It is very hard to main= tain. >=20=20 > 4. So we're back to option 2, which doesn't allow robust error handling b= ecause the error type isn't rich enough. Thus, the question is why is it an= y better than raising exceptions. It is not making your code any safer beca= use you're forced to program monadically, where you systematically ignore e= very 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 tha= t "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 y= our 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. >=20=20 > Disclaimer: my opinion about this changes every day. A lot more can be said about that and it's highly independent from the sett= ing. However I think this discussion is mostly irrelevant here since we are= constrained by the loose design of the underlying library which, as I said= , doesn't differentiate/document enough its errors and provides them only a= s strings. So what I did is to return `Error whenever the function may retu= rn an error and the documentation indicates that Sdl.get_error () can be us= ed to get more information (they don't expose error codes). What I could ha= ve done though is to have that error message in the `Error case. As for usi= ng options instead of this result type I really want to be able to distingu= ish at the type level between the following two functions (see the correspo= nding C documentation): http://erratique.ch/software/tsdl/doc/Tsdl.Sdl.html#VALget_hint http://erratique.ch/software/tsdl/doc/Tsdl.Sdl.html#VALrw_from_file =20=20 > * What is the T in Tsdl? I don't see any T on the SDL website. Thin (bindings to) SDL. I could have used Sdl but I don't like to take owne= rship of toplevel names that are used in other settings. =20=20 >=20=20 > * Your type `barray` would be better named `big_array`. In this case, `bi= garray` would also be okay since it would be consistent with the module Big= array to which this type refers. Why not. Maybe I should prefer b_array which is used by Gg. =20=20 > I don't like random single letters in names, which is also a problem in y= our Vg and Gg project names. It's not random ! It's short cryptic acronyms. Vector graphics, geometry an= d graphics=E2=80=A6 =20=20 > Thanks for all your great libraries! You are welcome,=20=20 Daniel=20=20=20