RE: The Guile junk drawer and a C plea

[Maxime Devos]

>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.

 

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