Hello!
Edouard Klein <e...@rdklein.fr> skribis:
> Thank you Liliana and Attila for the swift and actionable feedback :)
>
> Below is a revised proposition.
>
> Here is a minimal working example of an os declaration:
> ------------------mwe.scm---------------
> (use-modules
> (beaver system)
> (beaver functional-services)
> (gnu packages version-control)
> (gnu services web)
> (gnu services telephony)
> (gnu services ssh)
> (gnu services base)
> (guix gexp))
>
> (-> (minimal-ovh "osef")
> (instantiate nginx)
> (instantiate mumble-server
> (welcome-text "coucou")
> (port 64738))
> (extend openssh `(("alice" ,(local-file
> "/home/edouard/.ssh/id_rsa.pub"))))
> (modify openssh
> (password-authentication? #f)
> (allow-empty-passwords? #t))
> (remove guix))
> -------------------------------------------------------
>
> To see the value of this syntactic sugar, try to replicate this MWE with
> the standard syntax. It's not horrendous, but it *is* off-putting to
> many newcomers to git, whereas this sugary piece is more readable for
> them (sample size of 1, p=0.00000005).
Glad you ran a user study. :-)
This is looking more and more like:
(define-syntax ->
(syntax-rules ()
((_ os rules ...)
(operating-system
(inherit os)
(services (modify-services (operating-system-user-services os)
rules ...))))))
One thing that always makes me hesitate due to the longstanding hygienic
macro tradition in Scheme is non-hyienic introduction of identifiers: in
the example you gave above, the identifiers ‘openssh-service-type’ and
‘openssh-configuration’ are automatically derived from ‘openssh’. This
could lead to surprises and makes grepping harder. But I don’t know,
maybe that’s the price to pay?
Maybe one conclusion we can draw from this is that configuration records
and service types should be more closely tied to one another.
>>> (service+ OS SERVICE [CONF])
>>> (service- OS SERVICE)
This one looked really revolutionary, but it’s inspiring too!
Thanks,
Ludo’.
