Am Mi., 14. Dez. 2022 um 10:05 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > The disadvantage of this approach is that you bind many identifiers in
> > your namespace.
>
> Matter of taste. It's unlikely that people need uppercase C identifiers
> for some other purpose. In any case, one can also do:
>
> (define errno/ENOENT 'ENOENT)

To make the language plus SRFI extensions more coherent, IMO, it makes
sense to use what's already there and standardized instead of
inventing a poor man's version of namespacing.

> ...
>
> > For a better approach (which should be promoted instead), see
> > `define-enumeration' in R6RS and SRFI 209.
>
> It's a bit unwieldy:
>
>  > (define-enumeration <errno>
>      (EPERM
>       ENOENT
>       ESRCH
>       EINTR
>       EIO
>       ENXIO
>       E2BIG
>       ENOEXEC
>       EBADF
>       ECHILD
>       EDEADLK
>       ENOMEM
>       EACCES
>       EFAULT)
>      errno)
>  > (errno ENOENT)
> #<enum-set>
>  > (enum-set->list (errno ENOENT))
> (ENOENT)

You don´t write (define-enumeration <errno> ...) but
(define-enumaration errno (EPERM ...) errno-set).

Then (errno EPERM) => 'EPERM (with compile-time checking whether EPERM
is allowed!) and (errno-set EPERM ECHILD) actually gives an enum set,
which can be useful when checking for more than one possible error
condition; use (enum-set-member? (errno EPERM) (errno-set EACCES EBLAH
EBLUBB)) for a fast comparison (based on bitwise arithmetic in
optimized implementations).

Marc

>
> You'd have to do something like this:
>  > (apply codeset-message 'errno (enum-set->list (errno ENOENT)))
>
> Would it be too much if the SRFI mandated (or recommended?) R6RS
> implementations to take single-member enum-sets in addition to symbols,
> and do an implicit enum-set->list?