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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 6C17A7EFCD for ; Sat, 4 Oct 2014 16:57:18 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of marek@xivilization.net) identity=pra; client-ip=178.63.18.39; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="marek@xivilization.net"; x-sender="marek@xivilization.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.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=mail2-smtp-roc.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 (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@coaxial.xivilization.net) identity=helo; client-ip=178.63.18.39; receiver=mail2-smtp-roc.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: AhMGAEsKMFSyPxIn/2dsb2JhbABggw5TEQNEuB+TDYdJAgp7FgF7hAQBAQMBOgYBATcBBAsLDhMlDxI2BhOIKgMJDAEIqFKFegEFgQKICw2HGAERAgSOFB2CFAcuhB2PX4ZWhH2CEIdah1aGUYNlagWBAySBHgEBAQ X-IPAS-Result: AhMGAEsKMFSyPxIn/2dsb2JhbABggw5TEQNEuB+TDYdJAgp7FgF7hAQBAQMBOgYBATcBBAsLDhMlDxI2BhOIKgMJDAEIqFKFegEFgQKICw2HGAERAgSOFB2CFAcuhB2PX4ZWhH2CEIdah1aGUYNlagWBAySBHgEBAQ X-IronPort-AV: E=Sophos;i="5.04,653,1406584800"; d="scan'208";a="99383893" Received: from coaxial.xivilization.net ([178.63.18.39]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 04 Oct 2014 16:57:17 +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:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=8URJbkKuY36fPFT1b0f35xKANvvEQC0PVhA29Z+HRWA=; b=TsbgsoMDonFuym4GNU4ZVjanfLXrzYhCVwTuhMjLzqVGxuiPrkmt8nqApJFTzQifuXcSZUl+10FGNuwPvD+e0PaBLoDkPPtTloP932jxPD0UVcpd11NrY/rZCcxFQbdH; Received: from aftr-88-217-181-150.dynamic.mnet-online.de ([88.217.181.150] helo=localhost.localdomain) by coaxial.xivilization.net with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XaQlo-0006ov-EK; Sat, 04 Oct 2014 16:57:16 +0200 Date: Sat, 4 Oct 2014 16:54:58 +0200 From: Marek Kubica To: Malcolm Matalka Cc: Caml List Message-ID: <20141004165458.4efce446@xivilization.net> In-Reply-To: <87a95cklck.fsf@gmail.com> References: <20141004150511.7e8de126@xivilization.net> <87a95cklck.fsf@gmail.com> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] [ANN] slacko-0.9.0 Hello Malcolm, Thanks for looking into my code. On Sat, 04 Oct 2014 13:36:43 +0000 Malcolm Matalka wrote: > I would either change the 'apierror' type to normal variants, or > spread out the apierror to multiple types. Can every API function > really return every one of those errors? The value of polymorphic > variants is they are module, and you can share the constructors > across types. You're right, there is a common set of errors that most functions return and then there are some specific errors. Originally I didn't want to create such a huge type but have every function have its own polymorphic variants that apply to it, so users of the API know exactly what errors might be thrown and have to handle these. The huge type is a direct result of the "validate" function which tests all cases. I tried specifying a smaller subset of polymorphic variants, but the compiler always selected the full set. I don't know how to fix this, because on the one hand side I don't want to have a big monolithic error type but on the other hand, I don't want to duplicate a subset of the validate function in every function. Looking forward for ideas on how to solve this in a more elegant way. > I would also structure the API calls in terms of the Result.t type in > Core. Right now success is part of the error type. If I understand you correctly, this should do the trick with the current code: type result = Success of Yojson.Basic.json | Error of apierror For future releases I plan to replace the strings in the signatures with proper types (so, some "string" turn into a "token" types, others into timestamp types) and to process the resulting JSON into some more convenient data structures. But for now, I hope to get the error handling right and then build upon this. Thanks in advance! regards, Marek