Hello Danny,
> I just wanted to say that I'm not ignoring your patch, I'm just not qualified
> to review it. I hope someone steps up to it--otherwise I can't really tell
> whether (mbegin %state-monad...) inside a random service procedure is a good
> idea.
>
> Then again, provenance-service-type does it and there it seems to be fine...
For ***this*** very specific case it is because of a random weirdness of
`system-service-type`.
Specifically, the *value* of that service-type is an association list of
filenames and their contained store values. However, an ***extension*** of
that service-type must be a monadic action that results in an association list
of filename-contents.
Here is relevant code in `gnu/services`:
```scheme
(define (system-derivation entries mextensions)
"Return as a monadic value the derivation of the 'system' directory
containing the given entries."
(mlet %store-monad ((extensions (mapm/accumulate-builds identity
mextensions)))
(lower-object
(file-union "system"
(append entries (concatenate extensions))))))
(define system-service-type
;; This is the ultimate service type, the root of the service DAG. The
;; service of this type is extended by monadic name/item pairs. These items
;; end up in the "system directory" as returned by
;; 'operating-system-derivation'.
(service-type (name 'system)
(extensions '())
(compose identity)
(extend system-derivation)
(description
"Build the operating system top-level directory, which in
turn refers to everything the operating system needs: its kernel, initrd,
system profile, boot script, and so on.")))
```
So *extensions* must be monads (due to `mapm/accumulate-builds` on the
`mextensions`) but the raw value must be a simple non-monadic assoc list.
The patch moves some generated files ("kernel" and "hurd") from the value of
the `system-service-type` to an extension of `system-service-type`, thus the
extra `mbegin %store-monad`. It needs to be `%store-monad` since that is the
monad used by the `system-derivation` function.
See:
```scheme
(define (kernel-builder-configuration->system-entry config)
"Return the kernel and hurd entries of the 'system' directory."
(mbegin %store-monad
#;...))
#;...
(define kernel-loadable-module-service-type
(service-type (name 'kernel-loadable-modules)
(extensions
(list (service-extension system-service-type
kernel-builder-configuration->system-entry))) ;; <-- OVER HERE
(compose concatenate)
(extend kernel-builder-configuration-add-modules)
(description
"Register packages containing kernel-loadable modules and adds
them+to the system.")))
```
So it is not just some "random service procedure", it is because that is the
interface exposed by `system-service-type` for its extensions, extensions of
`system-service-type` have to yield a monadic action. `mbegin` is one of the
simpler monadic actions. It is also in the "correct place" as best as I can
tell, since only service types in `gnu/services.scm` dare to extend
`system-service-type`.
`provenance-service-type` does this as well because it *also* extends
`system-service-type`. This is basically done here simply because that is what
`system-service-type` expects.
Thanks
raid5atemyhomework
