Recent changes to ImplementNewStrategy

ImplementNewStrategy modified by David Livingstone

David Livingstone — Sat, 10 Oct 2020 20:02:06 -0000

--- v25
+++ v26
@@ -11,8 +11,8 @@
 3.   The RAQUEL Token Class - Function Members. 
                           The function members that deal with name list parameters are more complex than those that deal with header fields and the pointers to the root nodes of various parse trees.  The latter are relatively straightforward, and consist of fairly obvious **GET** and **SET** functions.  The former are more complex, being tokenisers (albeit relatively straightforward tokenisers).

-It is convenient to have one NameList member function to handle all the different kinds of name lists.  It can handle all the general processing that applies to all name lists, e.g. general error checks.  It is called **DerivenameLists** and takes 2 arguments, one being the text of the name list parameter to the RAQUEL operator or assignment, and the other specifying which kind of name list the Raquel parameter text represents.  Since for clarity it is also useful to have one member function for each kind of name list, **DerivenameLists** calls the member function that is relevant to the particular kind of name function, to actually do the work.
-The algorithms used for each kind of name list are described in the document Algorithms of "DeriveNameLists" Member Function.  The algorithms are not as straightforward as at first sight they ought to be.  This is because of the need to detect as many different kinds of error as possible in the parameter text.  As it is useful to have a good set of test data to check for valid data and a range of errors, the test data used is given in the document Test Inputs for NameLists Member Functions.  The error numbers given in the document refer to the integer values of each member/enumerator of the enumerated type **E_ERRORTYPES_RaquelToken**, which is specifed in the file"ERRORTYPES-RaquelToken.h".  (This file is in the repository under the path name RaquelDBMS/Branches/Refactor1/RAQUELTOKENClass).
+It is convenient to have one NameList member function to handle all the different kinds of name lists.  It can handle all the general processing that applies to all name lists, e.g. general error checks.  It is called **DeriveNameLists** and takes 2 arguments, one being the text of the name list parameter to the RAQUEL operator or assignment, and the other specifying which kind of name list the Raquel parameter text represents.  Since for clarity it is also useful to have one member function for each kind of name list, **DeriveNameLists** calls the member function that is relevant to the particular kind of name function, to actually do the work.
+The algorithms used for each kind of name list are described in the document Algorithms of "DeriveNameLists" Member Function.  The algorithms are not as straightforward as at first sight they might be.  This is because of the need to detect as many different kinds of error as possible in the parameter text.  As it is useful to have a good set of test data to check for valid data and for a range of errors, the test data used is given in the document Test Inputs for NameLists Member Functions.  The error numbers given in that document refer to the integer values of each member/enumerator of the enumerated type **E_ERRORTYPES_RaquelToken**, which is specifed in the file "ERRORTYPES-RaquelToken.h".  (This file is in the repository under the path name RaquelDBMS/Branches/Refactor1/RAQUELTOKENClass).

 The Raquel Token Class requires invariants, i.e. checks to ensure that a RAQUEL Token object is created with valid and consistent internal values.  
 Since consistency is included in the invariants, it creates the possibility that the invariants may also be useful to create valid token objects from only subsets of relevant input data, *if* the input data is an appropriate subset.

ImplementNewStrategy modified by David Livingstone

David Livingstone — Sat, 10 Oct 2020 19:57:40 -0000

--- v24
+++ v25
@@ -11,7 +11,8 @@
 3.   The RAQUEL Token Class - Function Members. 
                           The function members that deal with name list parameters are more complex than those that deal with header fields and the pointers to the root nodes of various parse trees.  The latter are relatively straightforward, and consist of fairly obvious **GET** and **SET** functions.  The former are more complex, being tokenisers (albeit relatively straightforward tokenisers).

