From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by c5ff346549e7 (Postfix) with ESMTPS id 91BC75D5 for ; Sun, 5 Apr 2020 11:36:14 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.72,347,1580770800"; d="scan'208";a="443883629" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 05 Apr 2020 13:36:11 +0200 Received: by sympa.inria.fr (Postfix, from userid 20132) id 7BB8D7F47B; Sun, 5 Apr 2020 13:36:11 +0200 (CEST) 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 275D57F345 for ; Sun, 5 Apr 2020 13:36:05 +0200 (CEST) X-IronPort-AV: E=Sophos;i="5.72,347,1580770800"; d="scan'208";a="443883591" Received: from bou78-2-82-240-46-163.fbx.proxad.net (HELO MP-41019.local) ([82.240.46.163]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 05 Apr 2020 13:35:39 +0200 To: Gabriel Scherer , =?UTF-8?Q?Arthur_Chargu=c3=a9raud?= Cc: caml users References: From: =?UTF-8?Q?Fran=c3=a7ois_Pottier?= Message-ID: <4a78a1d5-9156-b9d9-89db-8f051f069b51@inria.fr> Date: Sun, 5 Apr 2020 13:35:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] Announcing Sek, an efficient implementation of sequences Reply-To: =?UTF-8?Q?Fran=c3=a7ois_Pottier?= X-Loop: caml-list@inria.fr X-Sequence: 18084 Errors-to: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi Gabriel, Thanks for your remarks; I have made a few improvements to the documentation based on your remarks. In particular, the default value of T is currently 64. On 04/04/2020 15:17, Gabriel Scherer wrote: > 6. Your _and_clear specification avoids any undefined or > surprising/undocumented behavior in the case that happens, but it may still > hide my programming mistake. This is true. We debated various options (described in NOTES.md) but chose the version whose specification is simplest (no undefined behavior, no exception). Because we would prefer to avoid offering many variants of each operation, we will probably keep things this way. -- François Pottier francois.pottier@inria.fr http://cambium.inria.fr/~fpottier/