From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Maxime Devos Newsgroups: gmane.lisp.guile.devel Subject: RE: The Guile junk drawer and a C plea Date: Mon, 1 Jul 2024 11:06:47 +0200 Message-ID: <20240701110648.i96m2C0051zp23j0196nPH@laurent.telenet-ops.be> 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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_0B521A5E-9B7B-4A67-9375-14FD2B9C7C92_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39800"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Philip McGrath , "mikael@djurfeldt.com" , "Thompson, David" , Richard Sent , guile-devel To: "Dr. Arne Babenhauserheide" Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Mon Jul 01 11:11:44 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 1sOD4Z-000A67-Nh for guile-devel@m.gmane-mx.org; Mon, 01 Jul 2024 11:11:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOD0R-0001Sb-DZ; Mon, 01 Jul 2024 05:07: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 1sOD02-0001Az-0A for guile-devel@gnu.org; Mon, 01 Jul 2024 05:07:05 -0400 Original-Received: from laurent.telenet-ops.be ([2a02:1800:110:4::f00:19]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sOCzv-0006Ed-7j for guile-devel@gnu.org; Mon, 01 Jul 2024 05:06:58 -0400 Original-Received: from [IPv6:2a02:1808:2:3933:c900:81d4:7da1:9dd8] ([IPv6:2a02:1808:2:3933:c900:81d4:7da1:9dd8]) by laurent.telenet-ops.be with bizsmtp id i96m2C0051zp23j0196nPH; Mon, 01 Jul 2024 11:06:48 +0200 Importance: normal X-Priority: 3 In-Reply-To: <878qympkhp.fsf@web.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=telenet.be; s=r24; t=1719824808; bh=JyFzfLu6qykNtjOsAkl9MkR8C4/5sWxV7lUwCGTPPMg=; h=To:Cc:From:Subject:Date:In-Reply-To:References; b=L5FXP8sWPAnP0TgsSzwRF+LofQ3t5HsR71OAd1c15XAQBFPcGlfayb7T4rJ/BS+x+ 25ZUdZh1KiOqBLXdfyL1Jz4sSdzhfiNc1AGSyk+ey1M337y4GbUO/4Nn+lIR21vphL DuMxX2y6S/1pgyV5ZWKH7/MFmA7vd6kPq82coq8R3ojJTylJqxpG0RhnUBwyOUAv42 UDDYOJ0myINGFYXXzOealkTdHMLOIc056aXjr0NrmpC7ho6ugAU1idY+FuOTGqeA0+ gnfvdi+T0kRJe7hgZrmgoZ+vo/xoF9zETSyyE6SjEry9NZ/ay7HFz7MpfdBX+MWt3f ExF8Sebhx3THQ== Received-SPF: pass client-ip=2a02:1800:110:4::f00:19; envelope-from=maximedevos@telenet.be; helo=laurent.telenet-ops.be 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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:22528 Archived-At: --_0B521A5E-9B7B-4A67-9375-14FD2B9C7C92_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Sent from Mail for Windows From: Dr. Arne Babenhauserheide Sent: Sunday, 30 June 2024 16:34 To: Maxime Devos Cc: Philip McGrath; mikael@djurfeldt.com; Thompson, David; Richard Sent; gu= ile-devel Subject: Re: The Guile junk drawer and a C plea >Maxime Devos writes: >> No it doesn=E2=80=99t, because of _the version number_. If you put (6) n= ext to >> the module name, that=E2=80=99s the _exact_ version number, it=E2=80=99s= not =E2=80=986 or >> later=E2=80=99 or =E2=80=98maybe 6 whatever=E2=80=99, it=E2=80=99s =E2= =80=98exactly 6=E2=80=99. You could load >> multiple versions of a module at the same time! (Not actually >> implemented currently, but it _could_ relatively easily be >> implemented.) > >Yes, that=E2=80=99s what I mean. > >And then I use a second library which gives me a comparator, so I pass >equal? from (rnrs base 7) to hash-table from (rnrs something 6). > >Either this is allowed, then I just doubled my testing area, or this >is forbidden, then programs break on update of a library and need to >update all their libraries to the new dependency version. It does not double the testing area, because there is only a single combina= tion here. It also probably does not, because =E2=80=98equal?=E2=80=99 from (rnrs base= (7)) would likewise be the same as (rnrs base (6)). Also, this is allowed, because (IIRC) (rnrs something (6)) has an API where= 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, tran= sitivity, symmetry)). In particular, it breaks nothing. 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 infinity for= most notions of infinity. Since (rnrs something) can=E2=80=99t care about = which comparator is used, it is redundant to test (rnrs something N) + [wha= tever equal?], it instead suffices to test (rnrs something N) and [whatever= equal? + whatever hash] in isolation.=20 There are situations where you can=E2=80=99t combine some things, this isn= =E2=80=99t one of them. I also never claimed that versioning is a panacea. >> Also, what source maintenance? Software, that isn=E2=80=99t subject to c= hanging external demands, doesn=E2=80=99t rot, and a _precise_ version numb= er >> is included which implies the lack of changing external demand. >I am writing about not breaking on update. What breaking of update? As mentioned previously, there is no breaking on u= pdate in the considered cases, and even if there were, there would still be= breaking on update if instead of a version number the module was given a d= ifferent name. At least the different version numbers give an indication of= what might potentially the cause of the update. >> In terms of implementation, realistically there would be a single module= version that contains the actual implementation, and various >> other version variants that only say =E2=80=98take these binding from th= at module (vN), with those renamings=E2=80=99 (and the occasional =E2=80=98= this binding >> was removed / has different arguments / ..., let=E2=80=99s provide a sma= ll wrapper). >I=E2=80=99m seeing in Guix how much more complex this approach makes packa= ging Haskell-programs. How Rust programs spawn 500 MiB of source-with-dependency for small features. This is not at all the same situation. Rust comes with entire _multiple imp= lementation versions_ of dependencies, I=E2=80=99m just talking about _rena= ming_ and basic wrappers. It also is a problem of cargo-build-system, if yo= u replace it by something saner (see mentions of antioxidant in guix-devel,= which was mostly complete (almost everything builds!) when I last posted a= n update on it) plenty of cases of multiple versions disappear and sometime= s dependencies disappear. I=E2=80=99m not very familiar with Haskell packaging, but last time I did t= hings with Haskell, I=E2=80=99m pretty sure I haven=E2=80=99t seen 500 MiB = of =E2=80=98rename things=E2=80=99 packages. Can you stop it with the strawmen? >>>You can use methods to shift the load of backwards compatibility to >>> different groups, but you cannot remove it. >> >> I=E2=80=99m pretty sure you can remove backwards compatibility > >You cannot remove *the load of backwards compatibility*. >> But in the case of _(guile)_, for most things in (guile) this isn=E2=80= =99t really the case. Likewise, (rnrs ...) is pretty well-defined =E2=80=93= there are some >> changes to RnRS stuff, but it=E2=80=99s mostly just additions, removals = and reorderings =E2=80=93 the semantics appear to have remained pretty much >> the same. >Yes, and that is how it should be. So why do you keep bringing up the strawman of changing semantics then? >It=E2=80=99s when you don=E2=80=99t actually need version numbers. And if = you added them, you=E2=80=99d still have to ensure compatibility between different versions, because libraries you use will have to be updated, even if your own code just keeps working. Please remember my example of a hypothetical =E2=80=98cons=E2=80=99 (R6RS) = -> make-pair (R8RS) transition that keeps the module name. In this case, yo= u definitely something equivalent to a version number. Also, no, you don=E2=80=99t need to update the library. That=E2=80=99s what= the version number is for. Also, you don=E2=80=99t need to ensure compatibility between different vers= ions, because in my proposal (contrary to what appears to be your strawman)= , the two different versions would be the same implementation, just with di= fferent names of bindings (and maybe the occasional wrapper for reordering = arguments or whatever). In this case, the two versions are trivially compat= ible with each other because they are the same thing. >That=E2=80=99s why I say that the load of backwards compatibility cannot b= e removed: it can only be shifted on other people. This is false, you can also shift it on yourself (i.e. whoever does a bunch= of renamings, also changes the version number and under the old version nu= mber adds some bindings referring to the new names in the new version numbe= r). I guess this is technically a =E2=80=98load=E2=80=99, but the effort requir= ed is so minimal that this is hyperbole. >But when the culture shifts so people say =E2=80=9Chey, we have versioned = APIs now, let=E2=80=99s change everything around to fit this new style; it won= =E2=80=99t break existing clients (until we remove the old version)=E2=80=9D (can you = say that you never saw people do that? I did see it), then it causes serious problems. If you are making up strawmen, that=E2=80=99s your problem, not mine. =E2=80=9Clet=E2=80=99s change everything + remove old version=E2=80=9D is a= n entirely different situation from =E2=80=9Cdo some reorganisation preser= ving semantics and only changing location/names + keep old version (referri= ng to new version as a bunch of renamings)=E2=80=9D. Someone else said to remove the old version, not me. Can you stop making strawmen and say what would be the problem with _renami= ng_/ _relocating_ when the old names are still preserved? > (can you say that you never saw people do that? I did see it) I can lie, yes. Also, don=E2=80=99t conflate people with me. If other peopl= e do that, you need to take it up with them, not me, because I=E2=80=99m no= t one of them Regards, Maxime Devos --_0B521A5E-9B7B-4A67-9375-14FD2B9C7C92_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