-The algorithms they use are described in the document Algorithms of "DeriveNameLists" Member Function.  (**DeriveNameLists** is the name of the main tokeniser member function).  The test data used is given in the document Test Inputs for NameLists Member Function.
+It is convenient to have one NameList member function to handle all the different kinds of name lists.  It can handle all the general processing that applies to all name lists, e.g. general error checks.  It is called **DerivenameLists** and takes 2 arguments, one being the text of the name list parameter to the RAQUEL operator or assignment, and the other specifying which kind of name list the Raquel parameter text represents.  Since for clarity it is also useful to have one member function for each kind of name list, **DerivenameLists** calls the member function that is relevant to the particular kind of name function, to actually do the work.
+The algorithms used for each kind of name list are described in the document Algorithms of "DeriveNameLists" Member Function.  The algorithms are not as straightforward as at first sight they ought to be.  This is because of the need to detect as many different kinds of error as possible in the parameter text.  As it is useful to have a good set of test data to check for valid data and a range of errors, the test data used is given in the document Test Inputs for NameLists Member Functions.  The error numbers given in the document refer to the integer values of each member/enumerator of the enumerated type **E_ERRORTYPES_RaquelToken**, which is specifed in the file"ERRORTYPES-RaquelToken.h".  (This file is in the repository under the path name RaquelDBMS/Branches/Refactor1/RAQUELTOKENClass).

 The Raquel Token Class requires invariants, i.e. checks to ensure that a RAQUEL Token object is created with valid and consistent internal values.  
 Since consistency is included in the invariants, it creates the possibility that the invariants may also be useful to create valid token objects from only subsets of relevant input data, *if* the input data is an appropriate subset.

ImplementNewStrategy modified by David Livingstone

David Livingstone — Sat, 10 Oct 2020 19:28:16 -0000

--- v23
+++ v24
@@ -4,11 +4,14 @@

 The purpose of the data members of a Raquel Token (object) is to provide a rational arrangement to hold all the data pertinent to a Raquel Token., despite the fact that the data to be held varies considerably in different tokens.  The requirements are now well established, and a straightforward design of data members completed.
 The function members required depend on the needs of the DBMS modules that access Raquel Tokens.  There are a number of modules, and their needs are by no means completely established.  Therefore a reasonable set of function members will be provided initially, but the set may be revised and/or extended as the DBMS develops.
+
 The physical design of the new Raquel Token class is described in the following documents :
 1.   The Rationale of the RAQUEL Token Class Physical Design.
 2.   The RAQUEL Token Class - Data Members.
 3.   The RAQUEL Token Class - Function Members. 
-                          The function members that deal with name list parameters are more complex than those that deal with header fields and the pointers to the root nodes of various parse trees.  The latter are relatively straightforward, and consist of fairly obvious **GET** and **SET** functions.  The former are more complex, being tokenisers (albeit relatively straightforward tokenisers).  The algorithms they use are described in the document Algorithms of "DeriveNameLists" Member Function.  (**DeriveNameLists** is the name of the main tokeniser member function).
+                          The function members that deal with name list parameters are more complex than those that deal with header fields and the pointers to the root nodes of various parse trees.  The latter are relatively straightforward, and consist of fairly obvious **GET** and **SET** functions.  The former are more complex, being tokenisers (albeit relatively straightforward tokenisers). 
+
+The algorithms they use are described in the document Algorithms of "DeriveNameLists" Member Function.  (**DeriveNameLists** is the name of the main tokeniser member function).  The test data used is given in the document Test Inputs for NameLists Member Function.

 The Raquel Token Class requires invariants, i.e. checks to ensure that a RAQUEL Token object is created with valid and consistent internal values.  
 Since consistency is included in the invariants, it creates the possibility that the invariants may also be useful to create valid token objects from only subsets of relevant input data, *if* the input data is an appropriate subset.

ImplementNewStrategy modified by David Livingstone

David Livingstone — Sun, 27 Sep 2020 16:31:15 -0000

--- v22
+++ v23
@@ -8,7 +8,7 @@
 1.   The Rationale of the RAQUEL Token Class Physical Design.
 2.   The RAQUEL Token Class - Data Members.
 3.   The RAQUEL Token Class - Function Members. 
