using srfi-189 in (gnu services configuration)

[Attila Lendvai]

this is a follow up to: using an SRFI that is not available in Guile

https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00249.html

let me summarize the discussion, and with that my argument why i'd
like to use srfi-189 in the configuration code:

- sometimes we need to be able to unambiguously distinguish whether a
  config field value has been specified by the user or not.

  the reason is that in some situations setting a config value by the
  user is actually an error; e.g. when field A's value is derived from
  field B's value, but only sometimes, depending on the actual value
  of B.

  in the current setup, simply specifying a default value would make
  it impossible to distinguish, because by the time the code of the
  service is executed, the default value is already written into the
  field.

- the current code uses the symbol 'DISABLED as a special field value
  to signify that the field has not been set (i.e. what Nothing would
  mean if we used srfi-189). it is rather confusing, because many
  config fields are boolean fields, where 'DISABLED sounds like a
  valid off value. it is also prone for clashes with user specified
  values.

- the current codebase also uses 'UNDEFINED as yet another special
  marker. once i understood, but unfortunately, i have forgotten what
  for since then... looks like only as a marker in the macro for the
  situation when no default value form has been specified for a
  field's definition.

- using symbols as markers for special values is a bad idea, because
  the user may specify a field type to be SYMBOL?, which wouldn't
  error when the value is 'DISABLED.

- we can't use Guile's *UNSPECIFIED* for this, because the underlying
  record implementation of Guile uses it for pretty much the same
  thing, and it errors whenever this value is encountered in a
  record's field.

- i see only one way to implement this in the current setup that may
  be doable: use DEFINE-RECORD* (already a loss of many features of
  CONFIGURATION), use thunked fields, and squeeze the logic into the
  default thunk of every field separately.

  at least in my case, it would force a rather unnatural shape on the
  code. understanding the code would be only possible if the reader
  has a proper understanding of thunked fields and what is executed
  when -- which is arguably a harder requirement than grasping Maybe
  and Nothing.

- srfi-189's Maybe and Nothing may come useful in other parts of the
  Guix codebase.

the Maybe and Nothing types/abstranctions implement a solution exactly
for this problem: the ability to detect and deal with the/a special
Nothing value.

the first stage of this adventure, namely adding guile-srfi-189 to the
packages, has been merged.

now, the second stage is going to be a non-trivial task for me,
therefore before i venture into incorporating the use srfi-189 into
the configuration codebase, and before we can see what the actual
implementation looks like, i'd like to ask the maintainers to speak up
if either:

 1) they have been convinced that this may actually turn out
    well, or

 2) if they still have strong feelings against this venture, and would
    probably oppose the use of sfri-189, regardless of the qualities
    of the resulting patch.

any feedback is appreciated,

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Learning without thinking is useless. Thinking without learning is dangerous.”
        — Confucius (551–479 BC), 'The Analects'