Patch attached.
I'd like to sort copyright papers too, let me know what's necessary.
From 0b7a585ffb3a0e5b33e10101cc817dbf50736a2f Mon Sep 17 00:00:00 2001
From: Wilfred Hughes <[email protected]>
Date: Sun, 4 Sep 2016 20:14:49 -0400
Subject: [PATCH] Clarify bootstrap docs
* doc/ref/vm.texi: Add a sentence stating which parts of the bytecode
toolchain are in C, and which are in Scheme. This avoids confusion if
users assume Guile==Scheme and so assume the whole toolchain is in
Scheme.
---
doc/ref/vm.texi | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/doc/ref/vm.texi b/doc/ref/vm.texi
index 2f32c51..9766ccb 100644
--- a/doc/ref/vm.texi
+++ b/doc/ref/vm.texi
@@ -62,10 +62,12 @@ The obvious solution is to compile to a virtual machine that is
present on all Guile installations.
The easiest (and most fun) way to depend on a virtual machine is to
-implement the virtual machine within Guile itself. This way the
-virtual machine provides what Scheme needs (tail calls, multiple
-values, @code{call/cc}) and can provide optimized inline instructions
-for Guile (@code{cons}, @code{struct-ref}, etc.).
+implement the virtual machine within Guile itself. Guile contains a
+bytecode interpreter (written in C) and a Scheme to bytecode compiler
+(written in Scheme). This way the virtual machine provides what Scheme
+needs (tail calls, multiple values, @code{call/cc}) and can provide
+optimized inline instructions for Guile (@code{cons}, @code{struct-ref},
+etc.).
So this is what Guile does. The rest of this section describes that VM
that Guile implements, and the compiled procedures that run on it.
--
2.9.3