-             As described in this document, the function members that deal with name list parameters are more complex than those that deal with header fields and the pointers to the root nodes of various parse trees.  The latter are relatively straightforward, and consist of fairly obvious **GET** and **SET** functions.  The former are more complex, being tokenisers (albeit relatively straightforward tokenisers).  The algorithms they use are described in the document Algorithms of "DeriveNameLists" Member Function.  (**DeriveNameLists** is the name of the main tokeniser member function).
+                          The function members that deal with name list parameters are more complex than those that deal with header fields and the pointers to the root nodes of various parse trees.  The latter are relatively straightforward, and consist of fairly obvious **GET** and **SET** functions.  The former are more complex, being tokenisers (albeit relatively straightforward tokenisers).  The algorithms they use are described in the document Algorithms of "DeriveNameLists" Member Function.  (**DeriveNameLists** is the name of the main tokeniser member function).

 The Raquel Token Class requires invariants, i.e. checks to ensure that a RAQUEL Token object is created with valid and consistent internal values.  
 Since consistency is included in the invariants, it creates the possibility that the invariants may also be useful to create valid token objects from only subsets of relevant input data, *if* the input data is an appropriate subset.

ImplementNewStrategy modified by David Livingstone

David Livingstone — Sun, 27 Sep 2020 16:29:17 -0000

--- v21
+++ v22
@@ -8,7 +8,7 @@
 1.   The Rationale of the RAQUEL Token Class Physical Design.
 2.   The RAQUEL Token Class - Data Members.
 3.   The RAQUEL Token Class - Function Members. 
-             As described in this document, the function members that deal with name list parameters are more complex than those the header fields and the pointers to the root nodes of various parse trees.  The latter are relatively straightforward, and consist of fairly obvious **GET** and **SET** functions.  The former are more complex, being tokenisers (albeit relatively straightforward tokenisers).  The algorithms they use are described in the document Algorithms of "DeriveNameLists" Member Function.  (**DeriveNameLists** is the name of the main tokeniser member function).
+             As described in this document, the function members that deal with name list parameters are more complex than those that deal with header fields and the pointers to the root nodes of various parse trees.  The latter are relatively straightforward, and consist of fairly obvious **GET** and **SET** functions.  The former are more complex, being tokenisers (albeit relatively straightforward tokenisers).  The algorithms they use are described in the document Algorithms of "DeriveNameLists" Member Function.  (**DeriveNameLists** is the name of the main tokeniser member function).

 The Raquel Token Class requires invariants, i.e. checks to ensure that a RAQUEL Token object is created with valid and consistent internal values.  
 Since consistency is included in the invariants, it creates the possibility that the invariants may also be useful to create valid token objects from only subsets of relevant input data, *if* the input data is an appropriate subset.

ImplementNewStrategy modified by David Livingstone

David Livingstone — Sun, 27 Sep 2020 16:28:10 -0000

--- v20
+++ v21
@@ -8,7 +8,7 @@
 1.   The Rationale of the RAQUEL Token Class Physical Design.
 2.   The RAQUEL Token Class - Data Members.
 3.   The RAQUEL Token Class - Function Members. 
-          T  The function members that deal with the header fields and the pointers to the root nodes of various parse trees are relatively straightforward, and consist of fairly obvious **GET** and **SET** functions.  However for name list parameters, a member function is needed that takes a name list parameter and represents it in the token by deriving the appropriate values of the name list data members.  This member function is called **DeriveNameLists**.  The algorithms it uses are described in the document Algorithms of "DeriveNameLists" Member Function.  (N.B.  It is useful to also have some **GET** and **SET** functions to directly handle the values of the name list data members).
+             As described in this document, the function members that deal with name list parameters are more complex than those the header fields and the pointers to the root nodes of various parse trees.  The latter are relatively straightforward, and consist of fairly obvious **GET** and **SET** functions.  The former are more complex, being tokenisers (albeit relatively straightforward tokenisers).  The algorithms they use are described in the document Algorithms of "DeriveNameLists" Member Function.  (**DeriveNameLists** is the name of the main tokeniser member function).

 The Raquel Token Class requires invariants, i.e. checks to ensure that a RAQUEL Token object is created with valid and consistent internal values.  
 Since consistency is included in the invariants, it creates the possibility that the invariants may also be useful to create valid token objects from only subsets of relevant input data, *if* the input data is an appropriate subset.

