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

[bokr@bokr.com]

Hi,

On +2022-08-02 09:31:14 +0200, Ludovic Courtès wrote:
> 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?
>

My 2¢ :

Maybe separate commmit churn more formally into a
release candidate series like Linus does for linux kernel,
and have a long term stable guix only get what is agreed
with solid consensus?

AND, importantly: where issues involve subtleties
of abstract entities vs their concrete representations,
make sure this is clearly documented in the commit rationale,
e.g., maybe using denottional semantics[1] like r5rs ?

[1]:  <https://en.wikipedia.org/wiki/Denotational_semantics>

:)

> Thanks,
> Ludo’.
>
--
Regards,
Bengt Richter
OT PS: Has Boot-to-guile been updated by anyone?
Kudos for the original! :) A RISCV qemu image? :)