|
| From: | Maxime Devos |
| Subject: | RE: The Guile junk drawer and a C plea |
| Date: | Mon, 1 Jul 2024 11:06:47 +0200 |
Sent from Mail for Windows From: Dr. Arne Babenhauserheide >Maxime Devos <maximedevos@telenet.be> writes: >> No it doesn’t, because of _the version number_. If you put (6) next to >> the module name, that’s the _exact_ version number, it’s not ‘6 or >> later’ or ‘maybe 6 whatever’, it’s ‘exactly 6’. 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’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-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 combination here. It also probably does not, because ‘equal?’ 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 – so it doesn’t 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. This does not increase the testing area, because the testing area of (rnrs something (6)) is already infinite since it can’t care about which comparator in particular it is passed – 2*infinity = infinity for most notions of infinity. Since (rnrs something) can’t care about which comparator is used, it is redundant to test (rnrs something N) + [whatever equal?], it instead suffices to test (rnrs something N) and [whatever equal? + whatever hash] in isolation. There are situations where you can’t combine some things, this isn’t one of them. I also never claimed that versioning is a panacea. >> Also, what source maintenance? Software, that isn’t subject to changing external demands, doesn’t 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 breaking of update? As mentioned previously, there is no breaking on update 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 different 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 ‘take these binding from that module (vN), with those renamings’ (and the occasional ‘this binding >> was removed / has different arguments / ..., let’s provide a small wrapper). >I’m seeing 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 same situation. Rust comes with entire _multiple implementation versions_ of dependencies, I’m 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 on it) plenty of cases of multiple versions disappear and sometimes dependencies disappear. I’m not very familiar with Haskell packaging, but last time I did things with Haskell, I’m pretty sure I haven’t seen 500 MiB of ‘rename things’ 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’m 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’t really the case. Likewise, (rnrs ...) is pretty well-defined – there are some >> changes to RnRS stuff, but it’s mostly just additions, removals and reorderings – 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’s when you don’t actually need version numbers. And if you added them, you’d 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 ‘cons’ (R6RS) -> make-pair (R8RS) transition that keeps the module name. In this case, you definitely something equivalent to a version number. Also, no, you don’t need to update the library. That’s what the version number is for. Also, you don’t 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 bindings (and maybe the occasional wrapper for reordering arguments or whatever). In this case, the two versions are trivially compatible with each other because they are the same thing. >That’s 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 bunch of renamings, also changes the version number and under the old version number adds some bindings referring to the new names in the new version number). I guess this is technically a ‘load’, but the effort required is so minimal that this is hyperbole. >But when the culture shifts so people say “hey, we have versioned APIs now, let’s change everything around to fit this new style; it won’t break existing clients (until we remove the old version)” (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’s your problem, not mine. “let’s change everything + remove old version” is an entirely different situation from “do some reorganisation preserving semantics and only changing location/names + keep old version (referring to new version as a bunch of renamings)”. Someone else said to remove the old version, not me. Can you stop making strawmen and say what would be the problem with _renaming_/ _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’t conflate people with me. If other people do that, you need to take it up with them, not me, because I’m not one of them Regards, Maxime Devos |
| [Prev in Thread] | Current Thread | [Next in Thread] |