ImplementNewStrategy modified by David Livingstone

David Livingstone — Sun, 27 Sep 2020 16:18:59 -0000

--- v19
+++ v20
@@ -7,7 +7,8 @@
 The physical design of the new Raquel Token class is described in the following documents :
 1.   The Rationale of the RAQUEL Token Class Physical Design.
 2.   The RAQUEL Token Class - Data Members.
-3.   The RAQUEL Token Class - Function Members.  The function members that deal with the header fields and the pointers to the root nodes of various parse trees are relatively straightforward, and consist of fairly obvious **GET** and **SET** functions.  However for name list parameters, a member function is needed that takes a name list parameter and represents it in the token by deriving the appropriate values of the name list data members.  This member function is called **DeriveNameLists**.  The algorithms it uses are described in the document Algorithms of "DeriveNameLists" Member Function.  (N.B.  It is useful to also have some **GET** and **SET** functions to directly handle the values of the name list data members).
+3.   The RAQUEL Token Class - Function Members. 
+          T  The function members that deal with the header fields and the pointers to the root nodes of various parse trees are relatively straightforward, and consist of fairly obvious **GET** and **SET** functions.  However for name list parameters, a member function is needed that takes a name list parameter and represents it in the token by deriving the appropriate values of the name list data members.  This member function is called **DeriveNameLists**.  The algorithms it uses are described in the document Algorithms of "DeriveNameLists" Member Function.  (N.B.  It is useful to also have some **GET** and **SET** functions to directly handle the values of the name list data members).

 The Raquel Token Class requires invariants, i.e. checks to ensure that a RAQUEL Token object is created with valid and consistent internal values.  
 Since consistency is included in the invariants, it creates the possibility that the invariants may also be useful to create valid token objects from only subsets of relevant input data, *if* the input data is an appropriate subset.

ImplementNewStrategy modified by David Livingstone

David Livingstone — Wed, 23 Sep 2020 21:06:13 -0000

--- v18
+++ v19
@@ -7,7 +7,7 @@
 The physical design of the new Raquel Token class is described in the following documents :
 1.   The Rationale of the RAQUEL Token Class Physical Design.
 2.   The RAQUEL Token Class - Data Members.
-3.   The RAQUEL Token Class - Function Members.
+3.   The RAQUEL Token Class - Function Members.  The function members that deal with the header fields and the pointers to the root nodes of various parse trees are relatively straightforward, and consist of fairly obvious **GET** and **SET** functions.  However for name list parameters, a member function is needed that takes a name list parameter and represents it in the token by deriving the appropriate values of the name list data members.  This member function is called **DeriveNameLists**.  The algorithms it uses are described in the document Algorithms of "DeriveNameLists" Member Function.  (N.B.  It is useful to also have some **GET** and **SET** functions to directly handle the values of the name list data members).

 The Raquel Token Class requires invariants, i.e. checks to ensure that a RAQUEL Token object is created with valid and consistent internal values.  
 Since consistency is included in the invariants, it creates the possibility that the invariants may also be useful to create valid token objects from only subsets of relevant input data, *if* the input data is an appropriate subset.

ImplementNewStrategy modified by David Livingstone

David Livingstone — Thu, 13 Aug 2020 21:00:17 -0000

--- v17
+++ v18
@@ -15,21 +15,25 @@

 As the functionality of the DBMS is increased by adding more operators & assignments, the number of invariants must be increased to cope with them.  For additional relational and DB schema operators & assignments, the additional invariants can be added to the DBMS library at the same time.  However the scalar operators & assignments available depend on the scalar types currently 'plugged into' the DBMS.  A different library arrangement will be needed for them, because each DBMS installation could have a diferent set of scalar types.

