about summary refs log tree commit diff stats
diff options
context:
space:
mode:
authorKartik K. Agaram <vc@akkartik.com>2016-04-25 22:35:51 -0700
committerKartik K. Agaram <vc@akkartik.com>2016-04-25 22:35:51 -0700
commitd350348120aafc6b6a6895a090f9b856b3a6a2b0 (patch)
tree62ed1711267066cdc361c0b8db864042b6880079
parent32b8fac2799ac7cec613e84a3eb9c009141b6a3a (diff)
downloadmu-d350348120aafc6b6a6895a090f9b856b3a6a2b0.tar.gz
2867
-rw-r--r--033address.cc15
-rw-r--r--html/033address.cc.html15
2 files changed, 18 insertions, 12 deletions
diff --git a/033address.cc b/033address.cc
index 29beec1e..31405c86 100644
--- a/033address.cc
+++ b/033address.cc
@@ -14,16 +14,18 @@
 //:
 //: The notion of 'lookup' isn't an instruction like 'add' or 'subtract'.
 //: Instead it's an operation that can be performed when reading any of the
-//: ingredients of an instruction, and when writing to any of the products.
-//: Modern computers provide efficient support for addresses and lookups,
-//: making this a realistic feature.
+//: ingredients of an instruction, and when writing to any of the products. To
+//: write to the payload of an ingredient rather than its value, simply add
+//: the /lookup property to it. Modern computers provide efficient support for
+//: addresses and lookups, making this a realistic feature.
 //:
 //: To recap: an address is a bookmark to some potentially large payload, and
 //: you can replace any ingredient or product with a lookup to an address of
 //: the appropriate type. But how do we get addresses to begin with? That
 //: requires a little more explanation. Once we introduce the notion of
 //: bookmarks to data, we have to think about the life cycle of a piece of
-//: data and its bookmark. Otherwise several bad outcomes can result (and
+//: data and its bookmarks (because remember, bookmarks can be copied around
+//: just like anything else). Otherwise several bad outcomes can result (and
 //: indeed *have* resulted in past languages like C):
 //:
 //:   a) You can run out of memory if you don't have a way to reclaim
@@ -34,8 +36,9 @@
 //:   problems can be very hard to track down, and they can also be exploited
 //:   to break into your computer over the network, etc.
 //:
-//: To avoid these problems, we introduce a *reference count* or refcount. The
-//: life cycle of a bit of data accessed through addresses looks like this.
+//: To avoid these problems, we introduce the notion of a *reference count* or
+//: refcount. The life cycle of a bit of data accessed through addresses looks
+//: like this.
 //:
 //:    We create space in computer memory for it using the 'new' instruction.
 //:    The 'new' instruction takes a type as an ingredient, allocates
diff --git a/html/033address.cc.html b/html/033address.cc.html
index cdae9d7c..04791321 100644
--- a/html/033address.cc.html
+++ b/html/033address.cc.html
@@ -51,16 +51,18 @@ body { font-size: 12pt; font-family: monospace; color: #eeeeee; background-color
 <span class="Comment">//:</span>
 <span class="Comment">//: The notion of 'lookup' isn't an instruction like 'add' or 'subtract'.</span>
 <span class="Comment">//: Instead it's an operation that can be performed when reading any of the</span>
-<span class="Comment">//: ingredients of an instruction, and when writing to any of the products.</span>
-<span class="Comment">//: Modern computers provide efficient support for addresses and lookups,</span>
-<span class="Comment">//: making this a realistic feature.</span>
+<span class="Comment">//: ingredients of an instruction, and when writing to any of the products. To</span>
+<span class="Comment">//: write to the payload of an ingredient rather than its value, simply add</span>
+<span class="Comment">//: the /lookup property to it. Modern computers provide efficient support for</span>
+<span class="Comment">//: addresses and lookups, making this a realistic feature.</span>
 <span class="Comment">//:</span>
 <span class="Comment">//: To recap: an address is a bookmark to some potentially large payload, and</span>
 <span class="Comment">//: you can replace any ingredient or product with a lookup to an address of</span>
 <span class="Comment">//: the appropriate type. But how do we get addresses to begin with? That</span>
 <span class="Comment">//: requires a little more explanation. Once we introduce the notion of</span>
 <span class="Comment">//: bookmarks to data, we have to think about the life cycle of a piece of</span>
-<span class="Comment">//: data and its bookmark. Otherwise several bad outcomes can result (and</span>
+<span class="Comment">//: data and its bookmarks (because remember, bookmarks can be copied around</span>
+<span class="Comment">//: just like anything else). Otherwise several bad outcomes can result (and</span>
 <span class="Comment">//: indeed *have* resulted in past languages like C):</span>
 <span class="Comment">//:</span>
 <span class="Comment">//:   a) You can run out of memory if you don't have a way to reclaim</span>
@@ -71,8 +73,9 @@ body { font-size: 12pt; font-family: monospace; color: #eeeeee; background-color
 <span class="Comment">//:   problems can be very hard to track down, and they can also be exploited</span>
 <span class="Comment">//:   to break into your computer over the network, etc.</span>
 <span class="Comment">//:</span>
-<span class="Comment">//: To avoid these problems, we introduce a *reference count* or refcount. The</span>
-<span class="Comment">//: life cycle of a bit of data accessed through addresses looks like this.</span>
+<span class="Comment">//: To avoid these problems, we introduce the notion of a *reference count* or</span>
+<span class="Comment">//: refcount. The life cycle of a bit of data accessed through addresses looks</span>
+<span class="Comment">//: like this.</span>
 <span class="Comment">//:</span>
 <span class="Comment">//:    We create space in computer memory for it using the 'new' instruction.</span>
 <span class="Comment">//:    The 'new' instruction takes a type as an ingredient, allocates</span>