77 lines
2.2 KiB
Plaintext
77 lines
2.2 KiB
Plaintext
|
.sp 1.5i
|
||
|
|
.nr H1 7
|
||
|
|
.NH
|
||
|
|
Hints to change the standard
|
||
|
|
.nh
|
||
|
|
.sp
|
||
|
|
.LP
|
||
|
|
We encoutered some difficulties when the compiler was developed. In this
|
||
|
|
chapter some hints are presented to change the standard, which would make
|
||
|
|
the implementation of the compiler less difficult. The semantics of Pascal
|
||
|
|
would not be altered by these adaptions.
|
||
|
|
.sp 2
|
||
|
|
.LP
|
||
|
|
\- Some minor changes in the grammar of Pascal from the user's point of view,
|
||
|
|
but which make the writing of an LL(1) parser considerably easier, could be:
|
||
|
|
.in +3m
|
||
|
|
.nf
|
||
|
|
field-list : [ ( fixed-part [ variant-part ] | variant-part ) ] .
|
||
|
|
fixed-part : record-section \fB;\fR { record-section \fB;\fR } .
|
||
|
|
variant-part : \fBcase\fR variant-selector \fBof\fR variant \fB;\fR { variant \fB;\fR } .
|
||
|
|
|
||
|
|
case-statement : \fBcase\fR case-index \fBof\fR case-list-element \fB;\fR { case-list-element \fB;\fR } \fBend\fR .
|
||
|
|
.fi
|
||
|
|
.in -3m
|
||
|
|
|
||
|
|
|
||
|
|
.LP
|
||
|
|
\- To ease the semantic checking on sets, the principle of qualified sets could
|
||
|
|
be used, every set-constructor must be preceeded by its type-identifier:
|
||
|
|
.nf
|
||
|
|
.ti +3m
|
||
|
|
set-constructor : type-identifier \fB[\fR [ member-designator { \fB,\fR member-designator } ] \fB]\fR .
|
||
|
|
|
||
|
|
Example:
|
||
|
|
t1 = set of 1..5;
|
||
|
|
t2 = set of integer;
|
||
|
|
|
||
|
|
The type of [3, 5] would be ambiguous, but the type of t1[3, 5] not.
|
||
|
|
.fi
|
||
|
|
|
||
|
|
|
||
|
|
.LP
|
||
|
|
\- Another problem arises from the fact that a function name can appear in
|
||
|
|
three distinct 'use' contexts: function call, assignment of function
|
||
|
|
result and as function parameter.
|
||
|
|
.br
|
||
|
|
Example:
|
||
|
|
.in +5m
|
||
|
|
.nf
|
||
|
|
\fBprogram\fR function_name;
|
||
|
|
|
||
|
|
\fBfunction\fR p(x : integer; function y : integer) : integer;
|
||
|
|
\fBbegin\fR .. \fBend\fR;
|
||
|
|
|
||
|
|
\fBfunction\fR f : integer;
|
||
|
|
\fBbegin\fR
|
||
|
|
f := p(f, f); (*)
|
||
|
|
\fBend\fR;
|
||
|
|
|
||
|
|
\fBbegin\fR .. \fBend\fR.
|
||
|
|
.fi
|
||
|
|
.in -5m
|
||
|
|
|
||
|
|
A possible solution in case of a call (also a procedure call) would be to
|
||
|
|
make the (possibly empty) actual-parameter-list mandatory. The assignment
|
||
|
|
of the function result could be changed in a \fIreturn\fR statement.
|
||
|
|
Though this would change the semantics of the program slightly.
|
||
|
|
.br
|
||
|
|
The above statement (*) would look like this: return p(f(), f);
|
||
|
|
|
||
|
|
|
||
|
|
.LP
|
||
|
|
\- Another extension to the standard could be the implementation of an
|
||
|
|
\fIotherwise\fR clause in a case-statement. This would behave exactly like
|
||
|
|
the \fIdefault\fR clause in a switch-statement in C.
|
||
|
|
.bp
|