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 3DB787EC6E for ; Wed, 18 Dec 2013 02:13:15 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of berenger@riken.jp) identity=pra; client-ip=134.160.33.175; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of berenger@riken.jp designates 134.160.33.175 as permitted sender) identity=mailfrom; client-ip=134.160.33.175; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@postman.riken.jp designates 134.160.33.175 as permitted sender) identity=helo; client-ip=134.160.33.175; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="postmaster@postman.riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkBALf1sFKGoCGvnGdsb2JhbABZhxqyYoMHgTcOAQEBAQEICxIUKIIlAQEBBCMECwEFNgoRCxgCAgUWCwICCQMCAQIBRQYNCAEBiACwZJhsF4EpjQZqgm6BSAEDiUGOVYZFjwk X-IPAS-Result: AqkBALf1sFKGoCGvnGdsb2JhbABZhxqyYoMHgTcOAQEBAQEICxIUKIIlAQEBBCMECwEFNgoRCxgCAgUWCwICCQMCAQIBRQYNCAEBiACwZJhsF4EpjQZqgm6BSAEDiUGOVYZFjwk X-IronPort-AV: E=Sophos;i="4.95,504,1384297200"; d="scan'208";a="41497391" Received: from postman3.riken.jp (HELO postman.riken.jp) ([134.160.33.175]) by mail3-smtp-sop.national.inria.fr with ESMTP; 18 Dec 2013 02:13:12 +0100 Received: from postman.riken.jp (postman3.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id 3D3FB38380FB for ; Wed, 18 Dec 2013 10:13:09 +0900 (JST) Received: from [172.27.98.103] (rikad98.riken.jp [134.160.214.98]) by postman.riken.jp (Postfix) with ESMTPA id 1208638202BF for ; Wed, 18 Dec 2013 10:13:09 +0900 (JST) Message-ID: <52B0F6A5.9060605@riken.jp> Date: Wed, 18 Dec 2013 10:13:09 +0900 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: caml-list References: <4DDEBB7487B641C0834F09D522EA9918@erratique.ch> <1C9496037B6149EC970D65C3BFA490F7@erratique.ch> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.18.10315 Subject: Re: [Caml-list] SDL2 bindings, testers and feedback welcome On 12/18/2013 05:26 AM, Daniel Bünzli wrote: > Le mardi, 17 décembre 2013 à 19:57, Ashish Agarwal a écrit : >> The desire to distinguish between a successful non-result vs an error is reasonable, but it's hard to know where to draw the line. > > In that case the line is pretty clear, any function that may return an error about the call through Sdl.get_error gets that type. But regarding the overall discussion, for me it boils down to one of these choices: > > 1) Convert all error conditions to exceptions and say in the docs any function in the Sdl module may raise Sdl.Error > 2) Keep it as it is now. > >> Is it an error for Map.find to not find the item you asked for? Maybe. Maybe not. > > Actually this case is quite easy IMHO. When you devise a map data structure you should have both Map.get : 'a t -> key -> 'a, that raises *Invalid_argument* if the key is unbound (that's for code paths were you know the value is in there) and Map.find : 'a t -> key -> 'a option, that returns None if the key is unbound (that's for code paths were you don't know if the value is there). > >> I misspoke. What I meant is: I don't like short cryptic acronyms. They appear random to me because I don't know what they mean. > Ok then ! The thing is that when you use combinators approaches and/or get type errors you don't want to have long winded name prefixes. I think the name just after the prefix is more important and here I don't use short cryptic acronyms: Vg.image, Vg.glyph, Vg.path, Vg.renderer etc. Here is what I learned some time ago on this very same mailing-list; at the top of some .ml file: module Vg = Vector_graphics I _love_ it. -- Best regards, Francois Berenger.