Rationale for developing another type system.
Posted: Wed Aug 28, 2013 5:26 pm
***NOTE***
This posting has been superseded by that dated 2013-11-13 below. This version has been retained, to keep the thread coherent. The new version replaces this one completely.
***NOTE***
This is the note I included in Ex 10, with my rationale for using a type system as the example, when Rel already has one.
Why yet another type system? The Third Manifesto (TTM) specifies the requirements for a type system, Tutorial D describes an language that meets those requirements, while Rel implements that language. So why not rely on those requirements, that language, and that implementation?
This type system (SDT) is designed to support problem and requirements gathering and analysis. As such it needs to be able to represent types that may not have a computable representation - see the definition for unbounded_integer for an example.
The base data types are derived from dimensional analysis rather than the lowest common denominator of constructs available to a/some/all computing languages. The chosen set should be capable of defining all but the most exotic of data types, though to define these it may be necessary to combine relational operators with non-operational operators; and/or extend the type system to multiple inheritance or multiple levels of inheritance. They also provide a more natural representation of different types.
The definitions of the various data types used are based very heavily on prior work by Shlaer and Mellor, and the Kennedy-Carter consultancy.
The main motivation for the type system is that it is an essential building block for a project to demonstrate proof of concept of a system development method. Such type system has to tie in with other aspects of the method. In addition, research in the method has led to some very specific ideas about how a type system should behave. Although it is believed that this type system is:
(a) compatible with TMM's requirements;
(b) internally consistent;
(c) complete;
no attempt has been made to formally prove any of these beliefs. Details of the expectations for a type system are spelt out in the note "Expected behaviour of type systems". It is not clear how far this type system conforms to/is compatible with/or contradicts that described in TTM and implemented in Rel.
It is very difficult to understand what the type system in TTM et al actually is. The implications of the requirements are less than clear; the approach of the implementation is accessible only via the grammar; and the documentation for the type system is virtually non-existent. Add to this the perpetual shadow that the approach to type systems described here is different from that described in TTM et al. but any differences are not obvious. then utilising Rel's type system becomes more problematic.
The differences between Rel and the example type system that have been identified so far are:
1. Rel has chosen to make identifiers case sensitive, and keywords insensitive. While there is no reason to believe that case sensitivity or insensitivity is preferable, it is my personal belief that the mix of choices within Rel is the least useful set possible. It leads to constraints on the choice of identifiers that are unnecessary; and leads to anomalies in definition. In Rel it is not possible to define an identifier called ordinal, Ordinal, or ORDINAL. It is possible to have identifiers named boolean, Boolean, but not BOOLEAN. It is also one of the expectations that type systems should be able to define types with different values of case sensitivity, collate sequences and the like. The lack of case sensitivity in identifiers does make implementing this expectation more difficult.
2. It is not possible to specify default values in Rel - whether in type definitions or variable definitions. The INIT construct is concerned with initialising multiple POSSREPs when a value is supplied to one of the POSSREPs.
3. The set of basic types in Rel is based on computer implementation types. SDT has a set of basic data types, based on dimensional analysis.
4. There is one known difference between SDT and TTM, though it is hoped that this is only a terminology difference. TTM permits variables to be defined ORDINAL and ORDERED. By contrast SDT uses enumerated and ordinal. The documentation for TTM does not really make it clear what is meant by ORDINAL or ORDERED. Ordinal has the connotation of an ordering system, and it seems that TTM uses it to describe a value from a list: not one that has an inherent order. Enumeration has no such implication. Equally when considering sequencing,the implications of ORDERED are normally only complete ones, rather than both partial and complete orderings.
5. Rel generates a different set of operators than those described as legitimate in the expected behaviour of type systems.
The requirement is for a type system that will support multiple aspects and phases of system development. The main construct needed to describe and implement processing and architecture in a computer system, sequence, is precisely that which is most difficult to represent within a relational system without artificial additional structures.
One approach adopted throughout this development is that all interfaces (or bridges) between parts of the system are as narrow as possible. Defining a type system can be done with about a dozen references to the base types and helper functions of Rel. As use of the built-in operators in conjunction with inherited data types (whether because of lack of understanding of the TTM requirements; lack of understanding of the syntax of Rel; or the current state of development of Rel) seems to have the potential to generate substantial numbers of errors within Rel, minimising the use of such built-ins is deemed helpful.
This posting has been superseded by that dated 2013-11-13 below. This version has been retained, to keep the thread coherent. The new version replaces this one completely.
***NOTE***
This is the note I included in Ex 10, with my rationale for using a type system as the example, when Rel already has one.
Why yet another type system? The Third Manifesto (TTM) specifies the requirements for a type system, Tutorial D describes an language that meets those requirements, while Rel implements that language. So why not rely on those requirements, that language, and that implementation?
This type system (SDT) is designed to support problem and requirements gathering and analysis. As such it needs to be able to represent types that may not have a computable representation - see the definition for unbounded_integer for an example.
The base data types are derived from dimensional analysis rather than the lowest common denominator of constructs available to a/some/all computing languages. The chosen set should be capable of defining all but the most exotic of data types, though to define these it may be necessary to combine relational operators with non-operational operators; and/or extend the type system to multiple inheritance or multiple levels of inheritance. They also provide a more natural representation of different types.
The definitions of the various data types used are based very heavily on prior work by Shlaer and Mellor, and the Kennedy-Carter consultancy.
The main motivation for the type system is that it is an essential building block for a project to demonstrate proof of concept of a system development method. Such type system has to tie in with other aspects of the method. In addition, research in the method has led to some very specific ideas about how a type system should behave. Although it is believed that this type system is:
(a) compatible with TMM's requirements;
(b) internally consistent;
(c) complete;
no attempt has been made to formally prove any of these beliefs. Details of the expectations for a type system are spelt out in the note "Expected behaviour of type systems". It is not clear how far this type system conforms to/is compatible with/or contradicts that described in TTM and implemented in Rel.
It is very difficult to understand what the type system in TTM et al actually is. The implications of the requirements are less than clear; the approach of the implementation is accessible only via the grammar; and the documentation for the type system is virtually non-existent. Add to this the perpetual shadow that the approach to type systems described here is different from that described in TTM et al. but any differences are not obvious. then utilising Rel's type system becomes more problematic.
The differences between Rel and the example type system that have been identified so far are:
1. Rel has chosen to make identifiers case sensitive, and keywords insensitive. While there is no reason to believe that case sensitivity or insensitivity is preferable, it is my personal belief that the mix of choices within Rel is the least useful set possible. It leads to constraints on the choice of identifiers that are unnecessary; and leads to anomalies in definition. In Rel it is not possible to define an identifier called ordinal, Ordinal, or ORDINAL. It is possible to have identifiers named boolean, Boolean, but not BOOLEAN. It is also one of the expectations that type systems should be able to define types with different values of case sensitivity, collate sequences and the like. The lack of case sensitivity in identifiers does make implementing this expectation more difficult.
2. It is not possible to specify default values in Rel - whether in type definitions or variable definitions. The INIT construct is concerned with initialising multiple POSSREPs when a value is supplied to one of the POSSREPs.
3. The set of basic types in Rel is based on computer implementation types. SDT has a set of basic data types, based on dimensional analysis.
4. There is one known difference between SDT and TTM, though it is hoped that this is only a terminology difference. TTM permits variables to be defined ORDINAL and ORDERED. By contrast SDT uses enumerated and ordinal. The documentation for TTM does not really make it clear what is meant by ORDINAL or ORDERED. Ordinal has the connotation of an ordering system, and it seems that TTM uses it to describe a value from a list: not one that has an inherent order. Enumeration has no such implication. Equally when considering sequencing,the implications of ORDERED are normally only complete ones, rather than both partial and complete orderings.
5. Rel generates a different set of operators than those described as legitimate in the expected behaviour of type systems.
The requirement is for a type system that will support multiple aspects and phases of system development. The main construct needed to describe and implement processing and architecture in a computer system, sequence, is precisely that which is most difficult to represent within a relational system without artificial additional structures.
One approach adopted throughout this development is that all interfaces (or bridges) between parts of the system are as narrow as possible. Defining a type system can be done with about a dozen references to the base types and helper functions of Rel. As use of the built-in operators in conjunction with inherited data types (whether because of lack of understanding of the TTM requirements; lack of understanding of the syntax of Rel; or the current state of development of Rel) seems to have the potential to generate substantial numbers of errors within Rel, minimising the use of such built-ins is deemed helpful.