Re: A new paradigm for modifying operating system declarations

[raid5atemyhomework]

Good morning Taylan,

> First, let me point out a more conventional alternative to what your
> 'decorate' macro does:
>
> (define (compose proc . rest)
> "Functional composition; e.g. ((compose x y) a) = (x (y a))."
> (if (null? rest)
> proc
> (let ((rest-proc (apply compose rest)))
> (lambda x
> (let-values ((x (apply rest-proc x)))
> (apply proc x))))))
>
> This allows for something like:
>
> ((compose install-foo install-bar install-zfs)
> (operating-system ...))
>
> Or perhaps cleaner:
>
> (define my-os-modifier (compose install-foo install-bar install-zfs))
>
> (my-os-modifier
> (operating-system ...))
>
> If you need custom modifications within, you can do:
>
> (define my-os-modifier
> (compose install-foo
> (lambda (os) ...)
> install-bar))
>
> It's more verbose, but doesn't "break" standard Scheme syntax as much.
> Function composition is conceptually pretty easy and probably more
> well-known than "decorators" (which I had never heard of, personally).

Yes, except function composition does not work on syntactic forms, which is 
why, with `compose`, you have to separate the `operating-system` form instead 
of being able to compose `operating-system` with the rest of the os 
modifications.

The intent is that you have already an existing `operating-system` form with a 
single layer of parenthesis. With `compose`, if you want to install ZFS and a 
bunch of other complex OS modifications, you have to add a layer of 
parenthesis.  With `decorate`, you don't:

```scheme
((compose install-zfs install-foo)
 (operating-system
    (name "my-system") #;...))
;vs
(decorate (install-zfs
           install-foo
           operating-system)
  (nmae "my-system") #;...)
```

>
> Fewer macros means the reader needs to keep fewer special rules in mind.

Fine, I'm doubling down then.

```scheme
(define-syntax compose-syntax
  (syntax-rules ()
    ((compose-syntax (x ...))
     (syntax-rules ::: ()
       ((form args :::)
        (x ... args :::))))
    ((compose-syntax x)
     (syntax-rules ::: ()
       ((form args :::)
        (x args :::))))
    ((compose-syntax (x ...) y ...)
     (syntax-rules ::: ()
       ((form args :::)
        (let-syntax ((sub-syntax (compose-syntax y ...)))
          (x ... (sub-syntax args :::))))))
    ((compose-syntax x y ...)
     (syntax-rules ::: ()
       ((form args :::)
        (let-syntax ((sub-syntax (compose-syntax y ...))
          (x (sub-syntax args :::)))))))))
```

Then use it as follows:

```
(define-syntax my-operating-system
  (compose-syntax
    (install-zfs #:options '(("zfs_arc_max" 5000000000)) #:os)
    operating-system))
(my-operating-system
  (name "my-system") #;...)
```

Again, the goal here is to keep the nestedness of your existing, very long 
`operating-system` form, which your simple `compose` function fails to do, 
because you can't compose syntax with `compose` and `operating-system` is a 
syntax form.

>
> Secondly, I wonder if passing an OS declaration through various
> procedures that modify it is really the best approach in the first place.
>
> For build phases, we have the 'modify-phases' syntax. For services,
> there is 'modify-services'. Maybe there should be a 'modify-os' kind of
> syntax. (In other words, if we're going to invent new syntax, why not
> go all-out and create the most convenient syntax for the use-case.)

Because a *generic* form to modify the operating system is worthless --- you 
can just define the operating-system directly.

What `install-zfs` does is that it installs the same kernel-specific package in 
three different points:

* `kernel-loadable-modules`, because ZFS needs to get into the kernel somehow.
* `packages`, because the kernel module is useless if you don't have the 
userland tools to interact with the kernel module.
* `services`, because ZFS is well-documented outside of Guix as automatically 
mounting its filesystems at bootup, but that actually requires a bit of magic 
in the `init` system, specifically you need to actually **load** the module, 
then execute `zpool import -a -l` to have it scan for all filesystems and mount 
those that need automounting.

Thus, an `install-zfs`, that is a *single* form that inserts the correct bits 
in the correct ***three*** places, makes the experience of adding ZFS to your 
`operating-system` easier because there's less scope for error in actually 
adding the package.  You just add a single `install-zfs`, not add three things 
(plus an extra `(define my-zfs (make-zfs-package linux-libre-5.4))` before your 
form).


Now, if this kind of simplifying form is useful for ZFS, I imagine that this 
kind of simplifying form would also exist for other things you could install 
into your operating system in the future.  Thus, we need some way to take an 
existing `<operating-system>` and pass it through a number of single 
simplifying operating system transformations, which I don't think something 
like `modify-os` would work well with.


Thanks
raid5atemyhomework