Subject: SDL-News: Comments to textual algorithms
From: Ralf Schröder (r.schroeder#informatik.hu-berlin.de)
Date: Tue Jul 14 1998 - 13:16:15 GMT
Dear colleagues,
Here some comments to new syntactic constructs in SDL:
"Textual algorithms in SDL/GR" TDB607 in Berlin
(forum member) ftp:ftp.sdl-forum.org/sg10/1998/berlinq6/tdb607.doc
1)
There is a different use of ';' resp. <end> in the production
of <textual procedure definition> and "normal" <procedure definition>.
Example:
procedure p
fpar i Integer; returns Boolean;
start; return true;
endprocedure;
procedure p
fpar i Integer returns Boolean;
return true;
The rules for no/optional/mandatory ';' should be the same for all
notations. Technically, LR(1) parser technology has problems to find the
difference between normal and textual procedure definitions.
The situation for operator definitions is similar to procedures, here
the syntax is already crap because of the external operators:
Example:
operator op ; fpar i Integer; returns Boolean;
/* ^ optional ';' */
endoperator;
operator op fpar in/out Integer returns Boolean external;
Hopefully, the authors know the consequences of <operator procedure signature>
for external operators. These operators cannot be replaced by an SDL-like
operator definition in the model, as there are no operators with
out-parameters in SDL at the moment.
For the implementation of these rules I used optional ';' in all situations
to cover all rules. However, the resulting grammar rule for the parser
is extremely ugly. May be it works for procedures, too.
2)
The construction
endprocedure <opt_name>; / endoperator <opt_name>;
is optional for textual notations.
As a result, the following text has two possible interpretations:
Example:
procedure p;
procedure pp; {}
endprocedure;
...
-------------------------------
procedure p;
procedure pp; {}
endprocedure;
...
The parser has no chance to decide to which the endprocedure belongs.
3)
The "{}" pair can be omitted on the top level of the
procedure body:
procedure p;
returns 42;
This causes some trouble in the parsing process if you see:
procedure p;
procedure pp
There are at least two continuations:
a) ...
procedure pp rpc(1);
:a qualified rpc call in a textual procedure.
b) procedure pp; start; stop; endprocedure;
start; stop;
endprocedure p;
:a local procedure in a normal procedure definition.
This is a look-ahead of 3, not good for good old yacc. A solution
would be difficult to implement.
Because of 2) and 3) we should force "{}" on top level and drop
optional end... keywords.
4)
Some examples for conflicts:
- if true then if false then return 1 else return 2
- for (i=1,i<10) for(j=1,j<5) ; then count = count+1; /* count = ??? */
and already well known:
- call rpc to call get_pid to sender
- call rcp to call get_pid via g
- call rpc to call get_pid to sender via g
- op(call rpc via g1,g2) /* g2 Integer, op : XXX, Integer -> YYY */
same for timer
- op(call rpc timer t1, t2)
Z.100 and the proposal are not clear what the semantics of these
constructs are.
5)
Omitting task and call cause some trouble in the parsing process of
expressions (need some grammar reconstructions to avoid reduce/shift/reduce
conflicts). May be tool vendors should have a look to that!
6)
loops:
for(Integer i := 1, i<10, 1) {
...
} then continue;
<continue> can be used within a <loop statement>. Hence, the
loop body can be entered again. No contradiction with respect to
the model.
7)
Virtual and inherited procedures
virtual procedure p; fpar i Integer;
endprocedure;
redefined procedure p; { ... }
According to the transformation model
- the base procedure(s) cannot have a start state, the body of redef. p
is transformed to a non virtual start transition.
- states of the base procedure can never be reached from the redef. p.
However, it is a good idea not to provide nextstate/join statements!!!
Consequence: Virtuality and inheritance can be used to (change)/reuse the
signature of a procedure, nothing else.
"Algorithmic" procedures cannot be derived from each other:
procedure p; fpar i Integer;; /* strange syntax cf. remark 3 */
procedure pp inherits p; { ... } /* pp has 2 start transitions */
This archive was generated by hypermail 2a23 : Sun Jun 16 2013 - 10:41:40 GMT