matiec: comparison stage1

equal deleted inserted replaced

-:41d4ac0b4821
+:c62a4078f269
 #include "iec.y.hh"
 /* The interface through which bison and flex interact. */
 #include "stage1_2_priv.hh"
+#include "../absyntax_utils/add_en_eno_param_decl.hh"	/* required for  add_en_eno_param_decl_c */
 /* an ugly hack!!
 * We will probably not need it when we decide
 *  to cut down the abstract syntax down to size.
 *  We keep it as it is until we get to write
 /* Where do these tokens belong?? They are missing from the standard! */
 /* NOTE: There are other tokens related to these 'EN' ENO', that are also
 * missing from the standard. However, their location in the annex B is
 * relatively obvious, so they have been inserted in what seems to us their
 * correct place in order to ease understanding of the parser...
+*
+* please read the comment above the definition of 'variable' in section B1.4 for details.
 */
 %token	EN
 %token	ENO
 %type <leaf>	en_identifier
 %type <leaf>	eno_identifier
 /*********************/
 /* B 1.4 - Variables */
 /*********************/
 /* NOTE: The standard is erroneous in it's definition of 'variable' because:
 *         - The standard considers 'ENO' as a keyword...
-*         - ...which means that it may never be parsed as an 'identifier'...
+*         - ...=> which means that it may never be parsed as an 'identifier'...
-*         - ...and therefore may never be used as the name of a variable inside an expression.
+*         - ...=> and therefore may never be used as the name of a variable inside an expression.
 *         - However, a function/FB must be able to assign the ENO parameter
 *           it's value, doing it in an assignment statement, and therefore using the 'ENO'
 *           character sequence as an identifier!
-*        The solution we found was to also allow the ENO keyword to be
+*        The obvious solution is to also allow the ENO keyword to be
 *         used as the name of a variable. Note that this variable may be used
 *         even though it is not explicitly declared as a function/FB variable,
 *         as the standard requires us to define it implicitly in this case!
-*         We could not therefore handle the ENO as a normal variable that would
+*        There are three ways of achieving this:
-*         go into the previously_declared_variable symbol table, as we may need to
+*          (i) simply not define EN and ENO as keywords in flex (lexical analyser)
-*         allow it to be used as a variable even though it is not declared as such!
+*              and let them be considered 'identifiers'. Aditionally, add some code
+*              so that if they are not explicitly declared, we add them automatically to
+*              the declaration of each Functions and FB, where they would then be parsed
+*              as a previously_declared_variable.
+*              This approach has the advantage the EN and ENO would automatically be valid
+*              in every location where it needs to be valid, namely in the explicit declaration
+*              of these same variables, or when they are used within expressions.
+*              However, this approach has the drawback that
+*              EN and ENO could then also be used anywhere a standard identifier is allowed,
+*              including in the naming of Functions, FBs, Programs, Configurations, Resources,
+*              SFC Actions, SFC Steps, etc...
+*              This would mean that we would then have to add a lexical analysis check
+*              within the bison code (syntax analyser) to all the above constructs to make sure
+*              that the identifier being used is not EN or ENO.
+*         (ii) The other approach is to define EN and ENO as keywords / tokens in flex
+*              (lexical analyser) and then change the syntax in bison to acomodate
+*              these tokens wherever they could correctly appear.
+*              This has the drawback that we need to do some changes to the synax defintion.
+*        (iii) Yet a another option is to mix the above two methods.
+*              Define EN and ENO as tokens in flex, but change (only) the syntax for
+*              variable declaration to allow these tokens to also be used in declaring variables.
+*              From this point onwards these tokens are then considered a previously_declared_variable,
+*              since flex will first check for this before even checking for tokens.
+*
+*              I (Mario) cuurretnly (2011) believe the cleanest method of achieving this goal
+*              is to use option (iii)
+*              However, considering that:
+*                - I have already previously implemented option (ii);
+*                - option (iii) requires that flex parse the previously_declared_variable
+*                   before parsing any token. We already support this (remeber that this is
+*                   used mainly to allow some IL operators as well as PRIORITY, etc. tokens
+*                   to be used as identifiers, since the standard does not define them as keywords),
+*                   but this part of the code in flex is often commented out as usually people do not expect
+*                   us to follow the standard in the strict sense, but rather consider those
+*                   tokens as keywords;
+*                considering the above, we currently carry on using option (ii).
 */
 variable:
 symbolic_variable
 | prev_declared_direct_variable
 | eno_identifier
 any_record_variable:
 any_symbolic_variable
 ;