=  

 

Sent from = Mail for Windows

 

From: Dr. Arne Babenhause= rheide
Sent: Sunday, 30 June 2024 16:34
To: Maxime Devos
Cc: Philip McGrath; mikael@djurfeldt.com; Thompson, David; Richard Sent; guile-de= vel
Subject: Re: The Guile junk drawer and a C plea

=

 

>Maxime D= evos <maximedevos@telenet.be> writes:

>>= ; No it doesn=E2=80=99t, because of _the version number_. If you put (6) ne= xt to

>> the module name, that=E2=80=99s the = _exact_ version number, it=E2=80=99s not =E2=80=986 or

>> later=E2=80=99 or =E2=80=98maybe 6 whatever=E2=80=99, it=E2=80= =99s =E2=80=98exactly 6=E2=80=99. You could load

&g= t;> multiple versions of a module at the same time! (Not actually

>> implemented currently, but it _could_ relatively= easily be

>> implemented.)

> 

>Yes, that=E2=80=99= s what I mean.

> 

>And then I use a second library which gives me a comparator, = so I pass

>equal? from (rnrs base 7) to hash-tab= le from (rnrs something 6).

> 

>Either this is allowed, then I just doubled my t= esting area, or this

>is forbidden, then program= s break on update of a library and need to

>upda= te all their libraries to the new dependency version.

 

