Heya,

On Sat Dec 10, 2022 at 9:25 PM GMT, Mekeor Melire wrote:
> I think it'd also be fine to come up with the titles during the process of writing as sometimes that process itself is insightful. E.g. I could imagine parts 2 and 4 to collapse. Maybe, maybe not, you'll see.

Perhaps.  I think monads are complex enough to warrant their own post, though.

> How'd this part differ from section "12.18 Defining Services" of the manual?

Along with a low-level description of the workings of services, it'd contain a
complex, concrete example of a service.  The manual mostly has an API reference
and some high-level-ish examples.

> How'd this part differ from sections 22 and "22.6 Submitting Patches" from the manual?

Again, it'd be more concrete than what the manual shows.  It'd explain the
process by demonstrating the development of an *actual patch*, and showing how
it could be sent to guix-patches@gnu.org.

> By the way, the text does not seem to strictly fill columns at a certain line width. So I did not bother to fill columns in the "patch".

Right, I should set up FILL-COLUMNS-INDICATOR... :)

> If the purpose is out of scope, then we should not dive in that deeply. Especially, I'd suggest skip the code snippet.

I'm not sure about this.  

> Here you write "pretty simple". Later you also write "self-explanatory" and "obviously". I suggest to let the reader decide what's simple.

Fair.

> Before this point, the record fields have been called '"argument"'s all the time. I think it's not nice style to carry on a quoted term through many paragraphs like this. Let's simply write "record field" all the time, instead.

This is fair too :)

> I think an example for invoking read-derivation-from-file would round up this tutorial really nicely because it'd close the circle between .drv-files and <derivation>-objects.

Okay!  And one for write-derivation, too.

> Here, in the conclusion, IMHO, there could be another brief listing of all fields of a derivation.

Good idea.

    -- (