bug#56799: (gnu services configuration) usage of *unspecified* is problematic

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi!
>>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>
>>> Since commit 8cb1a49a3998c39f315a4199b7d4a121a6d66449, the
>>> define-configuration machinery in (gnu services configuration) uses
>>> *unspecified* instead of 'disabled for an unspecified field value.
>>
>> As Attila wrote, the rationale as discussed in
>> <https://issues.guix.gnu.org/54674> was to specifically use a “special”
>> value without a read syntax in lieu of a symbol like 'disabled.
>>
>>> While this is indeed an improvement in readability, it introduces an
>>> extra complication: because this new value is not self-quoting, it
>>> cannot be used as is in G-Exps, and values using it must be carefully
>>> expanded outside the gexp context, which is error prone.
>>
>> Could you give a simple example of how this can happen?
>>
>> In my experience, one would use ‘define-maybe’ and appropriate field
>> serializers such that *unspecified* never goes through.  Previously
>> you’d check for (eq? x 'disabled) and now you just check for
>> (unspecified? x).
>
> Yes, I understand that.  What changed is that previously you could have
> the configuration serialized and used on the service side, which is what
> using *unspecified* made impossible.

Do you have an example?  Even on the service side, I imagine one could
check for ‘unspecified?’ just like one would check for 'disabled, no?

> Granted, few services outside of Jami probably made use of this, but it
> was nevertheless a useful property.

I don’t know of any.

Having spent time reviewing the original change that Attila proposed and
then chiming in on this issue, I would have hoped for a longer
discussion before enacting the change in
a2b89a3319dc1d621c546855f578acae5baaf6da.

In addition to these issues around the process, I think we should strive
for more stability.  One of the reasons it took time to review
<https://issues.guix.gnu.org/54674> is that interface changes are a
commitment.  Now commit a2b89a3319dc1d621c546855f578acae5baaf6da
introduces a second interface change for reasons that are unclear to me
(if the conclusion had been to revert, I’d have favored an actual revert
rather than introducing 'unset).

How should we move forward?

Thanks,
Ludo’.