It does not double the testing= area, because there is only a single combination here.

It also probably does not, because =E2=80=98equal?=E2=80=99 from (rnrs= base (7)) would likewise be the same as (rnrs base (6)).

 

Also, this is allowed, bec= ause (IIRC) (rnrs something (6)) has an API where you specify _which= _ hash and _which_ comparator =E2=80=93 so it doesn=E2=80=99t care w= hich comparator and hash (as long as they are compatible with each other an= d the comparator is, in fact, a comparator (reflexivity, transitivity, symm= etry)). In particular, it breaks nothing.

&nbs= p;

This does not increase the testing area, b= ecause the testing area of (rnrs something (6)) is already infinite since i= t can=E2=80=99t care about which comparator in particular it is passed =E2= =80=93 2*infinity =3D infinity for most notions of infinity. Since (rnrs so= mething) can=E2=80=99t care about which comparator is used, it is redundant= to test (rnrs something N) + [whatever equal?], it instead suffices to tes= t (rnrs something N) and [whatever equal? + whatever hash] in isolation.

 

There are = situations where you can=E2=80=99t combine some things, this isn=E2=80=99t = one of them.

 

I also never claimed that versioning is a panacea.

 

>> Also, what source ma= intenance? Software, that isn=E2=80=99t subject to changing external demand= s, doesn=E2=80=99t rot, and a _precise_ version number

>> is included which implies the lack of changing external demand= .

>I am writing about not breaking on update.

 

What breaki= ng of update? As mentioned previously, there is no breaking on update in th= e considered cases, and even if there were, there would still be breaking o= n update if instead of a version number the module was given a different na= me. At least the different version numbers give an indication of what might= potentially the cause of the update.

 

>> In terms of implementation, realistic= ally there would be a single module version that contains the actual implem= entation, and various

>> other version varian= ts that only say =E2=80=98take these binding from that module (vN), with th= ose renamings=E2=80=99 (and the occasional =E2=80=98this binding

>> was removed / has different arguments / ..., let=E2= =80=99s provide a small wrapper).

