From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lassi Kortela Newsgroups: gmane.lisp.guile.devel Subject: Re: Numbers in library names Date: Tue, 23 Jul 2024 19:12:16 +0300 Message-ID: <62ccedc7-3feb-471c-8b5d-0354569e00ec@lassi.io> References: <712b1502-6311-406a-b59a-7ec4dfe32c97@lassi.io> <5b3b9623-4b2b-42be-826d-e998a18b005f@lassi.io> <173e06e8-2ec3-461b-a1f7-43a3e78165aa@lassi.io> <20240723180101.r4112C0082kuPDg01411Xo@baptiste.telenet-ops.be> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25652"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Taylan Kammer , "guile-devel@gnu.org" , Arne Babenhauserheide To: Maxime Devos , =?UTF-8?Q?Marc_Nieper-Wi=C3=9Fkirchen?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Jul 23 18:12:51 2024 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sWI8B-0006Xo-F0 for guile-devel@m.gmane-mx.org; Tue, 23 Jul 2024 18:12:51 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sWI7r-0004cX-4X; Tue, 23 Jul 2024 12:12:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sWI7p-0004Xv-Qh for guile-devel@gnu.org; Tue, 23 Jul 2024 12:12:29 -0400 Original-Received: from mail-108-mta182.mxroute.com ([136.175.108.182]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sWI7n-0004na-HL for guile-devel@gnu.org; Tue, 23 Jul 2024 12:12:29 -0400 Original-Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta182.mxroute.com (ZoneMTA) with ESMTPSA id 190e05d7ccc00017a3.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 23 Jul 2024 16:12:21 +0000 X-Zone-Loop: 9bbfcb4869a37ad6a743aff6086fdf5ccc42e2f54618 X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lassi.io; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:Cc: To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=tYv22Bgyiw9jMbkmAEDWC+hNRL32IKUhkaSbiQ07w9k=; b=scvonv17YSn51a9H5Y4H2OR/3J HWtzURAeIwPo0dqyGqLWu4Vi5TIuARZsiWPZg4Ddmp5vLyL47OnavV8u/MfvzIizbNyRMcN9pmA/d 0y/wDjuYcqTNeSfs8iCeIlvkgfT1OphtEe9qZuDWkrTRSgvV5pxZOWH/KwPMyXMfU/BbId9K85rSQ 9LuNED20731yZXVRWTLhOPF+Qxu/NkvglqLpNHk5+2FgYM8W7Wj2o4gKj5D7S56EbxyQB9RbDzHJ7 zDT5ZfLgzg3Q+raM2FziyxiVyG3nZqgC3E1Nm6Z/rsTy/AELmSPcEPc0vugro3qBpNqiSyJb+oRpk amysVhRw==; Content-Language: en-US In-Reply-To: <20240723180101.r4112C0082kuPDg01411Xo@baptiste.telenet-ops.be> X-Authenticated-Id: lassi@lassi.io Received-SPF: pass client-ip=136.175.108.182; envelope-from=lassi@lassi.io; helo=mail-108-mta182.mxroute.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:22652 Archived-At: > I haven’t received the e-mail you are responding too (in particular, I > don’t know who you are responding to), but … I was talking to Marc; it seems there is a delay in list traffic. > As already has been answered: > > The practical harm is (srfi |1|) is non-standard, but it looks standard > because it contains ‘srfi’, so if someone were to type (srfi |1|) in > their Scheme implementation and it gets automatically mapped to (srfi > 1), then it appears to work, hence misleading the writer into thinking > that (srfi |1|) is standard. > > (For the same reason, Guile doing (srfi srfi-1) is problematic. It’s not > just there for compatibility, it’s the main way of importing SRFI things.) > > If (srfi |1|) were to be standardised via SRFI process or RnRS (maybe > implicitly as a ‘module names equality is to be done modulo > number/symbol conversions’ thing in a future R8RS), then (srfi |1|) > would be fine, but such a thing. Fair enough. Good points. I'm in favor of defining such a rule via SRFI and/or RnRS. > This has already been answered. > > The practical difference, IIUC, is that esoteric point (IIUC, different > lexical context stuff). If you misinterpret the esoteric stuff, then > your library/program/... might not work properly, which is a practical > concern. > > (More precisely: lexical context of library name not necessarily the > same as context of a name part.) The issue was whether to take the first part or the last part of the library name. (The spec would stipulate that this part has to be an identifier.) I ahve the impression that every part of the same name has an equally useful lexical context.