Re: Syntactic Diabetes (was Re: A friendlier API for operating-system declarations)

[Liliana Marie Prikler]

Am Sonntag, dem 26.11.2023 um 21:46 +0100 schrieb Edouard Klein:
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> > >     (instantiate nginx)
> > I do wish you spelled out service.  Also, instantiate takes as much
> > characters to type as add-service.
> > 
> 
> Done, see below. I was worried about the paronymy between add-service
> and add-services which already exists. I defer to you and your
> experience on this, naming things is hard.
That's not that much of a deal in scheme, see let and let* for example.

> > > 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).
> > Well, that'd be
> > ...
> 
> I tried:
> 
> (let ((base (minimal-ovh "osef")))
>   (operating-system
>     (inherit base)
>     (services
>       (cons*
>        (service nginx-service-type)
>        (service mumble-server-service-type
>                 (mumble-server-configuration
>                  (welcome-text "couocu")
>                  (port 64738)))
>        (service openssh-service-type
>                 (openssh-configuration
>                  (password-authentication? #f)
>                  (allow-empty-passwords? #t)
>                  (authorized-keys `(("alice" ,(local-file
> "/home/edouard/.ssh/id_rsa.pub"))))))
>        (operating-system-user-services base)))))
> 
> 
> I admit that this is as readable as the sweet version, but:
> 
> - Openssh is already defined in  (minimal-ovh "osef"), so the build
>   fails with: 'guix system: error: service 'ssh-daemon' provided more
>   than once'
> - you forgot the removal of guix-service, which admitedly is not used
> much in practice
>   anyway
Nice catch.

> The problem with those two is that they break the nice structure of
> just adding services, and now one has to first remove an element from
> (operating-system-user-services base), then edit one of the element
> of the resulting list, then add to elements to it. It is probably
> possible to write it in a readable way, maybe less so than the sweet
> version, but not so much as to justify adding the new macros to guix.
Fair enough, but you could still implement that as an (extended)
modify-services.  We haven't reached the level of complexity where we'd
touch multiple fields, which is when operating-system really becomes a
pain to work with.  (The ssh-user from beaverlabs is one such example,
that IIRC is also used extensively on the-dam.)

> However the readability is not the main selling point, the
> writeability is. Please do not discount how hard it is to write that
> kind of stuff when scheme's not your main language. It is possible
> people here forgot how hard this is for beginners, especially those
> like me whose brain is deformed from years using algol-derived
> syntaxes.
> 
> I think we are losing a lot of mindshare because of the hard step of
> learning both guile and guix, and the kind of syntactic sugar I
> suggest may help bridge the gap long enough for newcomers to ease
> into the syntax, after they get a taste of guix' capabilities.
Fair point, and I'm not really opposed to making things more
readable/writable.  The problem comes with groking the additional
syntax.  It is not something the manuals would prepare you for and
probably also encounters weird corner cases like services using
something else than SERVICE-configuration for its configuration data.

> Another experiment: with the sweet syntax, you can easily extend
> services, without having to define a -record-type, etc. Just define a
> function. I can write more at length about that if you want.
That's again just simple-service doing its job tho :)

In essence, what I'm trying to get here is something that'd let us
implement the more complicated part of OS config fiddling with few
lines of code.  I think hyper-focusing on syntax to make services
"nicer" might be the wrong approach here: You could greatly reduce the
complexity by making them procedures instead of syntax and still keep
most of the configuration readable to a great extent.

Maybe we should start with making modify-services more powerful to also
cover the "adding services" case: modify-inputs already does that, so
it's weird that modify-services doesn't.  We should also think on how
to best wrap this in a lambda then; defining a new syntax for most
operations doesn't seem all that useful and scalable to me.

Cheers
>