>Maxime Devos <maximede...@telenet.be> writes: >>> I suggest that we design a new module hierarchy, introduce aliases for >>> module bindings, and still supply the old module hierarchy during a few >>> years for backward compatibility. >> Also, on deprecation and removal: just because you deprecate something, >> doesn’t mean it has to be removed. And just because something >> deprecated will be removed or because something is volatile, doesn’t mean it >> has to be an incompatible change! >Change can be done without breaking things, but that’s not what was proposed.
Unless you are referring to the ‘during a few years’ (and in particular, the implied ‘remove it afterwards’) or (*), I don’t follow – renaming things and keeping the old names available doesn’t break things. >I’m not saying that there shouldn’t be change, just that there shouldn’t be *breaking* change. What breaking change are you referring to? >And that a new hierarchy we define is not guaranteed to actually *stay* better. There would be errors, but different ones. We can only expect that the new one will be significantly better in case where either the computing environment changed substantially or where our knowledge and skill of how to define such a structure improved substantially. >Also take into account whether we can adapt third party tutorials. These are an often forgotten part of software and when they no longer work due to chages, this seriously hampers adoption. We don’t need to account for third party tutorials here, renaming things while keeping the old names available is a compatible change so third party tutorials remain valid (just a bit outdated in naming). >One such case was making modules declarative by default. This broke tutorials which described how to create a live-REPL for interactive game development. It cost me hours of time to find the cause. And then again when I worked on a system with only Guile 2.0 where that module-option #:declarative #f is illegal. The compatibility change for the REPL completely broke the code on that other system. And the deployment system had another Guile version again, causing more breakage. I am proposing a compatible change except for (*), not an incompatible change, but this is an example of an incompatible change instead of a compatible change, so this doesn’t seem an analogous situation unless this is about (*). (*) different default environment for “guile -l” and the like. And (*) can be resolved with some automatic warning messages – if things are in the (implicit) interaction environment and a binding could not be found, propose explicitly choosing (guile) as interaction environment). p.s. forgot to mention that (define-module ...) also has default environment and hence should also be adjusted to explicitly choose _which_ environment. Best regards, Maxime Devos
