change "deferred call queue" to "defer-call stack"

fix go101#284

pages/fundamentals/acknowledgements.html

@@ -218,6 +218,7 @@ <h1>Acknowledgments</h1>
 Rahul,
 zlqpzww,
 iridescentGray,
+balagrivine,
 etc.
 </p>
 

pages/fundamentals/control-flows-more.html

@@ -405,15 +405,14 @@ <h3>Deferred Function Calls</h3>
 
 <p>
 When a defer statement is executed, the deferred function call is not executed immediately.
-Instead, it is pushed into a deferred call queue maintained by its caller goroutine.
+Instead, it is pushed into a defer-call stack maintained by its caller goroutine.
 After a function call <code>fc(...)</code> returns (but has not fully exited yet)
 and enters its <a href="function-declarations-and-calls.html#exiting-phase">exiting phase</a>,
-all the deferred function calls pushed into the deferred call queue
-during executing the function call will be removed from the deferred call queue and executed,
+all the deferred function calls pushed into the defer-call stack
+during executing the function call will be removed from the defer-call stack and executed,
 in first-in, last-out order, that is, the reverse of the order
-in which they were pushed into the deferred call queue.
-Once all these deferred calls are executed,
-the function call <code>fc(...)</code> fully exits.
+in which they were pushed into the defer-call stack.
+Once all these deferred calls are executed, the function call <code>fc(...)</code> fully exits.
 </p>
 
 Here is a simple example to show how to use deferred function calls.
@@ -503,7 +502,7 @@ <h3>The Evaluation Moment of the Arguments of Deferred Function Calls</h3>
 <p>
 The arguments of a deferred function call
 are all evaluated at the moment when the corresponding defer statement is executed
-(a.k.a. when the deferred call is pushed into the deferred call queue).
+(a.k.a. when the deferred call is pushed into the defer-call stack).
 The evaluation results are used when the deferred call is executed later during
 the existing phase of the surrounding call (the caller of the deferred call).
 </p>

pages/fundamentals/defer-more.html

@@ -48,7 +48,7 @@ <h3>The Evaluation Moment of Deferred Function Values</h3>
 
 <div>
 The called function (value) in a deferred function call is evaluated
-when the call is pushed into the deferred call queue of the current goroutine.
+when the call is pushed into the defer-call stack of the current goroutine.
 For example, the following program will print <code>false</code>.
 
 <pre class="line-numbers"><code class="language-go">package main
@@ -70,7 +70,7 @@ <h3>The Evaluation Moment of Deferred Function Values</h3>
 
 The called function in a deferred function call may be a nil function value.
 For such a case, the panic will occur when the call to the nil function is invoked,
-instead of when the call is pushed into the deferred call queue of the current goroutine.
+instead of when the call is pushed into the defer-call stack of the current goroutine.
 An example:
 <pre class="line-numbers"><code class="language-go">package main
 
@@ -97,7 +97,7 @@ <h3>The Evaluation Moment of Receiver Arguments of Deferred Method Calls</h3>
 <p>
 As explained before, the arguments of a deferred function call are
 <a href="control-flows-more.html#argument-evaluation-moment">also evaluated when</a>
-the deferred call is pushed into the deferred call queue
+the deferred call is pushed into the defer-call stack
 of the current goroutine.
 </p>
 
@@ -117,7 +117,7 @@ <h3>The Evaluation Moment of Receiver Arguments of Deferred Method Calls</h3>
 	var t T
 	// "t.M(1)" is the receiver argument of the method
 	// call ".M(2)", so it is evaluated when the
-	// ".M(2)" call is pushed into deferred call queue.
+	// ".M(2)" call is pushed into defer-call stack.
 	defer t.M(1).M(2)
 	t.M(3).M(4)
 }
@@ -286,7 +286,7 @@ <h3>Kind-of Resource Leaking by Deferring Function Calls</h3>
 
 <div>
 
-A very large deferred call queue may also consume much memory,
+A very large defer-call stack may also consume much memory,
 and some resources might not get released in time if some calls are delayed too much.
 
 For example, if there are many files needed to be handled in a call to the following function,

pages/fundamentals/panic-and-recover-more-newer.html

@@ -15,7 +15,7 @@ <h3>Exiting Phases of Function Calls</h3>
 <div>
 <p>
 In Go, a function call may undergo an exiting phase before it fully exits.
-In the exiting phase, the deferred function calls pushed into the deferred call queue
+In the exiting phase, the deferred function calls pushed into the defer-call stack
 during executing the function call will be executed (in the inverse pushing order).
 When all of the deferred calls fully exit,
 the exiting phase ends and the function call also fully exits.
@@ -171,7 +171,7 @@ <h3>Associating Panics of Function Calls</h3>
 	if there was an old unrecovered panic associating with the nesting call before,
 	the old one will be replaced by the spread one.
 	For this case, the nesting call must had already entered its exiting phase for sure,
-	so the next deferred function call in its deferred call queue will be invoked.
+	so the next deferred function call in its defer-call stack will be invoked.
 </li>
 <li>
 	if there was not an unrecovered panic associating with the nesting call before,

pages/fundamentals/panic-and-recover-more-old.html

@@ -25,7 +25,7 @@ <h3>Exiting Phases of Function Calls</h3>
 <div>
 <p>
 In Go, a function call may undergo an exiting phase before it fully exits.
-In the exiting phase, the deferred function calls pushed into the deferred call queue
+In the exiting phase, the deferred function calls pushed into the defer-call stack
 during executing the function call will be executed (in the inverse pushing order).
 When all of the deferred calls fully exit,
 the exiting phase ends and the function call also fully exits.
@@ -177,7 +177,7 @@ <h3>Associating Panics and Goexit Signals of Function Calls</h3>
 	if there was an old unrecovered panic associating with the nesting call before,
 	the old one will be replaced by the spread one.
 	For this case, the nesting call has already entered its exiting phase for sure,
-	so the next deferred function call in the deferred call queue will be invoked.
+	so the next deferred function call in the defer-call stack will be invoked.
 </li>
 <li>
 	if there was not an unrecovered panic associating with the nesting call before,

pages/fundamentals/panic-and-recover-more.html

@@ -15,7 +15,7 @@ <h3>Exiting Phases of Function Calls</h3>
 <div>
 <p>
 In Go, a function call may undergo an exiting phase before it fully exits.
-In the exiting phase, the deferred function calls pushed into the deferred call queue
+In the exiting phase, the deferred function calls pushed into the defer-call stack
 during executing the function call will be executed (in the inverse pushing order).
 When all of the deferred calls fully exit,
 the exiting phase ends and the function call also fully exits.
@@ -162,7 +162,7 @@ <h3>Associating Panics and Goexit Signals of Function Calls</h3>
 	if there was an old unrecovered panic associating with the nesting call before,
 	the old one will be replaced by the spread one.
 	For this case, the nesting call must had already entered its exiting phase for sure,
-	so the next deferred function call in its deferred call queue will be invoked.
+	so the next deferred function call in its defer-call stack will be invoked.
 </li>
 <li>
 	if there was not an unrecovered panic associating with the nesting call before,