The SCOOP Language

In Appendix A we have given a context free grammar for parsing SCOOP programs. This is an earlier Java-like grammar with some added and some modified productions to parse SCOOP language constructs. In the appendix, we have marked some productions with the letter ‘S’ to indicate that these productions are particular to our proposed SCOOP language. As usual in a parser grammar, there are two kinds of symbols. We define our convention for the grammar symbols in the table below.

49

Kind of Symbols Description Examples Terminals Keywords and Operators in small

alphabets

int, public, statebinding, +, ++,

Identifiers in small alphabets id, o_id, st_id Non Terminals enclosed in angle brackets <var_dec>, <class>,

<stm> Table 5.1 SCOOP Grammar Symbols

We discuss in some detail below a few of the productions for parsing SCOOP language constructs. The numbering of the productions we use is according to the numbering in Appendix A.

Production no. 4 in Appendix A is as follows

<class>  <st_dec_list> class cls_id { <cls_body> }

This production allows parsing the stated class declaration, e.g. the File class in Figure 5.1. The <st_dec_list> non-terminal would parse the declaration of state name of a class just before parsing the keyword class.

Production no. 5 in Appendix A is as follows <st_dec_list>  [ state ( <st_list> ) ]

This production allows parsing the state name of a stated class using the <st_list> non- terminal. It is derived from Production no. 4.

Production no. 6 in Appendix A is as follows <st_dec_list>  Є

This production allows stopping the expansion of parsing the list of state names of a class.

Production no. 7 in Appendix A is as follows <st_list>  <st_list> , <st_id>

50

This production allows parsing the repetition of state names while parsing the declaration of the list of state names using Production no. 5.

Production no. 8 in Appendix A is as follows <st_list>  <st_id>

This production allows parsing the single state name when there is only one state declared for a class.

Production no. 9 in Appendix A is as follows <st_id>  st_id

This production allows parsing the actual state name given by the programmer. In this production we represent the actual state name by the terminal st_id.

Production no. 10 in Appendix A is as follows

<cls_body>  <var_dec_list> < st_binding> <cls_m_list> <c_s_m_list>

This production allows parsing the internal body of a class and is derived from Production no. 4. As is obvious, the class body should first of all allow the variable declaration, followed by a state binding, followed by a list of the methods of the class, followed by the list of the state structures in the class.

Production no. 18 in Appendix A is as follows <st_binding>  statebinding { <b_list> }

This production allows parsing the state binding and is derived from Production no. 10. The <b_list> non-terminal allows parsing the list of binding state name, with a binding rule.

Production no. 19 in Appendix A is as follows <b_list>  <b_list> , <bind>

51

This production allows parsing the binding of state names with the binding rule. This is derived from Production no. 18.

Production no. 77 in Appendix A is as follows <c_s_m_list><c_s_m_list> <c_s_method>

This production allows parsing of the list of state structures, i.e. a possible repetition of many state structures. It is derived from Production no. 10. An example of a state structure is given in Figure 7.1.

Production no. 78 in Appendix A is as follows

<c_s_method>  <s_list> { <s_v_d_lst><s_m_list> }

This production allows parsing a single state structure. It is derived from Production no. 78. The <s_list> non-terminal would parse the state name of the state structure. An example of a state structure is given in Figure 7.1

Production no. 79 in Appendix A is as follows <s_m_list> <s_m_list> <s_method>

This production allows parsing the list of methods in the state structure, i.e. a list of methods particular to a state. It is derived from Production no. 79.

Production no. 81 in Appendix A is as follows

<s_method><r_type><m_id>(<arg_list>)<s_end_list>{<s_m_body>}

This production allows parsing a method in the state structure, i.e. a method particular to a state. The <s_end_list> non-terminal would parse the output state of this method. It is derived from Production no. 80.

Production no. 90 in Appendix A is as follows <st_stm>this.trans(st_id);

52

This production allows parsing the ‘trans()’ method as a language keyword. Note that this parsing is possible only from the body of a method i.e. it is particular to a state.

Production no. 115, in appendix A is as follows <s_list>  [st_id]:[ st_id]

This production allows parsing the state name of a state structure. The colon separates the state names of the parent class and the subclass. It is derived from Production no. 79.