>I=E2=80=99m s= eeing in Guix how much more complex this approach makes packaging

Haskell-programs. How Rust programs spawn 500 MiB of

source-with-dependency for small features.

 

This is not at all the s= ame situation. Rust comes with entire _multiple implementation versions<= /i>_ of dependencies, I=E2=80=99m just talking about _renaming_ and = basic wrappers. It also is a problem of cargo-build-system, if you replace = it by something saner (see mentions of antioxidant in guix-devel, which was= mostly complete (almost everything builds!) when I last posted an update o= n it) plenty of cases of multiple versions disappear and sometimes dependen= cies disappear.

 

I=E2=80=99m not very familiar with Haskell packaging, but last time = I did things with Haskell, I=E2=80=99m pretty sure I haven=E2=80=99t seen 5= 00 MiB of =E2=80=98rename things=E2=80=99 packages.

 

Can you stop it with the strawme= n?

 

>&g= t;>You can use methods to shift the load of backwards compatibility to

>>> different groups, but you cannot remove= it.

>> 

>> I=E2=80=99m pretty sure you can remove backwards compatibility=

> 

>= You cannot remove *the load of backwards compatibility*.

 

>> But in the case of= _(guile)_, for most things in (guile) this isn=E2=80=99t really the case. = Likewise, (rnrs ...) is pretty well-defined =E2=80=93 there are some

>> changes to RnRS stuff, but it=E2=80=99s mostly j= ust additions, removals and reorderings =E2=80=93 the semantics appear to h= ave remained pretty much

>> the same.

>Yes, and that is how it should be.

 

So why do you keep bringing = up the strawman of changing semantics then?

&n= bsp;

>It=E2=80=99s when you don=E2=80=99t = actually need version numbers. And if you added

the= m, you=E2=80=99d still have to ensure compatibility between different

versions, because libraries you use will have to be upda= ted, even if

your own code just keeps working.

<= p class=3DMsoNormal> 

Please rememb= er my example of a hypothetical =E2=80=98cons=E2=80=99 (R6RS) -> make-pa= ir (R8RS) transition that keeps the module name. In this case, you definite= ly something equivalent to a version number.

&= nbsp;

Also, no, you don=E2=80=99t need to upd= ate the library. That=E2=80=99s what the version number is for.

 

Also, you don=E2=80= =99t need to ensure compatibility between different versions, because in my= proposal (contrary to what appears to be your strawman), the two different= versions would be the same implementation, just with different names of bi= ndings (and maybe the occasional wrapper for reordering arguments or whatev= er). In this case, the two versions are trivially compatible with each othe= r because they are the same thing.

 

>That=E2=80=99s why I say that the load of bac= kwards compatibility cannot be

removed: it can only= be shifted on other people.

 

<= p class=3DMsoNormal>This is false, you can also shift it on yourself (i.e. = whoever does a bunch of renamings, also changes the version number and unde= r the old version number adds some bindings referring to the new names in t= he new version number).

 

I guess this is technically a =E2=80=98load=E2=80=99, but th= e effort required is so minimal that this is hyperbole.

 

>But when the culture shi= fts so people say =E2=80=9Chey, we have versioned APIs

now, let=E2=80=99s change everything around to fit this new style; it w= on=E2=80=99t

break existing clients (until we remov= e the old version)=E2=80=9D (can you say

that you n= ever saw people do that? I did see it), then it causes serious

problems.

 

If you are making up strawmen, that=E2=80=99s your problem, n= ot mine.

 

= =E2=80=9Clet=E2=80=99s change everything + remove old version=E2=80=9D is a= n entirely different situation from =C2=A0=E2=80=9Cdo some reorganisation p= reserving semantics and only changing location/names + keep old version (re= ferring to new version as a bunch of renamings)=E2=80=9D.

 

Someone else said to remov= e the old version, not me.

 

Can you stop making strawmen and say what would be the pr= oblem with _renaming_/ _relocating_ when the old names are st= ill preserved?

 

> (can you say that you never saw people do that? I did see it)

 

I can lie, = yes. Also, don=E2=80=99t conflate people with me. If other people do that, = you need to take it up with them, not me, because I=E2=80=99m not one of th= em

 

Regard= s,

Maxime Devos

= --_0B521A5E-9B7B-4A67-9375-14FD2B9C7C92_--