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: Portable code Date: Fri, 26 Jul 2024 12:21:30 +0300 Message-ID: <57ecaaca-21c2-4e74-bdcd-c6f5e3e08e2f@lassi.io> References: <20240629002027.13853-1-richard@freakingpenguin.com> <87h6co21qv.fsf@laura> <87r0bsxpoe.fsf@web.de> <4d9d9c2e-0830-4267-b8e5-1a50cb815508@msavoritias.me> <87a5ifyd0g.fsf@web.de> <20240719104617.pLmG2C00D4SnA1G01LmG1n@andre.telenet-ops.be> <87wmlgkyix.fsf@web.de> <15398dda-cb3e-4195-b2f8-263a59a73c68@lassi.io> <8734o4kte6.fsf@web.de> <4cc59aa4-755f-4dd3-a3b6-5d5d5edda053@lassi.io> <87plr8jcba.fsf@web.de> <4eb813c3-c7fb-4a5f-bb8e-0b026096beb9@lassi.io> <87le1wjal7.fsf@web.de> <0260814d-d129-460a-a30a-ba5ba29820fd@lassi.io> <87a5ibka4i.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19802"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Attila Lendvai , Maxime Devos , Greg Troxel , MSavoritias , "guile-devel@gnu.org" To: "Dr. Arne Babenhauserheide" Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Fri Jul 26 11:22:19 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 1sXH9X-0004zO-1l for guile-devel@m.gmane-mx.org; Fri, 26 Jul 2024 11:22:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sXH99-0007m3-Ct; Fri, 26 Jul 2024 05:21:55 -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 1sXH93-0007lh-Td for guile-devel@gnu.org; Fri, 26 Jul 2024 05:21:52 -0400 Original-Received: from mail-108-mta35.mxroute.com ([136.175.108.35]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sXH8y-0005SP-2H for guile-devel@gnu.org; Fri, 26 Jul 2024 05:21:46 -0400 Original-Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta35.mxroute.com (ZoneMTA) with ESMTPSA id 190ee587cc600017a3.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 26 Jul 2024 09:21:34 +0000 X-Zone-Loop: 3e8b215f06800dcd4a024362fad04200651a36b3fc33 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=IRCb9SL++om+byV6OIpYk0FzzMreWowaXx9T+ic95i0=; b=g4FEhvuMofipEbERmMW3yCbs6B yW9NDdxHEm1g+4+cRzd9LbU5BpS7rpn3unq2xmuUuhSUOdPvdxePbx1rgqWI6fHh9n4iI9hXX1VAk VzWPckeNYh7vZUHZwlIPctpX3H99UHF8sDCONIhHDEpOkQEvtkX2z/oMA3Nrhdz7veGfDxHgbR5+M mPsZyZmVxshaI8VBwdJm3lTwOd+YVnTQGZC3wxrVoy24zwToFF6KHvMLb7LQrG9k80O3PmOwFitfr ehOU7vq9l6spsQpeuEf0/ib7aoOtGuw7Lqy0MBJMthHnE+CDvMzaHVo0zcYmt3OnIPaYyidjvBQWS uJxQLSMA==; Content-Language: en-US In-Reply-To: <87a5ibka4i.fsf@web.de> X-Authenticated-Id: lassi@lassi.io Received-SPF: pass client-ip=136.175.108.35; envelope-from=lassi@lassi.io; helo=mail-108-mta35.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:22660 Archived-At: Arne wrote: >>> Would it be possible to start into that by creating prefixes for the >>> different package repositories? >>> (akkuscm ...) and (snow-fort ...) >> I advise against doing that, as the same package can be published to >> multiple repositories. > Would that be a problem? All it needs is a reference that reliably works > in Guile. The akku/snow-fort equivalent for srfi. I think it's not the best decomposition of the problem. At their core, Akku and Snow are package indexes. Pointers that say, "in order to obtain a copy of library X, use URL foo". At the source code level, a Scheme library does not care where its dependencies are obtained from. A particular version of a particular package should perhaps be identified by a cryptographic hash of its source code. And any place you can obtain a blob with that hash is fair game. This is the Git model. If we include the name of a package index in the library name, I think we're promoting package indexes too much. It's just not the right mental model, and that has secondary effects. > Maybe even something like the shims in the r7rs benchmarks: they have > preludes for the different schemes with which they can run the tests. > > Making a set of Guile preludes and for each package some info which > prelude is needed to run it could make the packages work out of the box > for many. And it could be generalized to many different Schemes. I recommend that each Scheme implementation natively support all the RnRS feature, and that the Scheme community come up with standard test suites for each RnRS edition. There is substantial work in this direction, IIRC championed by Will Clinger, but my memory is fuzzy. >>> (how do I find out whether they are portable? Do I have to try?) >> Last I checked, you just have to try. > Maybe we could start there for portability: create a list of packages > which work with Guile. Do you happen to have the start of such a list > from your testing? I haven't kept track of compatibility with any Scheme implementation. The general principle is (or should be) that each package is a collection of libraries; each library imports other libraries; and any Scheme implementation that can support those libraries can support the library that depends on them. Where this is not the case, IMHO time is better spent fixing that than manually keeping compatibility lists.