Hi, On +2022-08-02 09:31:14 +0200, Ludovic Courtès wrote: > Hi, > > Maxim Cournoyer <maxim.courno...@gmail.com> skribis: > > > Ludovic Courtès <l...@gnu.org> writes: > > > >> Hi! > >> > >> Maxim Cournoyer <maxim.courno...@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? :)