01/14: doc: Add GPCE paper.

[Ludovic Court�s]

civodul pushed a commit to branch master
in repository maintenance.

commit 6727f8e6b262d8071a45362f7e3c12eb101ce8ba
Author: Ludovic Courtès <address@hidden>
Date:   Fri Jun 30 18:40:03 2017 +0200

    doc: Add GPCE paper.
---
 .gitignore                            |   4 +
 doc/gpce-2017/GNUmakefile             |  11 +
 doc/gpce-2017/abstract.md             |  20 ++
 doc/gpce-2017/code/GuixSD.png         | Bin 0 -> 14332 bytes
 doc/gpce-2017/code/build-sexp.scm     |  39 ++++
 doc/gpce-2017/code/gexp-expansion.scm |  26 +++
 doc/gpce-2017/gpce.org                |  48 ++++
 doc/gpce-2017/gpce.skb                | 417 ++++++++++++++++++++++++++++++++++
 doc/gpce-2017/staging.sbib            |  22 ++
 9 files changed, 587 insertions(+)

diff --git a/.gitignore b/.gitignore
index 98201c3..948e1f9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -122,3 +122,7 @@
 /talks/ghm-2017/update/talk.snm
 /talks/ghm-2017/update/talk.toc
 /talks/ghm-2017/update/talk.vrb
