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. > 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 -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de
signature.asc
Description: PGP signature