Re: Profiles/manifests-related command line interface enhancements

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

Howdy!

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

>> I’d like to think that writing Guile declarations for the OS config,
>> manifest, etc. is not just for “power users”.  After all people, or
>> rather “computer-savvy” people in a broad sense, write JSON, YAML,
>> custom config files etc. routinely, and I don’t think the typical config
>> we propose is any “harder”.  You may say I’m a dreamer, but I’m not the
>> only one. 𝅗𝅥𝅘𝅥  ;-)
>
> The problem with powerful formal languages (read: Turing-complete) is
> not writing, but (1) debugging and (2) reading.

Yes and no.  Guile has a debugger, whereas XML/JSON/YAML don’t.  As for
reading, it’s subjective, but I don’t think a full-blown language is
necessarily harder to read.

  (define lst (list 1 2 3))

  lst = [1, 2, 3]

  lst:
    - 1
    - 2
    - 3

The goal for Guix was to have the ‘package’ and ‘operating-system’
forms, for instance, look exactly like what you’d write in JSON etc.,
only with a different syntax.

> 1. Writing a manifest file in Guile is no harder than writing a list
>    in YAML or whatever. But leave out the closing quote behind a
>    package name, and you will get an error message that will make
>    no sense to someone unfamiliar with the *complete* Scheme syntax.
>    For a small and simple file, you can usually spot the problem by
>    inspection (i.e. without the error message), but for more complex
>    files, it makes sense to use a more constrained language in order
>    to provide better error reporting.

Error-reporting is tricky, but it’s tricky also (perhaps even more!)
when parsing YAML.

I agree there’s room for improvement in Guile in that area, but it’s not
that bad either if you compare to error reporting with most YAML, JSON,
etc. libraries.  Also Guile can report errors about semantics.

>    BTW, the Racket team makes that point to argue for their rather
>    complex macro system. It takes much longer to master than traditional
>    Lisp or Scheme macros, but it supports writing macros with error
>    reporting that makes sense to someone who didn't read the macro code.

‘syntax-parse’ is wonderful for that, I agree.

> 2. Power users will always write code in powerful languages that exceed
>    what less advanced users can deal with. And since power users are not
>    necessarily benevolent, this creates a trust issue for the less
>    advanced ones.

Good point.  I tend to (naively?) view it the other way around: that it
gives people an incentive to try and write actual code rather than mere
declarations.

> For a long version of these arguments, see
>    https://hal.archives-ouvertes.fr/hal-01966145/document

Interesting!  The conclusion you seem to draw is that embedded DSLs as
found in Racket fit the bill, and to me, that’s pretty much what we’ve
been trying to do with Guix as well, no?

What do we disagree on, actually?  :-)

Thanks again for your feedback!

Ludo’.