From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 71FBC7F02D for ; Mon, 20 Oct 2014 23:50:59 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of marek@xivilization.net) identity=pra; client-ip=178.63.18.39; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="marek@xivilization.net"; x-sender="marek@xivilization.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of marek@xivilization.net designates 178.63.18.39 as permitted sender) identity=mailfrom; client-ip=178.63.18.39; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="marek@xivilization.net"; x-sender="marek@xivilization.net"; 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@coaxial.xivilization.net) identity=helo; client-ip=178.63.18.39; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="marek@xivilization.net"; x-sender="postmaster@coaxial.xivilization.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoHAOmCRVSyPxIn/2dsb2JhbABcgw5TEQNEujWRf4dbgQkWAX2EQwYBAQUgEzs0iSQBCK9nhXoBBS9TjnUCBI96dBiEHY9qhmKHEoExg0aCbUCNf4N5agGBBgEeBoEfAQEB X-IPAS-Result: AjoHAOmCRVSyPxIn/2dsb2JhbABcgw5TEQNEujWRf4dbgQkWAX2EQwYBAQUgEzs0iSQBCK9nhXoBBS9TjnUCBI96dBiEHY9qhmKHEoExg0aCbUCNf4N5agGBBgEeBoEfAQEB X-IronPort-AV: E=Sophos;i="5.04,758,1406584800"; d="scan'208";a="84000258" Received: from coaxial.xivilization.net ([178.63.18.39]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 20 Oct 2014 23:50:58 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xivilization.net; s=xiv; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=5bYd8cepj+Ar1JE6E13vUXQCyy3KAfl9tlHkwAxsLCk=; b=qT8Sx1sOmTk5A8fn8Yrv9z90z7zyRhaGjw8Y0xwmT70gj018BwKUlGTvUrdg6ch6LG2ShoaT6vazbUdwRtOOMgw3o7K5kOPiu9L2gP/H4D03qALvyZ35T3asx/YIkLa1; Received: from aftr-88-217-180-41.dynamic.mnet-online.de ([88.217.180.41] helo=localhost.localdomain) by coaxial.xivilization.net with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XgKqv-0003GP-2J for caml-list@inria.fr; Mon, 20 Oct 2014 23:50:57 +0200 Date: Mon, 20 Oct 2014 23:48:13 +0200 From: Marek Kubica To: caml-list@inria.fr Message-ID: <20141020234813.0d35e543@xivilization.net> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.25; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Caml-list] [ANN] slacko 0.10.0 Hello, I'd like to announce a new release of Slacko, the OCaml Slack API binding. This is both an announcement as well as a request for comments regarding the API. The homepage is at , the documentation can be read online at and the tarball as well as release notes can be found on . The recommended way is to install it from OPAM of course, which already carries the 0.10.0 release. I've listened to the suggestions by Malcolm, Gabriel and Jaques as well as Drup so the methods are not longer "stringly" typed, each function supports parameters that make more sense, like user/group/channel types, booleans, integers etc. The results are changed from a huge monolithic type to individual polymorphic variants composed of smaller types. But some questions remain: I have a number of types and conversion functions (foo_of_string mostly). These can validate the input (checking if the format is correct or whether the input is not too long) and most likely should. But what is the preferred OCaml way of handling failure to convert? I could use exceptions but that seems kinda type unsafe to me. I could use option types, but that might make for some clunky conversions. Any ideas? Also there are errors like `Msg_too_long. I'm currently exposing them, because the API might throw them. But when doing validation inside my binding, these errors can't really happen, since I validated beforehand. I think that these can be filtered out (since the length limit is static and if it changes, the library can be updated), but if anyone has a different perspective, please speak up. Looking forwards to comments! Oh and I ported from the Camlp4 Lwt macros to PPX. Was super easy and worked like a charm, zero issues. regards, Marek