CHAPTER 4

IMPLICIT DELAYED SEMANTICS

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;]
sum(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.,

A

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;]
sum(<*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 (<*...*>)
each.

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

POS	FORM : INT ;

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 ;

into

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.

4.1
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:

POS  FORM,TERM,ATOM : - ;

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 21.4.5.4 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('(');
A;
WRITE('+');
B;
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
to:

<FORM:a> + <TERM:b>		->	 <FORM:  //[a;b;]
WRITE('(');
<*A*>;
WRITE('+');
<*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
write:

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:
WRITE('(');
<*A*>;
WRITE('+');
<*B*>;
WRITE(')');
>

4.2
Exercises

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:

VAR  LEFT_VALUE, RIGHT_VALUE = INT ;

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
in:

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:

VAR	  TYPE_STYLE = INT;

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

VAR	  ITALIC, BOLD, NORMAL = INT ;

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]:
<*t1*>;
<*t2*>;
>

Type styles are set by the following rules:

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

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

{  <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 ); >
FI

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).