>Maxime Devos <maximede...@telenet.be> writes: >> ``` >> #!r6rs >> (library (foo) >> (export foo) >> (import (rnrs base)) >> (define foo >> (cons 'a 1))) >> ``` > Here you are demonstrating how R6RS libraries have the _same_ problem. You > should at least have included a version number next to (rnrs > base). Who knows, maybe R8RS will rename ‘cons’ to ‘make-pair’?
>Keep in mind that adding a version number does not resolve backwards compatibility. It just moves it so source maintenance instead of package maintenance — and then adds more complexity in keeping the system compatible with different versions of itself. >You’ll then have to test every version of Scheme with every other version, else you get breakage the moment a library updates to a newer version of Scheme while another is still on the old version. 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.) 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. 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). >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, just replace ‘cons’ by ‘make-pair’ in Guile code and see what happens. I think it’s better though to preserve backwards compatibility, e.g. by implementing version number support for modules with a _well-defined_ API. Note the emphasis on _well-defined_ -- if some API (in terms of semantics and not just bikeshedding over naming and argument order) is just what we have currently instead of something that is expected to remain the same (except perhaps for pure additions), and hence could easily change in the future, then version numbers are just going to lead to new problems. 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. Best regards, Maxime Devos
