From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) by sourceware.org (Postfix) with ESMTPS id 8413F3857C68 for ; Fri, 5 Feb 2021 22:03:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8413F3857C68 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bothner.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=per@bothner.com Received: from [10.9.9.72] (helo=submission01.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1l89CH-00044e-L3 for kawa@sourceware.org; Fri, 05 Feb 2021 23:03:25 +0100 Received: by submission01.runbox with esmtpsa [Authenticated alias (524175)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1l89C9-00056x-LX for kawa@sourceware.org; Fri, 05 Feb 2021 23:03:17 +0100 Subject: Re: SRFI inclusion To: kawa@sourceware.org References: From: Per Bothner Message-ID: <97fcf177-4168-b564-9ce3-32396986d5a1@bothner.com> Date: Fri, 5 Feb 2021 14:03:14 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: kawa@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Kawa mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 22:03:29 -0000 On 2/5/21 8:22 AM, Arvydas Silanskas via Kawa wrote: > Good evening, > > What is the process of deciding upon & including SRFIs in kawa? May I have > a go at implementing library-like SRFIs 27, 145, 158, 180, 189 and making > merge requests without a fear of objections about the choice of SRFI itself > (naturally objections over quality of implementation itself is another > deal)? My opinion - others are welcome to chime in: There are many SRFIs I think may be ill-considered: Primarily the shear number of them makes it impossible for anyone to grasp them all, or create a coherent vision of them. (To be fair even C++ and Java suffer from useful classes being designed in isolation from each other.) Secondarily, the number of container classes without any kind of inheritance or overloading. (For example draft SRFI 215 flexvector defines a useful data type and a useful set of functions for working with them. However, it's a new large set of functions, with no overlap with functions for working with plain vectors. At least there are some semi-standard naming conventions, but I think this approach of defining dozens of distinctly-named functions for each datatype is a dead end.) That said, the ones you mention seem (at a quick glance) small and standalone, and I don't see any problem including them as libraries. Including new names in the (kawa base) package is a much higher hurdle, of course. In terms of implementation, when a SRFI duplicates existing Kawa functionality (in terms of basic functionality, not necessarily every detail) I strongly prefer that it be implemented on top of Kawa functionality, especially any types that are introduced. For example new container types should if possible use an existing Kawa class, or should inherit from the appropriate existing classes/interfaces. -- --Per Bothner per@bothner.com http://per.bothner.com/