From ef4ab0a4c55f47e581e7a47622061f1583676d1e Mon Sep 17 00:00:00 2001 From: Ludovic Courtès Date: Thu, 8 May 2014 21:50:53 +0200 Subject: doc: Mention Kiselyov's work on "staging". * doc/guix.texi (G-Expressions): Mention Oleg's work on "staging" in footnote. --- doc/guix.texi | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) (limited to 'doc') diff --git a/doc/guix.texi b/doc/guix.texi index e127b0f76a..2aacf5d9b6 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -1995,10 +1995,14 @@ build the derivations; they are run by the daemon in a container It should come as no surprise that we like to write those build actions in Scheme. When we do that, we end up with two @dfn{strata} of Scheme code@footnote{The term @dfn{stratum} in this context was coined by -Manuel Serrano et al.@: in the context of their work on Hop.}: the -``host code''---code that defines packages, talks to the daemon, -etc.---and the ``build code''---code that actually performs build -actions, such as making directories, invoking @command{make}, etc. +Manuel Serrano et al.@: in the context of their work on Hop. Oleg +Kiselyov, who has written insightful +@url{http://okmij.org/ftp/meta-programming/#meta-scheme, essays and code +on this topic}, refers to this kind of code generation as +@dfn{staging}.}: the ``host code''---code that defines packages, talks +to the daemon, etc.---and the ``build code''---code that actually +performs build actions, such as making directories, invoking +@command{make}, etc. To describe a derivation and its build actions, one typically needs to embed build code inside host code. It boils down to manipulating build -- cgit v1.2.3