From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Dr. Arne Babenhauserheide" Newsgroups: gmane.lisp.guile.devel Subject: Re: The Guile junk drawer and a C plea Date: Mon, 01 Jul 2024 12:42:03 +0200 Message-ID: <87le2lo0lg.fsf@web.de> References: <20240629002027.13853-1-richard@freakingpenguin.com> <20240629124128.hNhS2C00S3x6CSs01NhTmA@xavier.telenet-ops.be> <20240630004113.hahD2C0053x6CSs01ahD20@andre.telenet-ops.be> <87plryq4yw.fsf@web.de> <20240630114503.hll22C00K3x6CSs01ll22i@xavier.telenet-ops.be> <878qympkhp.fsf@web.de> <20240701110648.i96m2C0051zp23j0196nPH@laurent.telenet-ops.be> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28719"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Philip McGrath , "mikael@djurfeldt.com" , "Thompson, David" , Richard Sent , guile-devel To: Maxime Devos Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Mon Jul 01 12:42:41 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 1sOEUZ-0007F7-Pn for guile-devel@m.gmane-mx.org; Mon, 01 Jul 2024 12:42:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOEUN-0005So-Fg; Mon, 01 Jul 2024 06:42:27 -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 1sOEUL-0005SU-NN for guile-devel@gnu.org; Mon, 01 Jul 2024 06:42:25 -0400 Original-Received: from mout.web.de ([212.227.15.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sOEUJ-0008PE-EB for guile-devel@gnu.org; Mon, 01 Jul 2024 06:42:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=web.de; s=s29768273; t=1719830528; x=1720435328; i=arne_bab@web.de; bh=8WD/wnXmRp6hL1iDzgCnOGTzLUVlkZmRAMxzZocDcLQ=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=M1qjoEtPFNth8ELl92A/1N8JODyOgHhnjLobQskoFmq32oy63vmbV58jmLN/cuqe JkDKFDUzUfu3PL7mS9RcLT+N+7Cov/ZpOonolu+AYT9LQe87deg5UeYLHz+H3tPo0 q0wqx11wPbA/lUN0Erl8gX4/n8f9gD4RurLGKn5l0gQEJR8L+jGZ5Pe1MEo232ilU /GCMjNbEeos5PZWbSqiussRNZA21CVsBzRwoC5w/DFB379Ek+xUsICmbLZPC7W8yQ k5DL4STO1fDAikFcBqgWp59Ldkj2eIJvIRWfFd0F0GspVFdiaDwADUCodLEwECUYC 8DnQnxVyRQll/nbITg== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Original-Received: from fluss ([84.165.21.10]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1Mt8kX-1s927N0KhF-010Hs7; Mon, 01 Jul 2024 12:42:08 +0200 In-Reply-To: <20240701110648.i96m2C0051zp23j0196nPH@laurent.telenet-ops.be> (Maxime Devos's message of "Mon, 1 Jul 2024 11:06:47 +0200") X-Provags-ID: V03:K1:Ll8C/syx4lHo0VzeEfzlZMQ7V0qC+8JUfPJRxHmA/AKOefjUHk2 3zqXA+qRvbVnEZ53HkHQH51EkRqIn3oixYE32m/xOjoVOFwGzs7ZslLnESAi2a047tC9KZc h0oANBlc5bN2/sKxU1FDmDkchDG9bKxMnFLtSBy+XlarqhC03Bjzg2mIhydy1BR7pBYjjUm uqXh5dfysSXHxa98MHXeQ== UI-OutboundReport: notjunk:1;M01:P0:D8o7RxikeiM=;0lHei+O/UZLViU0wFP4tlK1750a zM+Lfed/h/2O+nJenG2s7eucc0YqXyE3yID/HMexad6wmlsA7ud3eAInwGyIXLsUVBhbsWj2V cCasn6da8A4M2WLTuqLdPVMDifjZxnYYhglfQ+GJLP4XF3UHfdmC7R5Z4sw0b2RimjP9goBvx MbmHjVxJXJgIclY/tiR8/5wnWAYjHmPBnLLZ+JCCnW2qYupF5/Mr3UO5B1qFUl9hU9X4Ie34Y u0FMZSbqQGcS05Y/EYzOcfwWF0P35IYLOprY5+0SRXLzqJYJQQggNMaL4SPNt/lvOKlbc06/M 2bahoF2tTgpBGyS7GV2VGBSbPbtYSp2UVrobq1cq5m4+8J8cmku2jyrb5ZdIv4lgd3o1g17yM 5Rj42B1azRbvY7TNv1lliMhXezrPqx05O/NDhYJBWi/dGMJd9fIiWEZ3GpBapgvx9Z4EgFYXN ytb4i7YzLgAh+2X28yhUcTp0MyiV39ENwEW6u+sobC8VY+CiJ+m4GBkw6NXWRda8iOY+TnKPz UNrupAK18xx8CbGL8fT/CqgAL2LteacyH7uEist1uNnMF/ISWlqAVXJzvwy47Kbx/H8gyFb8D LJQXJT0VqpPAOlQJ4e80faX5TqHl1Ub5LvZiX/Nc340FvmeZkX/ZUEKHpnIbejkkv9+NkvbAq MzZ3w5eap481tGQ7vsNeql+k4rsCzWJPAsQKG6Bh0yZ4/JsgVWr1TMtav2rJpnnChqGJFn/Ra pySUhDewqWCr1kZbJpgH8OdWs8roq234USwOaxdzsOYUtI88Fgu6l+aMUv1ol6nB1sxz6SvE Received-SPF: pass client-ip=212.227.15.3; envelope-from=arne_bab@web.de; helo=mout.web.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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:22529 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Maxime Devos writes: >> But when the culture shifts so people say =E2=80=9Chey, we have versione= d APIs >> now, let=E2=80=99s change everything around to fit this new style; it wo= n=E2=80=99t >> break existing clients (until we remove the old version)=E2=80=9D (can y= ou say >> that you never saw people do that? I did see it), then it causes serious >> problems. > Someone else said to remove the old version, not me. It=E2=80=99s how this thread started, so that=E2=80=99s what I=E2=80=99m ta= lking about. I comment on the case without deleting them at the end. > It also probably does not, because =E2=80=98equal?=E2=80=99 from (rnrs ba= se (7)) would likewise be the same as (rnrs base (6)). > > Also, this is allowed, because (IIRC) (rnrs something (6)) has an API whe= re you specify _which_ hash and _which_ comparator =E2=80=93 so it doesn=E2= =80=99t care > which comparator and hash (as long as they are compatible with each other= and the comparator is, in fact, a comparator (reflexivity, > transitivity, symmetry)). In particular, it breaks nothing. It breaks nothing right now, because people took care to keep the semantics the same. They cared about backwards compatibility. But this is what changes if we use versions as reason to ignore backwards compatibility. > This does not increase the testing area, because the testing area of > (rnrs something (6)) is already infinite since it can=E2=80=99t care about > which comparator in particular it is passed =E2=80=93 2*infinity =3D infi= nity > for most notions of infinity. This is sophistry: leaving out that there are non-infinite parts of this infinity which are important to tested for most use-cases =E2=80=94 and that these non-infinite parts double. > I also never claimed that versioning is a panacea. Then I misunderstood you, because all I am doing is to warn, that versioning APIs to make big changes has drawbacks and risks a cultural shift towards breaking backwards compatibility. I=E2=80=99ve seen this with Python 3. It shows again with Rust. Scheme implementations have a pretty good history of backwards compatibility and making that worse is what I worry about. > Can you stop it with the strawmen? It=E2=80=99s only a strawman if it isn=E2=80=99t real. I am showing you examples where it leads when version numbers are treated as a free pass to break backwards compatibility. This is not a strawman, but the risk I see when a warning not to break backwards compatibility is answered with =E2=80=9Cwe need versions=E2=80=9D. >> That=E2=80=99s why I say that the load of backwards compatibility cannot= be >> removed: it can only be shifted on other people. > > This is false, you can also shift it on yourself (i.e. whoever does a bun= ch of renamings, also changes the version number and under the old > version number adds some bindings referring to the new names in the new v= ersion number). >=20 > I guess this is technically a =E2=80=98load=E2=80=99, but the effort requ= ired is so minimal that this is hyperbole. It sounds like this is the main point where our opinions differ. I do not consider this effort as minimal. It may look small with the first change, but it grows more than exponentially, because if you want to give a guarantee, every version has to be tested against every combination of already existing versions. > what would be the problem with _renaming_/ _relocating_ when the old name= s are still preserved? Off the cuff: You now have two sets of documentation to keep in sync (including tutorials that no longer match the best-practices), you must ensure that the implementations stay the same, you get code using mixed and matched module hierarchies, dependent parts can get imported with different names depending on which best-practices their authors followed. Best wishes, Arne =2D-=20 Unpolitisch sein hei=C3=9Ft politisch sein, ohne es zu merken. draketo.de --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJEBAEBCAAuFiEE801qEjXQSQPNItXAE++NRSQDw+sFAmaCh/wQHGFybmVfYmFi QHdlYi5kZQAKCRAT741FJAPD67pMD/91Ivb0+0qoEDE3ioN1920VTP8mXICVL7Qc 4OZMJwmR3jD6wAmVQPm/3OW4Cq9yIa7aMOFRdUJktlqTwCTvEMK875t90bizXs/5 M5pQaUFJAoQnuq37bfZNT4VHbDhLdtaAAdblNlJaqcyaunLkbmQ2N0+0b6JOJRd2 8EZ8U3MjeqiLloZEDnh5L6EfZQ204yUwlrBc9mAPRVoZV9ttuB9sJrz+a4ES8XkL 6qnXLLmTdMWEERowRFcxGtRD4h256gH3VKbnl5uNkVlE49rRt5dimDp7eUUlJWCS is1XtN9TDh10cLVP70cQkzgu0NDblR/58VlnflkyBJWGbFEmrdPq83s+Ej2kaYhN xWojWNjxQOGmZWf5/Q6PTSPO76w872QHS2c9SSQK6nPJi3KY77LyWFv4sv7uoDrP CCeZFyIMSmP4lSVapZvFe7ZPQUPspwZkYq1utpwrVmBRFpXPmg2TpI5igpRAjcW7 4xCFOWvMVDUesnfjiWTAzz5xNkd3kh9s5gtY13zw6uwwxDzRVgpO4FvntNcmQlZM Nw5VnLOPklmJow5HS8o4e/rbbGoWhxoYOAZ9pPh2wxbFTSd4gQczzwFyAzwjvB9V ZGn5jhyB+7Hrcd1GmIqXT7y331lSetuFVD6scR6hyQKFe86e4KMVc7knDvLu1vMM 2MPPSFsWZ4jEBAEBCAAuFiEE3Si95tmHXKvOSosd3M8NswvBBUgFAmaCh/8QHGFy bmVfYmFiQHdlYi5kZQAKCRDczw2zC8EFSI6IA/9rm7F0x57H8sjZ82KgSOAJlhBz abqNQQU9AjryAwkMTgm+0y2mx4e82O2wf2yumSpGyudASuPp7hvUuHnuRWmCl+fR +8+ZCCNKTyTGUNHo45JxkXhl5LlED7K3b6Lu7Fmod7LSf9AvyvRYSwBd1tj7jEE1 ESRKJkLhA8oXXK8yzg== =MYrP -----END PGP SIGNATURE----- --=-=-=--