using an SRFI that is not available in Guile

using an SRFI that is not available in Guile

[Attila Lendvai]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

dear Guixers,

when working on the (gnu services configuration) module, i would like to use srfi-189, which is not available in Guile (https://srfi.schemers.org/srfi-189/srfi-189.html).

is there any way to add it, or an already established custom for such a situation? e.g. adding the .scm file to Guix, preferrably late in the load order, until Guile catches up and shadows it with its own?

- attila
PGP: 5D5F 45C7 DFCD 0A39

[-- Attachment #2: Type: text/html, Size: 1234 bytes --]

Re: using an SRFI that is not available in Guile

[Attila Lendvai]

i did a quick experiment: created the srfi/ dir in guix's root dir,
downloaded the .scm file from the srfi's git repo, and added a module
definition to it. it seems to work as expected.

so, technically it seems to be doable. but would a patch that adds it
to Guix get accepted?

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Knowledge will forever govern ignorance: And a people who mean to be their own Governors, must arm themselves with the power which knowledge gives.”
	— James Madison (1751–1836), 'Epilogue: Securing the Republic' (1822)

Re: using an SRFI that is not available in Guile

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]

Attila Lendvai schreef op wo 12-01-2022 om 16:46 [+0000]:
> dear Guixers,
> 
> when working on the (gnu services configuration) module, i would like
> to use srfi-189, which is not available in Guile
> (https://srfi.schemers.org/srfi-189/srfi-189.html).
> 
> is there any way to add it, or an already established custom for such
> a situation? e.g. adding the .scm file to Guix, preferrably late in
> the load order, until Guile catches up and shadows it with its own?

Instead of bundling it in Guix (which would prevent Guix from being
packaged in Guix, due to point 8 in (guix)Submitting Patches), how
about making it a package available for anyone (not only Guix)?

Have a look at the Guix packages guile-srfi-89/145/158/159/180.

Basically, SRFIs can be implemented like any other module in Guile
and don't have a special status in Guile (except for cond-expand and
some special syntax for importing SRFI modules -- maybe in 'library',
not sure where exactly).

FWIW I don't think there is any need for Guile to ship an
implementation for all SRFIs by itself when they can be implemented as
separate libraries that can be installed with
$FAVOURITE_PACKAGE_MANAGER.

If at some point an implementation of the SRFI is moved into Guile,
then the package definition of guile-srfi-NNN can be removed from Guix
and guile-srfi-NNN can be removed from package inputs.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: using an SRFI that is not available in Guile

[Attila Lendvai]

[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]

thank you Maxime!

with your guidance, i have managed to add guile-srfi-189 next to the other guile-srfi-NNN packages in guile-xyz.scm (a slightly tested diff is attached).

but when i grep for how these guile-srfi-NNN packages are actually used within guix, then i don't see any hits unfortunately.

i tried the following to do a quick test of my new package:

$ ./pre-inst-env guix shell guile-srfi-189
$ ./pre-inst-env guix repl
scheme@(guix-user)> ,use (srfi srfi-189)
While executing meta-command:
no code for module (srfi srfi-189)

how do i introduce it into the guix codebase, without breaking e.g. bootstrappability?

i guess i need to add it as an input and a propagated-input to the guix package in package-management.scm? and then progress a kind of bootstrap stage/step, so that i can then `#:use-module (srfi srfi-189)` it in configuration.scm?

probably by recording the new input as a commit, and then guix pull'ing it into my user's profile? and only after that can i start using it within the guix codebase?

if that is the case, then is there a simpler/shorter way to test my new guile-srfi-189 package before i go through all this dance?

pointers to readings are also welcome.

or alternatively, if it's really this complicated, then i'd welcome if someone more experienced "documented" the process in the form of git commits... ;)

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Lenin was certainly right. There is no subtler, no surer means of overturning the existing basis of society than to debauch the currency. The process engages all the hidden forces of economic law on the side of destruction, and does it in a manner which not one man in a million is able to diagnose.”
	— John Maynard Keynes (1883–1946), 'The Economic Consequences of the Peace' (1919)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-guile-srfi-189.patch --]
