Dr. Arne Babenhauserheide kirjoitti 17.7.2024 klo 13.45:
Olivier Dion <olivier.d...@polymtl.ca> writes:
On Sat, 29 Jun 2024, Mikael Djurfeldt <mik...@djurfeldt.com> wrote:
[...]
As has been spoken about here previously, 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.
In the name of discoverability for new users, this must be done.
Aliasing (ice-9 *) to (guile *) for avoiding the "what's that none
standard ice-9 library?".
I remember wondering about that exactly once; never forgot the name
afterwards.
As long as ice-9 is kept, I would not mind an alias, but as long as
deprecation is on the table, I do object, because subsequent removal
would break a lot of working code and working tutorials.
Working code that needs no maintenance and would likely not receive any,
so it would just get broken and stay broken, driving people away from
Guile.
I mean deprecation doesn't mean it has to be removed immediately.
There will be some time before it is actually removed. We can even push
it to Guile 4.
Given a long timeline i doubt older programs would be advised to be used
or even work with recent guile. Given the rest of the cleaning
discussion and any other breaking changes that is.
Also (srfi srfi-N) with something meaninful
for humans that don't want to lookup srfi.schemers.org or keep a
cheatsheet on their desk. e.g., (srfi srfi-1) => (srfi list) or
something like that.
SRFI already suggests optional names, but you can use any name:
(import (srfi :1)) ;; works
(import (srfi :1 lists)) ;; works
(import (srfi :1 awesome-feature)) ;; also works, but maybe should warn
Though this is not supported by use-modules (yet?):
(use-modules (srfi srfi-1)) ;; works
(use-modules (srfi srfi-1 lists)) ;; error
(use-modules (srfi :1)) ;; error
(use-modules (srfi :1 lists)) ;; error
The correct step™ there would be to validate the name used in import
after the number against a list of accepted names.
If we were to use (srfi list), this would break the possibility to have
another srfi for lists (which is why SRFI does not do that).
Best wishes,
Arne
