Maxime Devos <maximedevos@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.

I’m not saying that there shouldn’t be change, just that there shouldn’t
be *breaking* change.

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.

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.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de