[-- Type: text/x-patch; name=0001-Add-guile-srfi-189.patch, Size: 2667 bytes --]

From 6960b5ef6de9a90726c9aa0c13d9e864cc83cd6d Mon Sep 17 00:00:00 2001
From: Attila Lendvai <attila@lendvai.name>
Date: Wed, 12 Jan 2022 19:57:32 +0100
Subject: [PATCH] Add guile-srfi-189.

* gnu/packages/guile-xyz.scm (guile-srfi-189): New variable.
---
 gnu/packages/guile-xyz.scm | 46 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/gnu/packages/guile-xyz.scm b/gnu/packages/guile-xyz.scm
index 74567830e6..9568055af6 100644
--- a/gnu/packages/guile-xyz.scm
+++ b/gnu/packages/guile-xyz.scm
@@ -3173,6 +3173,52 @@ (define-public guile-srfi-180
 API.")
       (license license:expat))))
 
+(define-public guile-srfi-189
+  (let ((commit "a0e3786702956c9e510d92746474ac988c2010ec")
+        (revision "0"))
+    (package
+      (name "guile-srfi-189")
+      (version (git-version "0" revision commit))
+      (source
+       (origin
+         (method git-fetch)
+         (uri (git-reference
+               ;; This is a fork of:
+               ;; (url "https://github.com/scheme-requests-for-implementation/srfi-189")
+               ;; Upstream merge requested at:
+               ;; https://github.com/scheme-requests-for-implementation/srfi-189/pull/21
+               ;; TODO switch over to the official repo when the PR gets merged
+               (url "https://github.com/attila-lendvai-patches/srfi-189")
+               (commit commit)))
+         (sha256
+          (base32
+           "0iqv4sjwbp4k87r9l9abzbs5yjcljm69m91kb1ypb03b0rx7napy"))
+         (modules '((guix build utils)))
+         (snippet
+          '(begin
+             (delete-file "test-syntax.scm")
+             (delete-file "test.scm")
+             #t))
+         (file-name (git-file-name name version))))
+      (build-system guile-build-system)
+      (arguments
+       '(#:not-compiled-file-regexp "srfi/189\\.scm$"))
+      (native-inputs
+       (list guile-3.0))
+      (propagated-inputs
+       (list guile-srfi-145))
+      (home-page "https://srfi.schemers.org/srfi-189/")
+      (synopsis "Scheme SRFI implementation of Maybe and Either")
+      (description
+       "This SRFI defines two disjoint immutable container types known as
+Maybe and Either, both of which can contain objects collectively known
+as their payload.  A Maybe object is either a Just object or the unique
+object Nothing (which has no payload); an Either object is either a Right
+object or a Left object.  Maybe represents the concept of optional values;
+Either represents the concept of values which are either correct (Right)
+or errors (Left).")
+      (license license:expat))))
+
 (define-public emacsy
   (package
     (name "emacsy")
-- 
2.34.0

Re: using an SRFI that is not available in Guile

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 3608 bytes --]

Attila Lendvai schreef op do 13-01-2022 om 09:55 [+0000]:
> thank you Maxime!
> 
> with your guidance, i have managed to add guile-srfi-189 next to
> the other guile-srfi-NNN packages in guile-xyz.scm (a slightly tested
> diff is attached).
> 
> but when i grep for how these guile-srfi-NNN packages are actually used
> within guix, then i don't see any hits unfortunately.
> 
> i tried the following to do a quick test of my new package:
> 
> $ ./pre-inst-env guix shell guile-srfi-189
> $ ./pre-inst-env guix repl
> scheme@(guix-user)> ,use (srfi srfi-189)
> While executing meta-command:
> no code for module (srfi srfi-189)

Using the guile REPL is a little less complicated than the guix repl,
I would recommend trying
"./pre-inst-env guix shell guile-srfi-189 -- guile" first.

> 
> how do i introduce it into the guix codebase, without breaking e.g. bootstrappability?

Take a look at ‘2.2  Requirements’ in the manual:
at least for now, I would recommend that the SRFI is kept optional
(using #:autoload and the like) and only required when doing Guix
System things, to help people bootstrapping Guix from a foreign distro
(without the binary installation, albeit with the bootstrap seeds).

See <https://issues.guix.gnu.org/52742> for how guile-lzma was added as
dependency, or see 67bf61255414115ffae0141df9dd3623bc742bff for
guile-disarchive.

For bootstrappability, you might have to define a copy of
guile-srfi-189 in build-aux/build-self, as done for guile-gcrypt.
Whether this is necessary or not depends on where srfi-189 is used. 
IIUC, if it is needed to compute the derivation of the guix package,
then it is, but otherwise, it is not.  Because it is only used in (gnu
services ...) and not, say, (guix packages), I don't think is
necessary.

However, it would be best to check.  E.g. you could commit the
guile-srfi-189 package definition and your changes to (gnu services ...),
then do

$ guix time-machine --commit=a-commit-from-before-the-srfi-was-packages -- time-machine --disable-authentication --url=/the/checkout --commit=the-commit-in-the-checkout --version

i guess i need to add it as an input and a propagated-input to the
> guix package in package-management.scm? and then progress a kind of
> bootstrap stage/step, so that i can then `#:use-module (srfi srfi-189)`
> it in configuration.scm?

Adding to both inputs and propagated-inputs doesn't have any additional
effect, adding it to propagated-input should be sufficient.

probably by recording the new input as a commit, and then guix pull'ing
> it into my user's profile? and only after that can i start using it within
> the guix codebase?

(FWIW, ~/.guix-profile and ~/.config/guix/current are different profiles)

Personally I wouldn't clutter ~/.config/guix/current with changes
to a local checkout and I would use "guix time-machine" or "guix pull --root=..."
instead, but that's a possibility.

Because guile-srfi-189 is not yet among the inputs,
you will have to do "guix shell -D guix guile-srfi-189" instead
of "guix shell -D guix" to set up a development environment.

That won't work yet because the SRFI isn't upstream yet,
but that can be circumvented with '-e ((@ (guix packages package) (name ...) ...)'.

if that is the case, then is there a simpler/shorter way to test my new
> guile-srfi-189 package before i go through all this dance?

FWIW I think it's easiest to first package the SRFI, submit it
and wait for the patch to be merged.  Adding new inputs to Guix
is complicated enough as-is.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: using an SRFI that is not available in Guile

[Attila Lendvai]

> Using the guile REPL is a little less complicated than the guix repl,
> I would recommend trying
>
> "./pre-inst-env guix shell guile-srfi-189 -- guile" first.

no luck with this either:

$ ./pre-inst-env guix build guile-srfi-189
/gnu/store/cy1mdr82i8dcj5435hnckibfqks3jmny-guile-srfi-189-0-0.a0e3786
$ ll /gnu/store/cy1mdr82i8dcj5435hnckibfqks3jmny-guile-srfi-189-0-0.a0e3786/lib/guile/3.0/site-ccache/srfi/
total 336
-r--r--r-- 2 root root 343525 Jan  1  1970 srfi-189.go
$ ./pre-inst-env guix shell guile-srfi-189 -- guile
GNU Guile 3.0.7
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> ,use (srfi srfi-189)
While executing meta-command:
no code for module (srfi srfi-189)
scheme@(guile-user)>


> Maybe do "guix build guile-srfi-189" to determine if srfi/189.sld
> is actually compiled to .../srfi/srfi-189.go?


when i try to build the vanilla srfi repo, then the .sld file is
ignored, and no .go file is produced at all. there's this, though:

https://lists.gnu.org/archive/html/info-gnu/2020-03/msg00005.html

```
** R7RS support recognizes the '.sld' extension

The '.sld' is what the R7RS suggests as a source file name extension.
It is now recognized when running "guile --r7rs", as well as
the '.guile.sld' extension.
```

but i guess i can't just compile one lib with --r7rs, and assume the
.go file can be loaded into a guile started without --r7rs, or can i?

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“It is a miracle that curiosity survives formal education. It is a very grave mistake to think that the enjoyment of seeing and searching can be promoted by means of coercion and a sense of duty.”
	— Albert Einstein (1879–1955), 'Autobiographical Notes' (1949), slightly paraphrased

Re: using an SRFI that is not available in Guile

[Attila Lendvai]

> no luck with this either:
>
> $ ./pre-inst-env guix shell guile-srfi-189 -- guile
> GNU Guile 3.0.7
> Copyright (C) 1995-2021 Free Software Foundation, Inc.
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type` ,show c' for details.
> Enter `,help' for help.
> scheme@(guile-user)> ,use (srfi srfi-189)
> While executing meta-command:
> no code for module (srfi srfi-189)
> scheme@(guile-user)>


hrm, it's not working for the preexisting srfi's either:

$ ./pre-inst-env guix shell guile-srfi-145 -- guile
scheme@(guile-user)> ,use (srfi srfi-145)
While executing meta-command:
no code for module (srfi srfi-145)

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The mice which helplessly find themselves between the cats teeth acquire no merit from their enforced sacrifice.”
	— Mahatma Gandhi (1869–1948)

Re: using an SRFI that is not available in Guile

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

Attila Lendvai schreef op do 13-01-2022 om 18:20 [+0000]:
> > Using the guile REPL is a little less complicated than the guix
> > repl,
> > I would recommend trying
> > 
> > "./pre-inst-env guix shell guile-srfi-189 -- guile" first.
> 
> no luck with this either:
> 
> $ ./pre-inst-env guix build guile-srfi-189

I forgot to include "guile" ("guix shell" needs that to know
"GUILE_LOAD{,_COMPILED}_PATH"), try

./pre-inst-env guix shell guile guile-srfi-189 -- guile

instead.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: using an SRFI that is not available in Guile

[Attila Lendvai]

> I forgot to include "guile" ("guix shell" needs that to know
> "GUILE_LOAD{,_COMPILED}_PATH"), try
>
> ./pre-inst-env guix shell guile guile-srfi-189 -- guile


that this works indeed, thanks!

i have sent the guile-srfi-189 patch as:

https://issues.guix.gnu.org/53317

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Without self knowledge, without understanding the working and functions of his machine, man cannot be free, he cannot govern himself and he will always remain a slave.”
	— George Ivanovich Gurdjieff (1877–1949)

Re: using an SRFI that is not available in Guile

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

Hi,

Attila Lendvai schreef op do 13-01-2022 om 09:55 [+0000]:
> +      (arguments
> +       '(#:not-compiled-file-regexp "srfi/189\\.scm$"))

Maybe do "guix build guile-srfi-189" to determine if srfi/189.sld
is actually compiled to .../srfi/srfi-189.go?

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: using an SRFI that is not available in Guile

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

Maxime Devos schreef op do 13-01-2022 om 11:53 [+0100]:
> Hi,
> 
> Attila Lendvai schreef op do 13-01-2022 om 09:55 [+0000]:
> > +      (arguments
> > +       '(#:not-compiled-file-regexp "srfi/189\\.scm$"))
> 
> Maybe do "guix build guile-srfi-189" to determine if srfi/189.sld
> is actually compiled to .../srfi/srfi-189.go?

Nevermind, I looked at the 'master' branch instead of the 'guile'
branch.  Would still be a good check though.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: using an SRFI that is not available in Guile

[Ludovic Courtès]

Hi,

Attila Lendvai <attila@lendvai.name> skribis:

> when working on the (gnu services configuration) module, i would like
> to use srfi-189, which is not available in Guile
> (https://srfi.schemers.org/srfi-189/srfi-189.html).

In addition to what Maxime wrote, I’d like to comment on the less
technical side of it.  I think it’s important to keep the code
consistent in terms of API usage.

There are often many different ways to do the same thing in Guile and
Scheme, but within Guix, settling on one (or two) ways for a given
things is preferable: it makes it easier for us all to understand and
maintain the code.

There’s no widespread “Maybe” idiom in Scheme; or rather, people use
TYPE | #f as a way to approximate “Maybe”.  It’s not ideal, primarily
because appropriate handling is not statically checked.  Yet, that’s
what we have and I’m not convinced adding SRFI-189 to the mix would
bring enough of an improvement to justify it.

Thoughts?

Thanks,
Ludo’.

Re: using an SRFI that is not available in Guile

[Attila Lendvai]

> There’s no widespread “Maybe” idiom in Scheme; or rather, people use
> TYPE | #f as a way to approximate “Maybe”. It’s not ideal, primarily
> because appropriate handling is not statically checked. Yet, that’s
> what we have and I’m not convinced adding SRFI-189 to the mix would
> bring enough of an improvement to justify it.
>
> Thoughts?


configurations are full of boolean fields, where #f is a valid value.

to represent unset fields, we would essentially need to implement half
of srfi-189 (Maybe and Nothing), and in a potentially buggy way
(e.g. using a symbol like 'disabled to represent an unset field value
(i.e. the current solution) clashes with a field type of symbol?).

i don't think it's worth rolling our own when an srfi covers what we
need.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Go find yourself first, so you can find me.”
	— Rumi (1207–1273)

Re: using an SRFI that is not available in Guile

[Ludovic Courtès]

Attila Lendvai <attila@lendvai.name> skribis:

>> There’s no widespread “Maybe” idiom in Scheme; or rather, people use
>> TYPE | #f as a way to approximate “Maybe”. It’s not ideal, primarily
>> because appropriate handling is not statically checked. Yet, that’s
>> what we have and I’m not convinced adding SRFI-189 to the mix would
>> bring enough of an improvement to justify it.
>>
>> Thoughts?
>
>
> configurations are full of boolean fields, where #f is a valid value.
>
> to represent unset fields, we would essentially need to implement half
> of srfi-189 (Maybe and Nothing), and in a potentially buggy way
> (e.g. using a symbol like 'disabled to represent an unset field value
> (i.e. the current solution) clashes with a field type of symbol?).

How about using ‘*unspecified*’ in those cases?

Out of curiosity, in what case do you need to represent “unset fields”?
I think in most or all of the existing configs, fields always have a
default value, there’s no “unset” state.

Thanks,
Ludo’.

Re: using an SRFI that is not available in Guile

[Attila Lendvai]

> How about using ‘*unspecified*’ in those cases?


hrm, that looks interesting, thanks! i'll try using that first. it's
Guile-specific, but then most of the rest of Guix is...


> Out of curiosity, in what case do you need to represent “unset fields”?


i think an example works better here: consider Swarm, a p2p storage
solution. its node implementation is called Bee. bees can join
swarms. there are some well-known swarms: 'testnet' and 'mainnet'.

when someone specifies the swarm field as a symbol naming one of the
well-known swarms, then some other mandatory fields should default to
the appropriate values derived from it, *and* the service should warn
if those fields are also set by the user.

and when one is joining a custom swarm, as per giving a string name in
the swarm field, then the service should warn when these mandatory
fields are not explicitly specified.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“We read the world wrong and say that it deceives us.”
	— Rabindranath Thakur, aka Tagore (1861–1941)

Re: using an SRFI that is not available in Guile

[Ludovic Courtès]

Hi,

Attila Lendvai <attila@lendvai.name> skribis:

>> Out of curiosity, in what case do you need to represent “unset fields”?
>
>
> i think an example works better here: consider Swarm, a p2p storage
> solution. its node implementation is called Bee. bees can join
> swarms. there are some well-known swarms: 'testnet' and 'mainnet'.
>
> when someone specifies the swarm field as a symbol naming one of the
> well-known swarms, then some other mandatory fields should default to
> the appropriate values derived from it, *and* the service should warn
> if those fields are also set by the user.
>
> and when one is joining a custom swarm, as per giving a string name in
> the swarm field, then the service should warn when these mandatory
> fields are not explicitly specified.

I see.  The ‘define-configuration’ macro uses 'disabled as a way to
indicate fields that have not been user-specified.  Would that be of any
help in this context?

Another approach would be to use ‘define-record-type*’ and record all
the default values, including those derived from other fields (just like
the default ‘home-directory’ field of <user-account> is derived from
‘name’.)

Does that make sense?

Ludo’.

Re: using an SRFI that is not available in Guile

[Attila Lendvai]

using *unspecified* here won't work, because Guile's underlying record
implementation uses it pretty much for the same purpose: it errors
when it encounters *unspecified* as a field value:

> (cfg)
While compiling expression:
Syntax error:
unknown file:761:0: %cfg: missing field initializers (threads) in form (%cfg)

so, i'm back to square one: short of another idea, i'll need srfi-189
for this.


> I see. The ‘define-configuration’ macro uses 'disabled as a way to
> indicate fields that have not been user-specified. Would that be of any
> help in this context?


as discussed already somewhere, regardless of everything else, using
'DISABLED in this context is a bad idea that warrants a patch in
itself; it's super confusing and error prone because configs are full
of boolean fields.


> Another approach would be to use ‘define-record-type*’ and record all
> the default values, including those derived from other fields (just like
> the default ‘home-directory’ field of <user-account> is derived from
> ‘name’.)
>
> Does that make sense?


i think it does, but it would enforce a rather different code
organization. right now i have a function called APPLY-CONFIG-DEFAULTS
that is called at the beginning of each entry point to my service
code. it makes sure that the input config is valid, and returns a new
config object that has the defaults filled in. it has corss-referenced
local variables and even some local functions.

assuming that the evaluation of the default value forms of thunked
fields is delayed until their first access, then forcing this logic
into multiple default forms is possible, but i'd rather not if i can
avoid it.

also, i do want to have the goodies of DEFINE-CONFIGURATION. i used to
use DEFINE-RECORD* before, prior to knowing that D-C was a thing. then
i rewrote my code to use D-C.

maybe i can smarten up DEFINE-CONFIGURATION to (optionally?) use
thunked fields? i'll need to sleep on it.

Ludovic, you're not too happy about the use of extra dependencies
here, right? if so, can you please advise whether i can proceed with
giving srfi-189 a try and see what it looks like (i.e. it's not off
the table to get it accepted)? or do you have any other ideas?

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
Before you speak, let your words pass through three gates:
  At the first gate, ask yourself ‘Is is true?’
  At the second gate ask, ‘Is it necessary?’
  At the third gate ask, ‘Is it kind?’
	— Sufi saying

Re: using an SRFI that is not available in Guile

[Ludovic Courtès]

Hi,

Attila Lendvai <attila@lendvai.name> skribis:

>> Another approach would be to use ‘define-record-type*’ and record all
>> the default values, including those derived from other fields (just like
>> the default ‘home-directory’ field of <user-account> is derived from
>> ‘name’.)
>>
>> Does that make sense?
>
>
> i think it does, but it would enforce a rather different code
> organization. right now i have a function called APPLY-CONFIG-DEFAULTS
> that is called at the beginning of each entry point to my service
> code. it makes sure that the input config is valid, and returns a new
> config object that has the defaults filled in. it has corss-referenced
> local variables and even some local functions.

[...]

> Ludovic, you're not too happy about the use of extra dependencies
> here, right? if so, can you please advise whether i can proceed with
> giving srfi-189 a try and see what it looks like (i.e. it's not off
> the table to get it accepted)? or do you have any other ideas?

I think I just don’t understand yet how the needs you describe differ
from those of the already available services.

Do you have a preliminary version of the service where you think
existing mechanisms are insufficient?  Sometimes I find it clearer to
discuss concrete cases.

Thanks,
Ludo’.