Re: The Guile junk drawer and a C plea

[Dr. Arne Babenhauserheide]

Olivier Dion <olivier.dion@polymtl.ca> writes:

> On Sat, 29 Jun 2024, Mikael Djurfeldt <mikael@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