+/doc/gpce-2017/gpce.aux
+/doc/gpce-2017/gpce.log
+/doc/gpce-2017/gpce.out
+/doc/gpce-2017/gpce.pdf
diff --git a/doc/gpce-2017/GNUmakefile b/doc/gpce-2017/GNUmakefile
new file mode 100644
index 0000000..361691a
--- /dev/null
+++ b/doc/gpce-2017/GNUmakefile
@@ -0,0 +1,11 @@
+SKRIBILO := skribilo
+PDFLATEX := pdflatex
+RUBBER   := rubber
+
+.DEFAULT_GOAL := gpce.pdf
+
+%.pdf: %.tex
+       $(RUBBER) --pdf "$<"
+
+%.tex: %.skb
+       $(SKRIBILO)  -t latex -o "$@" "$<"
diff --git a/doc/gpce-2017/abstract.md b/doc/gpce-2017/abstract.md
new file mode 100644
index 0000000..54bbab9
--- /dev/null
+++ b/doc/gpce-2017/abstract.md
@@ -0,0 +1,20 @@
+Staging in GNU Guix
+=================
+
+GNU Guix is a “functional” package manager that borrows from earlier
+work on Nix by Dolstra _et al._.  Guix implements high-level
+abstractions such as packages and operating system services as
+domain-specific languages (DSL) embedded in Scheme, and it also
+implements build actions and operating system orchestration in Scheme.
+This leads to a multi-tier programming environment where embedded code
+snippets are _staged_ for eventual execution.
+
+In this paper we present _G-expressions_ or “_gexps_”.  We explain our
+journey from traditional Lisp S-expressions to G-expressions, which
+augment the former with contextual information, and we discuss the
+implementation of gexps.  We report on our experience using gexps in a
+variety of operating system use cases—from package build processes, to
+initial RAM disk code, to system services.  To our knowledge, gexps
+provide a unique way to cover many aspects of OS configuration in a
+single, multi-tier language, and to facilitate code reuse and code
+sharing.  Finally we compare to related work on staging.
diff --git a/doc/gpce-2017/code/GuixSD.png b/doc/gpce-2017/code/GuixSD.png
new file mode 100644
index 0000000..eab9c59
Binary files /dev/null and b/doc/gpce-2017/code/GuixSD.png differ
diff --git a/doc/gpce-2017/code/build-sexp.scm 
b/doc/gpce-2017/code/build-sexp.scm
new file mode 100644
index 0000000..44f7a2e
--- /dev/null
+++ b/doc/gpce-2017/code/build-sexp.scm
@@ -0,0 +1,39 @@
+(use-modules (guix) (gnu))
+
+(define imagemagick
+  (specification->package "imagemagick"))
+
+(with-store store
+  (%guile-for-build (package-derivation store
+                                        (specification->package "guile"))))
+
+;!begin-build-sexp
+(let* ((store (open-connection))
+       (drv   (package-derivation store imagemagick))
+       (image (add-to-store store "image.png" #t "sha256"
+                            "./GuixSD.png"))
+       (build
+        '(let ((imagemagick (assoc-ref %build-inputs
+                                       "imagemagick"))
+               (image (assoc-ref %build-inputs "image")))
+           (mkdir %output)
+           (system* (string-append imagemagick "/bin/convert")
+                    "-quality" "75%"
+                    image
+                    (string-append %output "/image.jpg")))))
+  (build-expression->derivation store "example" build
+                                #:inputs `(("imagemagick" ,drv)
+                                           ("image" ,image))))
+;!end-build-sexp
+
+;!begin-imagemagick-gexp
+(let* ((image (local-file "./GuixSD.png" "image.png"))
+       (build #~(begin
+                  (mkdir #$output)
+                  (system* (string-append #$imagemagick
+                                          "/bin/convert")
+                           "-quality" "75%"
+                           #$image
+                           (string-append #$output "/image.jpg")))))
+  (gexp->derivation "example" build))
+;!end-imagemagick-gexp
diff --git a/doc/gpce-2017/code/gexp-expansion.scm 
b/doc/gpce-2017/code/gexp-expansion.scm
new file mode 100644
index 0000000..aab1365
--- /dev/null
+++ b/doc/gpce-2017/code/gexp-expansion.scm
@@ -0,0 +1,26 @@
+(use-modules (guix))
+
+;!begin-condensed
+#~(list (string-append #$imagemagick "/bin/convert")
+        (string-append #$emacs "/bin/emacs"))
+;!end-condensed
+
+;!begin-gexp-without-reader-macro
+(gexp (list (string-append (ungexp imagemagick)
+                           "/bin/convert")
+            (string-append (ungexp emacs)
+                           "/bin/emacs")))
+;!end-gexp-without-reader-macro
+
+;!begin-expansion
+(let ((references
+       (list (gexp-input imagemagick)
+             (gexp-input emacs)))
+      (proc (lambda (a b)
+              (list 'list
+                    (list 'string-append a
+                          "/bin/convert")
+                    (list 'string-append b
+                          "/bin/emacs")))))
+  (make-gexp references proc))
+;!end-expansion
diff --git a/doc/gpce-2017/gpce.org b/doc/gpce-2017/gpce.org
new file mode 100644
index 0000000..77d4dea
--- /dev/null
+++ b/doc/gpce-2017/gpce.org
@@ -0,0 +1,48 @@
+#+TITLE: Staging in GNU Guix
+
+* Abstract
+
+GNU Guix is a “functional” package manager that borrows from earlier
+work on Nix by Dolstra _et al._.  Guix implements high-level
+abstractions such as packages and operating system services as
+domain-specific languages (DSL) embedded in Scheme, and it also
+implements build actions and operating system orchestration in Scheme.
+This leads to a multi-tier programming environment where embedded code
+snippets are _staged_ for eventual execution.
+
+In this paper we present _G-expressions_ or “_gexps_”.  We explain our
+journey from traditional Lisp S-expressions to G-expressions, which
+augment the former with contextual information, and we discuss the
+implementation of gexps.  We report on our experience using gexps in a
+variety of operating system use cases—from package build processes, to
+initial RAM disk code, to system services.  To our knowledge, gexps
+provide a unique way to cover many aspects of OS configuration in a
+single, multi-tier language, and to facilitate code reuse and code
+sharing.  Finally we compare to related work on staging.
+
+* Introduction
+
+GNU Guix is a “functional” package manager based on the same concepts as
+Nix 
+
+* From S-Exps to G-Exps
+
+** Staging Build Expressions
+
+** When S-Exps Aren't Enough
+
+** Design and Implementation of G-Expressions
+
+* Experience
+
+** Build Processes
+
+** System Services
+
+** Mobile Code
+
+* Limitations
+
+* Related Work
+
+* Conclusion
diff --git a/doc/gpce-2017/gpce.skb b/doc/gpce-2017/gpce.skb
new file mode 100644
index 0000000..7c8aae6
--- /dev/null
+++ b/doc/gpce-2017/gpce.skb
@@ -0,0 +1,417 @@
+(use-modules (skribilo package acmproc)
+            (skribilo engine)
+            (skribilo engine latex)
+            (skribilo ast)
+            (skribilo writer)
+            (skribilo evaluator)
+            (skribilo biblio author)
+            (skribilo source lisp))
+
+(define (---) ; emdash
+  (resolve (lambda (n e env)
+             (if (engine-format? "html" e)
+                 (! "&mdash;")
+                 (! "---")))))
+
+(define (--) ; endash
+  (resolve (lambda (n e env)
+             (if (engine-format? "html" e)
+                 (! "&ndash;")
+                 (! "--")))))
+                
+(define (dash-dash)
+  (resolve (lambda (n e env)
+             (if (engine-format? "latex" e)
+                (! "{-}{-}")
+                "--"))))
+
+(define (corresponding)
+  (resolve (lambda (n e env)
+             (if (engine-format? "latex" e)
+                (! "co\\-rres\\-pon\\-ding")
+                "corresponding"))))
+
+(define (url url)
+  (ref :text (tt url) :url url))
+
+(define (=>)
+  (symbol "=>"))
+  
+;; For pdflatex.
+(engine-custom-set! (find-engine 'latex) 'image-format '("pdf"))
+                   
+;; Avoid "option clash" with acmart.
+(engine-custom-set! (find-engine 'latex) 'hyperref #f)
+                
+(engine-custom-set! (find-engine 'latex) 'usepackage
+                   (let ((u (engine-custom (find-engine 'latex)
+                                           'usepackage)))
+                     ;; See 
<https://en.wikibooks.org/wiki/LaTeX/Labels_and_Cross-referencing>
+                     ;; and 
<http://tug.org/pipermail/texhax/2010-September/015596.html>.
+                     (string-append u "\n" 
+                                   "\\usepackage{microtype}\n"
+                                   ;; "\\usepackage[hypcap]{caption}\n"
+                                   ;; "\\DeclareCaptionType{copyrightbox}\n"
+                                   "\\usepackage{balance}\n"
+                                   )))
+
+(engine-custom-set! (find-engine 'latex) 'documentclass
+                   "\\documentclass[sigplan, anonymous, review]{acmart}")
+
+(let* ((latex (find-engine 'latex))
+       (usep  (engine-custom latex 'usepackage)))
+;;   (engine-custom-set! latex 'usepackage
+;;                       (string-append usep "
+;; \\usepackage{floatrow}
+;; \\floatsetup[figure]{font=footnotesize}
+;; \\setlength{\\intextsep}{5pt plus 1.0pt minus 2.0pt}
+;; "))
+  (engine-custom-set! latex 'source-comment-color
+                      "#776600"))
+
+(bibliography "../els-2013/guix.sbib")
+(bibliography "../reppar-2015/reppar.sbib")
+(bibliography "./staging.sbib")
+
+(document :title [Code Staging in GNU Guix]
+   
+   (abstract
+    ;chapter :title [Abstract]
+   
+     (p [GNU Guix is a “functional” package manager that builds upon
+earlier work on Nix.  Guix implements high-level abstractions such as
+packages and operating system services as domain-specific languages
+(DSL) embedded in Scheme, and it also implements build actions and
+operating system orchestration in Scheme.  This leads to a multi-tier
+programming environment where embedded code snippets are staged for
+eventual execution.])
+
+     (p [In this paper we present ,(emph [G-expressions]) or “,(emph
+[gexps])”, the staging mechanism we devised for Guix.  We explain our
+journey from traditional Lisp S-expressions to G-expressions, which
+augment the former with contextual information, and we discuss the
+implementation of gexps.  We report on our experience using gexps in a
+variety of operating system use cases—from package build processes, to
+initial RAM disk code, to system services.  To our knowledge, gexps
+provide a unique way to cover many aspects of OS configuration in a
+single, multi-tier language, and to facilitate code reuse and code
+sharing.  Finally we compare to related work on staging.]))
+   
+   (chapter :title [Introduction]
+      
+      (p [Users of free operating systems such as GNU/Linux are used
+to ,(emph [package managers]) like Debian's ,(tt [apt-get]), which
+allow them to install, upgrade, and remove software from a large
+collection of free software packages.  GNU Guix,(footnote (url
+"https://gnu.org/software/guix";)) is a ,(emph [functional]) package
+manager that builds upon the ideas developed for Nix by Dolstra ,(it
+[et al.]) ,(ref :bib 'dolstra2004:nix).  The term “functional” means
+that software build processes are considered as pure functions: given
+a set of inputs (compiler, libraries, build scripts, and so on), a
+package’s build function is assumed to always produce the same result.
+Build results are stored in an immutable persistent data structure,
+the store, implemented as a single directory, ,(tt [/gnu/store]).
+Each entry in ,(tt [/gnu/store]) has a file name composed of the hash
+of all the build inputs used to produce it, followed by a symbolic
+name.  For example, ,(tt [/gnu/store/yr9rk90jf…-gcc-7.1.0]) identifies
+a specific build of GCC 7.1.  A variant of GCC 7.1, for instance one
+using different build options or different dependencies, would get a
+different hash.  Thus, each store file name uniquely identifies build
+results, and build processes are ,(emph [referentially transparent]).
+This simplifies the reasoning on complex package compositions, but it
+also has nice properties such as supporting transactional upgrades and
+rollback “for free.”  While Guix and Nix are package managers, the
+Guix System Distribution (or GuixSD) as well as NixOS extends the
+functional paradigm to whole operating system deployments ,(ref :bib
+'dolstra2010:nixos).])
+      (p [While Guix implements this functional deployment paradigm
+pioneered by Nix, we explained in previous work that its
+implementation departs from Nix in interesting ways ,(ref :bib
+'courtes2013:functional).  First, while Nix relies on a custom
+domain-specific language (DSL), the Nix language, Guix instead chooses
+to devise a set of DSLs and data structures embedded in the
+general-purpose language Scheme.  The rationale was that this approach
+would ease the development of user interfaces and tools dealing with
+packages, and would allow users to benefit from everything a
+general-purpose language brings: compiler, debugger, REPL, editor
+support, libraries, and so on.  Four years later, Guix has indeed
+gained rich tooling that would have been harder to develop for an
+external DSL like Nix: ,(tt [guix lint]) checks style conformance and
+mistakes in package definition, ,(tt [guix refresh]) updates package
+definitions to the latest version of a package, user interfaces in
+Emacs and in Web browsers have been developed, tools to rewrite a
+package’s dependency graph are available from the command line and
+through the API, and so on.])
+      (p [In Guix, high-level package definitions like the one shown
+in Figure XXX are compiled to ,(emph [derivations]), the low-level
+representation of build actions inherited from Nix.  A derivation
+specifies: a command to run to perform the build (the “build
+program”), environment variables to be defined, and derivations whose
+build result it depends on.  Derivations are sent to a privileged
+daemon, which is responsible for building them on behalf of clients.
+The build daemon creates isolated environments (isolated “containers”
+in a chroot) in which it spawns the build program; since build
+environments are isolated, this ensures that build programs do not
+depend on undeclared inputs.])
+      (p [The second way in which Guix departs from Nix is by using
+the same language, Scheme, for all its functionality.  While package
+definitions in Nix can embed Bash or Perl snippets to refine build
+steps, Guix package definitions would instead embed Scheme snippets.
+Consequently, we have two strata of Scheme code: the “host code”,
+which provides the package definition, and the “build code”, which is
+staged for later execution by the build daemon.  Our thesis is that
+this single-language, “multi-tier” approach facilitates code reuse and
+code sharing among the several tiers, and that it can avoid a whole
+class of errors in the staged code—as opposed to generation of code in
+a “foreign” language, which is treated a mere strings where syntactic
+and semantic errors cannot be detected by the host code.])
+      (p [This paper focus on code staging in Guix.  Our contribution
+is twofold: we present G-expressions (or “gexps”), a new code staging
+mechanism implemented through mere syntactic extensions of the Scheme
+language, and its use in several areas of the “orchestration” programs
+of the operating system.  ,(numref :text [Section] :ident "design")
+describes the evolution of code staging in Guix from its inception, as
+described in ,(ref :bib 'courtes2013:functional), to gexps.  ,(numref
+:text [Section] :ident "experience") reports on our experience using
+gexps in a variety of areas in Guix and GuixSD.  ,(numref :text
+[Section] :ident "limitations") discusses limitations and future work.
+Finally ,(numref :text [Section] :ident "related") compares gexps to
+related work and ,(numref :text [Section] :ident "conclusion")
+concludes.]))
+   
+   (chapter :title [Design and Implementation]
+      :ident "design"
+      
+      (p [Scheme is a dialect of Lisp, and Lisp is famous for its
+homoiconicity—the fact that code has a direct representation as a data
+structure using the same syntax.  “S-expressions” or “sexps”, Lisp’s
+parenthecal expressions, thus look like they lend themselves to code
+staging.  In this section we show how we started with sexps to end up
+with gexps as an “augmented” version of sexps.])
+
+      (section :title [Staging Build Expressions]
+        
+       (figure
+          :legend [First attempt: build expressions as sexps.]
+          :ident "fig-build-sexp"
+
+          (prog :line #f
+             (source :language scheme :file "code/build-sexp.scm"
+                 :start ";!begin-build-sexp"
+                 :stop ";!end-build-sexp")))
+
+        (p [In previous work ,(ref :bib 'courtes2013:functional), we
+presented our first attempt at writing build expressions in Scheme.
+Figure ,(ref :figure "fig-build-sexp") shows an example that creates a
+derivation that, when built, converts the input image to JPEG, using
+the ,(tt [convert]) program from the ImageMagick package.  In this
+example, variable ,(tt [store]) represents the connection to the build
+daemon.  The ,(tt [package-derivation]) function takes the ,(tt
+[imagemagick]) package object and computes its corresponding
+derivation, while the ,(tt [add-to-store]) remote procedure call (RPC)
+instructs the daemon to add the file ,(tt [GuixSD.png]) to ,(tt
+[/gnu/store]).  The variable ,(tt [build]) contains our build program
+as an sexp, thanks to the apostrophe, which means “quote” in Lisp.
+Finally, ,(tt [build-expression->derivation]) takes the build program
+and computes the corresponding derivation without building it.  The
+user can then make an RPC to the build daemon asking it to build this
+derivation; only then will the daemon create an isolated environment
+and run our build program.])
+        (p [,(tt [build-expression->derivation]) arranges so that the
+build program, ,(tt [build]), is evaluated in a context where two
+extra variables are defined: ,(tt [%build-inputs]) contains a list
+that maps labels, such as ,(tt ["imagemagick"]), to file names, such
+as ,(tt [/gnu/store/…-imagemagick-6.9]), and ,(tt [%output]) contains
+the file name for the result of this derivation.  Thus, the ,(tt
+[assoc-ref]) calls in ,(tt [build]) allow it to retrieve the file name
+of ImageMagick.]))
+
+      (section :title [S-Expressions Are Not Enough]
+        
+        (p [Needless to say, this interface was extremely verbose and
+inconvenient—fortunately, users usually only had to deal with the more
+pleasant ,(tt [package]) interface shown in Figure XXX.  All these
+steps are necessary to define the derivation and its dependencies, but
+where does the verbosity come from?  First, we have to explicitly call
+,(tt [package-derivation]) for each package the expression refers to.
+Second, we have to explicitly the inputs with labels at the call site.
+Third, the build code has to use this ,(tt [assoc-ref]) call just to
+retrieve the ,(tt [/gnu/store]) file name of its inputs.  It is also
+error-prone: if we omit the ,(tt [#:inputs]) parameter, of if we
+mispell an input label, we will only find out when we build the
+derivation.])
+        (p [Another limitation not visible on a toy example but that
+became clear as we developed GuixSD it the cost of carrying this ,(tt
+[#:inputs]) argument down to the call site.  It forces programmers to
+carry not only the build expression, ,(tt [build]), but also the
+corresponding ,(tt [inputs]) argument down to the call site.  This
+essentially makes it very hard to compose build expressions.])
+        (p [While ,(tt [quote]) allowed to easily represent code as
+expected, it clearly lacks some of the machinery that would make
+staging in Guix more convenient.  It boilds down to two things: it
+lacks ,(emph [context])—the set of inputs associated with the
+expression—and it lacks the ability to serialize high-level objects—to
+replace a reference to a package object with its ,(tt [/gnu/store])
+file name.])))
+
+   (chapter :title [G-Expressions]
+      :ident "gexps"
+       
+      (p [This section describes the design and implementation of
+G-expressions, as well as extensions we added to address new use
+cases.])
+      
+      (section :title [Design Principle]
+
+       (figure
+          :legend [Creating a derivation from a gexp.]
+          :ident "fig-build-gexp"
+
+          (prog :line #f
+             (source :language scheme :file "code/build-sexp.scm"
+                 :start ";!begin-imagemagick-gexp"
+                 :stop ";!end-imagemagick-gexp")))
+
+        (p [We devised “G-expressions” as a mechanism to address
+these shortcomings.  In essence, a gexp bundles an sexp and its inputs
+and outputs, and it can be serialized with ,(tt [/gnu/store]) file
+names substituted as needed.  We first define two operators:
+
+,(itemize
+    (item [,(tt [gexp]), abbreviated ,(tt [#~]), is the counterpart of
+Scheme’s ,(tt [quasiquote]): it allows users to describe unevaluated
+code.])
+    (item [,(tt [ungexp]), abbreviated ,(tt [#$]), is the counterpart
+of Scheme’s ,(tt [unquote]): it allows quoted to refer to values in
+the host language.  These values can be of any of Scheme’s primitive
+data types, but we are specifically interested in values such as
+package objects that can be “compiled” to elements in the store.]))
+
+The example in Figure ,(ref :figure "fig-build-sexp"), rewritten as a
+gexp, is shown in Figure ,(ref :figure "fig-build-gexp").  We have all
+the properties we were looking for: the gexp contains carries
+information about its inputs that does not need to be passed at the
+,(tt [gexp->derivation]) call site, and the reference to ,(tt
+[imagemagick]), which is bound to a package object, is automatically
+rewritten to the corresponding store file name by ,(tt
+[gexp->derivation]),(footnote [Compared to Figure ,(ref :figure
+"fig-build-sexp"), the ,(tt [store]) argument has disappeared.  This
+is because we implemented ,(tt [gexp->derivation]) as a monadic
+function in the ,(emph [state monad]), where the state threaded
+through monadic function calls is that store parameter.  The use of a
+monadic interface is completely orthogonal to the gexp design though,
+so we will not insist on it.])  ,(tt [local-file]) returns a new
+Scheme record that denotes a file from the local file system to be
+added to the store.]) 
+        (p [Under the hood, ,(tt [gexp->derivation]) converts the
+gexp to an sexp, the final build program, stored under ,(tt
+[/gnu/store]).  In doing that, it replaces the ,(tt [ungexp]) forms
+,(tt [#$imagemagick]) and ,(tt [#$image]) with their corresponding
+,(tt [/gnu/store]) file names.  The special ,(tt [#$output]) form,
+which is used to refer to the output file name of the derivation, is
+itself replaced by a ,(tt [getenv]) call to retrieve its value at run
+time (a necessity since the output file name is not known at the time
+the gexp is serialized to disk.)])
+        (p [The ,(tt [gexp->derivation]) function has an optional
+,(tt [#:system]) argument that can be used to specify the system on
+which the derivation is to be built.  For instance, passing ,(tt
+[#:system "i686-linux"]) forces a 32-bit build on a GNU system running
+the kernel Linux.  The gexp itself is system-independent; it refers to
+the ,(tt [imagemagick]) package object, which is also
+system-independent.  Since the store file name of derivation outputs
+is a function of the system type, ,(tt [gexp->derivation]) must make
+sure to use the file name of ImageMagick corresponding to its ,(tt
+[#:system]) argument.  Therefore, this substitution must happen when
+,(tt [gexp->derivation]) is invoked, and ,(emph [not]) when the gexp
+is created.]))
+      
+      (section :title [Implementation]
+        
+        (figure
+           :legend [Macro expansion of a G-expression.]
+           :ident "fig-gexp-expansion"
+
+           (prog :line #f
+              (source :language scheme :file "code/gexp-expansion.scm"
+                 :start ";!begin-condensed"
+                 :stop ";!end-condensed"))
+           
+           (p [… is equivalent to:])
+           
+           (prog :line #f
+              (source :language scheme :file "code/gexp-expansion.scm"
+                 :start ";!begin-gexp-without-reader-macro"
+                 :stop ";!end-gexp-without-reader-macro"))
+           
+           (p [… which expands to:])
+   
+           (prog :line #f
+              (source :language scheme :file "code/gexp-expansion.scm"
+                 :start ";!begin-expansion"
+                 :stop ";!end-expansion")))
+
+        (p [As can be seen from the example above, gexps are
+first-class Scheme values: a variable can be bound to a gexp, and
+gexps can be passed around like any other value.  The implementation
+consists of two parts: a syntactic layer that turns ,(tt [#~]) forms
+into code that instantiates gexp records, and run-time support
+procedures to serialize gexps and to “lower” their inputs.])
+        (p [Scheme is extensible through macros, so ,(tt [gexp]) is a
+“hygienic” (referentially-transparent) macro (,(tt [#~]) is a “reader
+macro” that expands to a ,(tt [gexp]) form, nothing more.)  This is
+implemented as a library for GNU,(~)Guile, an R5RS/R6RS Scheme
+implementation, ,(emph [without any modification to its compiler]).
+Figure ,(ref :figure "fig-gexp-expansion") shows what our ,(tt [gexp])
+macro expands to.  In the expanded code, ,(tt [gexp-input]) returns a
+record representing a dependency, while ,(tt [make-gexp]) returns a
+record representing the whole gexp.  The expanded code defines a
+function of two arguments, ,(tt [proc]), that returns an sexp; the
+sexp is simply the body of the gexp with these two arguments inserted
+at the point where the original ,(tt [ungexp]) forms appeared.
+Intenally, ,(tt [gexp->sexp]), the function that converts gexps to
+sexps, calls this two-argument procedure passing it the store file
+names of ImageMagick and Emacs.  This strategy gives us constant-time
+substitutions.])
+        (p [The internal ,(tt [gexp-inputs]) function returns, for a
+given gexp, store, and system type, the derivations that the gexp
+depends on.  In this example, it returns the derivations for
+ImageMagick and Emacs, as computed by the ,(tt [package-derivation])
+function seen earlier.])
+        (p [XXX: compilers & expanders]))
+      
+      (section :title [Extensions]
+        
+        (p [cross-compilation, modules])))
+   
+   (chapter :title [Experience]
+      :ident "experience"
+      
+      (section :title [Package Build Procedures])
+      (section :title [initrd])
+      (section :title [System Services]))
+   
+   (chapter :title [Limitations]
+      :ident "limitations"
+      
+      (p [hygiene, modules in scope, cross-stage debugging info]))
+   
+   (chapter :title [Related Work]
+      :ident "related"
+      
+      ;; See refs at 
https://www.researchgate.net/publication/2632322_Writing_Hygienic_Macros_in_Scheme_with_Syntax-Case
+      (p (ref :bib 'dybvig1992:syntax-case)
+         (ref :bib 'kiselyov2008:metascheme)
+        (ref :bib 'serrano2010:multitier)
+        (ref :bib 'dolstra2010:nixos)))
+   
+   (chapter :title [Conclusion]
+      :ident "conclusion")
+   
+   (references))
+   
+;;; Local Variables:
+;;; coding: utf-8
+;;; ispell-local-dictionary: "american"
+;;; compile-command: "make gpce.pdf"
+;;; comment-start: ";;"
+;;; End:
diff --git a/doc/gpce-2017/staging.sbib b/doc/gpce-2017/staging.sbib
new file mode 100644
index 0000000..fadb80c
--- /dev/null
+++ b/doc/gpce-2017/staging.sbib
@@ -0,0 +1,22 @@
+(techreport dybvig1992:syntax-case
+  (author "R. Kent Dybvig")
+  (title "Writing Hygienic Macros in Scheme with Syntax-Case")
+  (institution "Indiana Computer Science Department")
+  (number "356")
+  (month "June")
+  (year "1992")
+  (url "http://www.cs.indiana.edu/~dyb/pubs/tr356.pdf";))
+
+(article serrano2010:multitier
+  (author "Manuel Serrano and Christian Queinnec")
+  (title "A Multi-tier Semantics for Hop")
+  (journal "Higher Order Symbol. Comput.")
+  (volume "23")
+  (number "4")
+  (month "November")
+  (year "2010")
+  (issn "1388-3690")
+  (pages "409--431")
+  (url "http://dx.doi.org/10.1007/s10990-010-9061-9";)
+  (publisher "Kluwer Academic Publishers")
+  (address "Hingham, MA, USA"))