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-patc...@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. -- (
signature.asc
Description: PGP signature