Maxime Devos <maximede...@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. > 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. > 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. >>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. 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. That’s why I say that the load of backwards compatibility cannot be removed: it can only be shifted on other people. 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. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de
signature.asc
Description: PGP signature
