This chapter is here to point out that from now on, the ~delay in
	  ~delayed ~semantics will be made implicitly.	(Chapter 2 illustrated
	  the advantages of using delayed semantics).

	  On the righthand side of a "->" rulew, in the give-phrase, there
	  appears this notation:

		    < part_of_speech : program >

	  as in the right side of:

		    <FORM:a>  +  <TERM:b>	  ->	    ~<FORM: ~sum(a,b) ~>

	  From now on, the system will wrap up the program part within //...\\,
	  as in:

		    <FORM:a>  +  <TERM:b>	  ->	    <FORM: ~//[a;b;]
									     ~\\		   >

	  This delays the evaluation of semantics until after the rewriting
	  process is done.

	  Also, inside the new //...\\, each appearence of a variable, e.g.,


	  will be ~invoked, i.e., surrounded by <*...*>, as in:

		    <* A *>

	  if context demands that.

	  For example, when we write:

		    <FORM:a>  +  <TERM:b>	  ->	    <FORM: sum(a,b) >

	  we really get:

		    <FORM:a>  +  <TERM:b>	  ->	    <FORM: //[a;b;]
									     \\			>

	  The execution of ~sum is delayed until whatever time that this FORM's
	semantics may be invoked.  At such time, ~sum will execute, acquiring
	its two values by invoking each of ~a and ~b.  The delay imposed
	around this program was also cast around the semantics referenced by
	~a and ~b.  That delay in ~a and ~b is overcome by invoking (<*...*>)

	To make all this consistent, the type that you declare with a part-
	of-speech, as in:


	is really declared to be:

		POS	FORM : //INT\\ ;

	That is, the semantic entity associated with a FORM is a ~delayed
	whatever you wanted.

	In summary, we do three things to get everything as delayed semantics:

	    1)	We implicitly change the declaration

			POS  FORM : T ;


			POS  FORM : //T\\ ;

		(no matter what part-of-speech is declared).

	    2)	Inside a rule's semantics specification, within the resulting
		    part-of-speech (on the righthand side of "->"), we enclose the
		    whole thing in //...\\.

		3)  In there, we also turn appearences of the lefthand side
		    variables (A and B) into invocations of those variables (<*A*>
		    and <*B*>), if context demands that.

