using srfi-189 in (gnu services configuration)

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'

Re: using srfi-189 in (gnu services configuration)

[Maxime Devos]

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

Attila Lendvai schreef op ma 28-03-2022 om 14:35 [+0000]:
> 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. [...]
> 
>   in the current setup, simply specifying a default value would make
>   it impossible to distinguish, because [...]
> 
> - the current code uses the symbol 'DISABLED

It's a bit of a distraction to the discusses issue, but in Guile
Scheme, symbols are case-sensitive, so (not (eq? 'disabled '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.

This does not appear to be true, at least for (srfi srfi-9) records:
the following code can put *unspecified* in Guile records without any
errors:

(use-modules (srfi srfi-9))
(define-record-type <foobar>
 (make-foobar foo) foo? (foo foobar-foo))

(pk 'foobar (make-foobar *unspecified*))
;;; (foobar #<<foobar> foo: #<unspecified>>)

Anyway, even if *unspecified* causes problems, this can be resolved by
introducing a new constant like *unspecified* or the symbol 'disabled',
but without the potential confusion with a symbol.  E.g.:

(define-values (*unset-configuration-value* unset-configuration-value?)
  (let ()
    (define-record-type <unset-configuration-value>
      (*make-unset-configuration-value*) unset-configuration-value?
      unset-configuration-value?)
    (values (*make-unset-configuration-value*)
            unset-configuration-value?)))

srfi-189 is also an option, but it seems to me that Haskell-style
Maybe/Just/None that would require lots of wrapping and unwrapping
which seems a bit tedious to me -- doable and definitely an option, but
potentially tedious.

Additionally, for your Swarm example, would something like the
following work:

   ;; defined in (gnu services cryptocurrencies) or such
   (define swarm-testnet
     (swarm-instance
       (bootstrap-peers (list "x.y.z.w" "1111:2222:3333::4"))
       (foo-rate 1.5+2i)
       ...))
   (define swarm-mainnet [...])

   (swarm-configuration
     (ethereum-account ...)
     (port 12345) ; default: 54321
     ;; If the user known what they are doing, they can override
     ;; 
     (swarms (list swarm-testnet swarm-mainnet)))

?  This way, the well-known swarms 'testnet' and 'mainnet' do not have
to be special-cased.

Greetings,
Maxime.

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

Re: using srfi-189 in (gnu services configuration)

[Attila Lendvai]

> > - the current code uses the symbol 'DISABLED
>
> It's a bit of a distraction to the discusses issue, but in Guile
> Scheme, symbols are case-sensitive, so (not (eq? 'disabled 'DISABLED)).


to clarify: i'm using uppercase here only to discriminate scheme
symbols from a free-flowing english text. it's common practice in the
CL world, but i've also seen it in the Guix docstrings.


> This does not appear to be true, at least for (srfi srfi-9) records:
>
> the following code can put unspecified in Guile records without any
> errors:
>
> (use-modules (srfi srfi-9))
> (define-record-type <foobar>
> (make-foobar foo) foo? (foo foobar-foo))
> (pk 'foobar (make-foobar unspecified))
> ;;; (foobar #<<foobar> foo: #<unspecified>>)


my apologies for stating something with confidence that is not true!

i have vivid memory of having tried to use *unspecified*, and getting
errors from record accessors, but i cannot reproduce it now. maybe i
did something with UNDEFINED?, but i don't even see now how to get
hold of that value.

anyway, i'll try to patch up (gnu services configuration) to use
*unspecified* instead of 'DISABLED, and i'll report back with the end
result it it's worthy of that.


> Anyway, even if unspecified causes problems, this can be resolved by
> introducing a new constant like unspecified or the symbol 'disabled',
> but without the potential confusion with a symbol. E.g.:
>
> (define-values (unset-configuration-value unset-configuration-value?)
> (let ()
> (define-record-type <unset-configuration-value>
> (make-unset-configuration-value) unset-configuration-value?
> unset-configuration-value?)
> (values (make-unset-configuration-value)
> unset-configuration-value?)))


it's not really relevant now, but this is pretty much what srfi-189
does, but as a documented standard.


> srfi-189 is also an option, but it seems to me that Haskell-style
> Maybe/Just/None that would require lots of wrapping and unwrapping
> which seems a bit tedious to me -- doable and definitely an option, but
> potentially tedious.


i'm afraid about that, too, but i cannot say before i start
implementing it.

and i think the config code will be equally littered with (if
(unspecified?  ...)  ...) forms, as opposed to (maybe-ref ...) forms
when using srfi-189.


> Additionally, for your Swarm example, would something like the
> following work:


this is an excellent idea! (namely, to capture the settings of various
swarms into instances, and then predefine the two well-known swarms)

i'll implement this first, and only move on to the config stuff
afterwards.

thanks again Maxime,

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“He alone is great and happy who fills his own station of independence, and has neither to command nor to obey.”
	— Johann Wolfgang von Goethe (1749–1832), 'With the Iron Hand' (1773), Act I