-field_selector: any_identifier;
+field_selector:
+any_identifier
+| eno_identifier
+;
 /* NOTE: The formal definition of the standard is erroneous, as it simply does not
 *       consider the EN and ENO keywords!
 *       The semantic description of the languages clearly states that these may be
 *       used in several ways. One of them is to declare an EN input parameter.
 *       We have added the 'en_param_declaration' clause to cover for this.
+*
+*       Please read the comment above the definition of 'variable' in section B1.4 for details.
 */
 en_param_declaration:
 en_identifier ':' BOOL ASSIGN boolean_literal
 {$$ = new en_param_declaration_c($1, new bool_type_name_c(locloc(@$)), $5, new explicit_definition_c(), locloc(@$));}
 | en_identifier ':' BOOL ASSIGN integer
 /* NOTE: The formal definition of 'var_output_init_decl' as defined in the standard is erroneous,
 *       as it does not allow a user defined 'ENO' output parameter. However,
 *       The semantic description of the languages clearly states that this is allowed.
 *       We have added the 'eno_param_declaration' clause to cover for this.
+*
+*       Please read the comment above the definition of 'variable' in section B1.4 for details.
 */
 var_output_init_decl:
 var_init_decl
 | eno_param_declaration
 ;
 /* NOTE: The formal definition of the standard is erroneous, as it simply does not
 *       consider the EN and ENO keywords!
 *       The semantic description of the languages clearly states that these may be
 *       used in several ways. One of them is to declare an ENO output parameter.
 *       We have added the 'eno_param_declaration' clause to cover for this.
+*
+*       Please read the comment above the definition of 'variable' in section B1.4 for details.
 */
 eno_param_declaration:
 eno_identifier ':' BOOL
 /* NOTE We do _NOT_ include this variable in the previously_declared_variable symbol table!
 *      Please read the comment above the definition of 'variable' for the reason for this.
 function_declaration:
 /*  FUNCTION derived_function_name ':' elementary_type_name io_OR_function_var_declarations_list function_body END_FUNCTION */
 function_name_declaration ':' elementary_type_name io_OR_function_var_declarations_list function_body END_FUNCTION
 	{$$ = new function_declaration_c($1, $3, $4, $5, locloc(@$));
+	 add_en_eno_param_decl_c::add_to($$); /* add EN and ENO declarations, if not already there */
 	 variable_name_symtable.pop();
 	 direct_variable_symtable.pop();
 	 if (allow_function_overloading) {
 	   switch (library_element_symtable.find_value($1)) {
 	     case prev_declared_derived_function_name_token:
 	 }
 	}
 /* | FUNCTION derived_function_name ':' derived_type_name io_OR_function_var_declarations_list function_body END_FUNCTION */
 | function_name_declaration ':' derived_type_name io_OR_function_var_declarations_list function_body END_FUNCTION
 	{$$ = new function_declaration_c($1, $3, $4, $5, locloc(@$));
+	 add_en_eno_param_decl_c::add_to($$); /* add EN and ENO declarations, if not already there */
 	 variable_name_symtable.pop();
 	 direct_variable_symtable.pop();
 	 if (allow_function_overloading) {
 	   switch (library_element_symtable.find_value($1)) {
 	     case prev_declared_derived_function_name_token: /* do nothing, already in map. */ break;
 function_block_declaration:
 FUNCTION_BLOCK derived_function_block_name io_OR_other_var_declarations_list function_block_body END_FUNCTION_BLOCK
 	{$$ = new function_block_declaration_c($2, $3, $4, locloc(@$));
+	 add_en_eno_param_decl_c::add_to($$); /* add EN and ENO declarations, if not already there */
 	 library_element_symtable.insert($2, prev_declared_derived_function_block_name_token);
 	 /* Clear the variable_name_symtable. Since
 	  * we have finished parsing the function block,
 	  * the variable names are now out of scope, so
 	  * are no longer valid!
 /* The following is not required, as the sendto_identifier_token returned by flex will
 * also include the 'ENO' identifier.
 * The resulting abstract syntax tree is identical with or without this following rule,
 * as both the eno_identifier and the sendto_identifier are stored as
 * an identifier_c !!
+*
+* To understand why we must even explicitly consider the use of ENO here,
+* please read the comment above the definition of 'variable' in section B1.4 for details.
 */
 /*
 | eno_identifier SENDTO
 	{$$ = new il_assign_out_operator_c(NULL, $1, locloc(@$));}
 */
 /* The following is not required, as the sendto_identifier_token returned by flex will
 * also include the 'ENO' identifier.
 * The resulting abstract syntax tree is identical with or without this following rule,
 * as both the eno_identifier and the sendto_identifier are stored as
 * an identifier_c !!
+*
+* To understand why we must even explicitly consider the use of ENO here,
+* please read the comment above the definition of 'variable' in section B1.4 for details.
 *
 * NOTE: Removing the following rule also removes a shift/reduce conflict from the parser.
 *       This conflict is not really an error/ambiguity in the syntax, but rather
 *       due to the fact that more than a single look-ahead token would be required
 *       to correctly parse the syntax, something that bison does not support.
 /* The following is not required, as the sendto_identifier_token returned by flex will
 * also include the 'ENO' identifier.
 * The resulting abstract syntax tree is identical with or without this following rule,
 * as both the eno_identifier and the sendto_identifier are stored as
 * an identifier_c !!
+*
+* To understand why we must even explicitly consider the use of ENO here,
+* please read the comment above the definition of 'variable' in section B1.4 for details.
 */
 /*
 | eno_identifier SENDTO variable
 	{$$ = new output_variable_param_assignment_c(NULL, $1, $3, locloc(@$));}
 */
 /* The following is not required, as the sendto_identifier_token returned by flex will
 * also include the 'ENO' identifier.
 * The resulting abstract syntax tree is identical with or without this following rule,
 * as both the eno_identifier and the sendto_identifier are stored as
 * an identifier_c !!
+*
+* To understand why we must even explicitly consider the use of ENO here,
+* please read the comment above the definition of 'variable' in section B1.4 for details.
 */
 /*
 | NOT eno_identifier SENDTO variable
 	{$$ = new output_variable_param_assignment_c(new not_paramassign_c(locloc(@$)), $2, $4, locloc(@$));}
 */

changeset 315	c62a4078f269
parent 311	8fcea60029de
child 328	66cd5d9893dd