+Besides invariants, there are two other sources referenced by the Raquel Token class, which will in due course become components of a DBMS library.  They are :
+1.  The set of all possible errors that could arise when accessing a Raquel Token.  They will eventually become a component of an 'Error' library that will be created, of all posible errors that could arise when using the DBMS.
+2.  The set of all possible types of 'NameList that can appear in a Raquel Token.  They are potentially relevant to expression re-writer modules as well as the Compactor.
+
 #### STEP TWO : Check the Parser, and Debug/Refine if Necessary

-It is the Parser that sets up the pointers in a Raquel Token that link the token to its neighbours in the parse tree created to represent the input statement.  Thus the existing parser needs to be modified to handle the new Raquel Tokens.  It can be checked for bugs at the same time.
+It is the Parser that sets up the pointers in a Raquel Token which link that token to its neighbour(s) in the parse tree created to represent the input statement.  Thus the existing parser needs to be modified to handle the new Raquel Tokens.  It can be checked for bugs at the same time.

 #### STEP THREE : Revamp the Compactor

 Significant changes must be made to the Compactor, in order to :
 1.  enable it to handle the new Raquel Token;
-2.  utilise the patterns in the invariants to determine which Raquel Tokens are to be created;
+2.  utilise the patterns in the invariants to help determine which Raquel Tokens are to be created;
 3.  fix the Compactor bug which causes it to incorporate literal relational values into the tokens of value assignments as parameters, instead of accepting those values as the right hand operands of the assignments.
 4.  ensure that the revised Compactor can recursively call the Tokeniser, itself, and the Parser, in order to generate the parse trees of expression parameters.

 #### FURTHER STEPS : Decide on How Best to Implement the Execution of the New Parse Trees

-In essence this concerns how best to execute the new parse trees.  Specifically, is there any short term merit in utilising the existing execution mechanism, or is it simpler to cannibalise it into the new DBMS architecture that will eventually be required anyway.
+In essence this concerns whether there is any short term merit in utilising the existing execution mechanism, or is it simpler to cannibalise it into the new DBMS architecture that will eventually be required anyway.

 **Return to** [Home]
 **Return to** [NewStrategy]

ImplementNewStrategy modified by David Livingstone

David Livingstone — Thu, 13 Aug 2020 20:01:25 -0000

--- v16
+++ v17
@@ -15,5 +15,21 @@

 As the functionality of the DBMS is increased by adding more operators & assignments, the number of invariants must be increased to cope with them.  For additional relational and DB schema operators & assignments, the additional invariants can be added to the DBMS library at the same time.  However the scalar operators & assignments available depend on the scalar types currently 'plugged into' the DBMS.  A different library arrangement will be needed for them, because each DBMS installation could have a diferent set of scalar types.

+#### STEP TWO : Check the Parser, and Debug/Refine if Necessary
+
+It is the Parser that sets up the pointers in a Raquel Token that link the token to its neighbours in the parse tree created to represent the input statement.  Thus the existing parser needs to be modified to handle the new Raquel Tokens.  It can be checked for bugs at the same time.
+
+#### STEP THREE : Revamp the Compactor
+
+Significant changes must be made to the Compactor, in order to :
+1.  enable it to handle the new Raquel Token;
+2.  utilise the patterns in the invariants to determine which Raquel Tokens are to be created;
+3.  fix the Compactor bug which causes it to incorporate literal relational values into the tokens of value assignments as parameters, instead of accepting those values as the right hand operands of the assignments.
+4.  ensure that the revised Compactor can recursively call the Tokeniser, itself, and the Parser, in order to generate the parse trees of expression parameters.
+
+#### FURTHER STEPS : Decide on How Best to Implement the Execution of the New Parse Trees
+
+In essence this concerns how best to execute the new parse trees.  Specifically, is there any short term merit in utilising the existing execution mechanism, or is it simpler to cannibalise it into the new DBMS architecture that will eventually be required anyway.
+
 **Return to** [Home]
 **Return to** [NewStrategy]