Leaving Behind The Explicit Use Of The Type BASIC_PROCESS

	  Now that we introduce automatically one layer of delay for any
	  semantic type, the benefits of declaring parts-of-speech with the type
	  BASIC_PROCESS is redundant.	 Let's change our BASIC_PROCESS semantics
	for FORMs, TERMs, and ATOMs.  We now declare:


	The appearence of "-", where a type is expected, means the semantics
	yields no value upon invocation, rather, it exists just for the
	performance of side-effects, like writing characters to your terminal.

	Our transformation upon POS declarations translates this artificial
	"-" into the type //\\, which is in fact the type BASIC_PROCESS
	(Section 2.1 or or 23.6).  The "-" is an artifact used to
	denote that there is no value delivered from the (implicit) invocation.

	We now write the FORM rule concisely as follows:

		<FORM:a>  +  <TERM:b>	   ->      <FORM:  WRITE('(');
							   WRITE(')');	  >

	The implicit translation, inserting <*...*> and //...\\, renders this
	specification to be identical to our original BASIC_PROCESS
	specification.  That is, this latest rule's specification translates

		    <FORM:a> + <TERM:b>		->	 <FORM:  //[a;b;]
										 WRITE(')');  \\ >

	  Note that the insertions of <*...*> and //...\\ occur only within the
	  semantics specification, that is, the ... in:

		    < part_of_speech : ... >

	  This occurs only in the semantics of parts-of-speech appearing in
	  the righthand side (of "->").

	  These transformations do not occur elsewhere.	 For example, we still

		    SHOW  <FORM:f>  .		->	     <*F*>;

	  The invocation of F on the righthand side is just a regular program.
	  (It is not the semantics of a part-of-speech).  Hence, here we still
	  have to supply the <*...*>.

	  NOTE:   We will always take advantage of the implicit //...\\ in
		    the "<FORM:...:>".	(We will never write the // nor \\ there).

		    However, throughout the vast majority of this text, we will
		    write the optional <* and *>, i.e., we will invoke each
		    variable explicitly, as we believe this lends the most clarity
		    to the novice.

		    Thus, we will write the "<FORM> + <TERM>" rule as:

				<FORM:a>  +	 <TERM:b>	  ->	   <FORM:


	  1)	    Let's declare the part-of-speech BOP by:

			POS  BOP[4] : INT ;

		Let's declare two global variables which will be top-down
		    context for the semantics of any BOP:


		    We introduce the operator "+", with semantics, as:

				+	  ->	    <BOP[4]: LEFT_VALUE + RIGHT_VALUE >

		    and for "*":

				*	  ->	    <BOP[3]: LEFT_VALUE * RIGHT_VALUE >

		    Here is the EXPR-BOP-EXPR rule with semantics:

				<EXPR[i]:x>	 <BOP[j]:y>	 <EXPR[k]:z>     ->

					  IF	i =< j  &  k < j	THEN

						    <EXPR[j]:   HOLDING	 LEFT_VALUE:= X;
										 RIGHT_VALUE:= X;

								    GIVE   Y

								    ENDHOLD	    >		     FI

		    There is a bug here which causes the following errors:

				5+6	  =	    10
				3*20	  =	    9

		    Fix the bug.

	  2)	    Consider a text formatter, like TeX.	Its job is to print a
		    text file where boldface and italics may occur.  You insert
		    "\ital" in front of text that you want italicized, and insert
		    "\bold" in front of text you want in boldface.

		    The italics or boldface will be in force throughout the rest
		    of the text, until you change again by specifying "\ital" or
		    "\bold".  You can limit the reign of a type style by enclosing
		    the "\ital" or "\bold" along with text within brackets "{}", as

				This sentence has an {\ital italic} word.

		    Only one word is italicized in this example.

		    Assume we have a function TYPESET which takes in one character
		    along with an integer telling which type style to use:

				TYPESET( char , integer )

		    Here are the parts-of-speech for this typesetting language:

				POS	  TEXT[2]: - ;

						  " The semantic action is to generate
						    phototypesetter commands that put this
						    text on paper, (i.e., call TYPESET) for
						    each character.

						    These semantics read the top-down
						    context global variable TYPE_STYLE to
						    know which type style to use. "

				POS	  CHAR: INT ;	"The semantics are the
								 character's ASCII code."

		    We declare the top-down context variable:


		    For reading convenience, let's declare some constants to
		represent TYPESET's possible type styles:


				ITALIC:= -1;
				BOLD:= -2;
				NORMAL:= -3;

		    We now show the workhorse rule:

			 <CHAR: c >	  ->	    <TEXT:	TYPESET( c, TYPE_STYLE );  >

		    Individual characters like these may be combined into TEXT:

			 <TEXT[i]: t1>  <TEXT[1]: t2>	   ->	    <TEXT[2]:

		    Type styles are set by the following rules:

			 \ital  <TEXT: t>		 ->	  <TEXT[2]:
									  TYPE_STYLE:= ITALIC;

			 \bold  <TEXT: t>		 ->	  <TEXT[2]:
									  TYPE_STYLE:= BOLD;

			 {  <TEXT: t>  }		 ->	  <TEXT:  ??  >

		a)  Fill in the "??" appropriately, so that any type style change
		    made within the given <TEXT> between the brackets remains
		    confined to within those brackets.

		b)  This grammar is ambiguous, as the sentence:

				This sentence has an {\ital italic} word.

		    can be interpretted as <TEXT> in two ways.	On one hand, this
		    sentence could come out as intended, where no brackets appear
		    on the piece of paper, and the word "italic" is italicized.
		    On the other hand, the brackets could be interpretted as
		    part of the literal text of the sentence, and therefore wind
		    up on the piece of paper as they appear here, with no word
		    being italicized.

		    We remove this ambiguity and make "\" a reserved character,
		    so that "\" will never appear on the resulting piece of paper,
		    by replacing the <CHAR> rule with:

			 <CHAR: c>	    ->    IF  c <> '\'	THEN

							 <TEXT: TYPESET( c, TYPE_STYLE ); >

		    This rule generates the <TEXT> interpretation for the character
		    only if it is not equal ("<>") to "\".

		    Modify this rule so that the brackets "{}" are also reserved
		    characters.  (Use "&" to denote logical ANDing of conditions,
		    as introduced in Section 22.1.2).