|
Site Menu Project Specification Implementation Recommendations Reference Needs Updating Work in Progress Wastebasket Wiki Manual |
Verification Of Operator Bindings Static And Dynamic TypesWiP.VerificationOfOperatorBindingsStaticAndDynamicTypes HistoryHide minor edits - Show changes to output 2010-04-16 14:45
by -
Deleted lines 41-45:
[@definitionOfModule : DEFINITION MODULE moduleId ( '(' semanticType ')' )? ';' importList* definition* END moduleId '.' ;@] 2010-04-16 14:41
by -
Added lines 42-46:
[@definitionOfModule : DEFINITION MODULE moduleId ( '(' semanticType ')' )? ';' importList* definition* END moduleId '.' ;@] 2010-04-16 10:19
by - 2010-04-16 09:27
by -
Changed lines 77-82 from:
!!! Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. If the newly required type specifier for collection types is to be chosen with the highest overall consistency in mind then "A-Type" is the most suitable choice. !!! to:
!!!Full Examples Added lines 85-88:
!!!Conclusion Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. If the newly required type specifier for collection types is to be chosen with the highest overall consistency in mind then "A-Type" is the most suitable choice. 2010-04-16 09:27
by -
Changed lines 83-88 from:
[[Operator Binding Example for Approach 2: A-Type]] [[Operator Binding Example for Approach 2: S-Type]] [[Operator Binding Example for Approach 2: Z-Type]] [[Operator Binding Example for Approach 3: A-Type]] [[Operator Binding Example for Approach 3: S-Type]] [[Operator Binding Example for Approach 3: Z-Type]] to:
*[[Operator Binding Example for Approach 2: A-Type]] *[[Operator Binding Example for Approach 2: S-Type]] *[[Operator Binding Example for Approach 2: Z-Type]] *[[Operator Binding Example for Approach 3: A-Type]] *[[Operator Binding Example for Approach 3: S-Type]] *[[Operator Binding Example for Approach 3: Z-Type]] 2010-04-16 09:26
by -
Added line 83:
[[Operator Binding Example for Approach 2: A-Type]] Changed lines 85-89 from:
[[ [[ [[ [[ [[WiP/OpBindings/Examples/Approach3/ to:
[[Operator Binding Example for Approach 2: Z-Type]] [[Operator Binding Example for Approach 3: A-Type]] [[Operator Binding Example for Approach 3: S-Type]] [[Operator Binding Example for Approach 3: Z-Type]] 2010-04-16 09:26
by -
Changed line 83 from:
[[Operator Binding Example for Approach to:
[[Operator Binding Example for Approach 2: S-Type]] 2010-04-16 09:25
by -
Changed line 83 from:
[[ to:
[[Operator Binding Example for Approach #2: S-Type]] 2010-04-16 09:24
by -
Changed line 83 from:
[[WiP/ to:
[[WiP/OpBindingsExamplesApproach2_A-Type]] 2010-04-16 09:24
by -
Changed lines 79-88 from:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. If the newly required type specifier for collection types is to be chosen with the highest overall consistency in mind then "A-Type" is the most suitable choice. to:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. If the newly required type specifier for collection types is to be chosen with the highest overall consistency in mind then "A-Type" is the most suitable choice. !!!Examples [[WiP/OpBindings/Examples/Approach2/A-Type]] [[WiP/OpBindings/Examples/Approach2/S-Type]] [[WiP/OpBindings/Examples/Approach2/Z-Type]] [[WiP/OpBindings/Examples/Approach3/A-Type]] [[WiP/OpBindings/Examples/Approach3/S-Type]] [[WiP/OpBindings/Examples/Approach3/Z-Type]] 2010-04-16 09:13
by -
Changed line 74 from:
* if the module header has a Z, R to:
* if the module header has a Z, R or C specifier, the type must be a record. 2010-04-16 09:12
by -
Changed line 79 from:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. If the required type specifier for collection types is to be chosen with the highest overall consistency in mind then "A-Type" is the most suitable choice. to:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. If the newly required type specifier for collection types is to be chosen with the highest overall consistency in mind then "A-Type" is the most suitable choice. 2010-04-16 09:10
by -
Changed line 79 from:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. If the required type specifier for collection types is to be chosen with the highest overall consistency in mind then "A-Type" is the to:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. If the required type specifier for collection types is to be chosen with the highest overall consistency in mind then "A-Type" is the most suitable choice. 2010-04-16 09:07
by -
Changed line 41 from:
The syntax of approach #3 emphasises the notion that bindings are a property of the library. Since the definition module of a library also serves as its documentation, this syntax has the advantage that it indicates the semantic model of the library at the top of its documentation. to:
The syntax of approach #3 emphasises the notion that bindings are a property of the library. Since the definition module of a library also serves as its documentation, this syntax has the advantage that it indicates the semantic model of the library at the top of its documentation. It also has a minor advantage in that the grammar is slightly simpler. 2010-04-16 09:04
by -
Changed line 79 from:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. If the required type specifier for collection types is to be chosen with the highest overall consistency in mind then "A-Type" is the most suitable choice followed by "AA-Type" as second most suitable choice. to:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. If the required type specifier for collection types is to be chosen with the highest overall consistency in mind then "A-Type" is the most suitable choice followed by "AA-Type" as the second most suitable choice. 2010-04-16 09:04
by -
Changed line 79 from:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. If the required type specifier for collection types is to be chosen with the highest overall consistency in mind then "A-Type" is the most suitable choice. to:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. If the required type specifier for collection types is to be chosen with the highest overall consistency in mind then "A-Type" is the most suitable choice followed by "AA-Type" as second most suitable choice. 2010-04-16 09:02
by -
Changed line 79 from:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. to:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. If the required type specifier for collection types is to be chosen with the highest overall consistency in mind then "A-Type" is the most suitable choice. 2010-04-16 09:01
by -
Changed line 79 from:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. The required type specifier for collection types should also be chosen with overall consistency in mind. to:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. The required type specifier for collection types should also be chosen with overall consistency in mind. 2010-04-16 09:01
by -
Changed line 79 from:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. The required type specifier for collection types should also be chosen with overall consistency in mind. to:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are favourable and both equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. The required type specifier for collection types should also be chosen with overall consistency in mind. 2010-04-16 08:57
by -
Changed lines 61-62 from:
* if there is a record type with a specifier and the same name as the module then bindings associated with the specifier are permitted. * if there is an opaque pointer type with the same name as the module then string and collection bindings are permitted. to:
* if there is a record type declaration with a specifier and the same name as the module then bindings associated with the specifier are permitted. * if there is an opaque pointer type declaration with the same name as the module then string and collection bindings are permitted. 2010-04-16 08:56
by -
Changed line 61 from:
* if there is a to:
* if there is a record type with a specifier and the same name as the module then bindings associated with the specifier are permitted. 2010-04-16 08:54
by -
Changed lines 61-62 from:
* if there is a specifier, the type with the specifier must have the same name as the module * if there is an opaque pointer type with the same name as the module then string and collection bindings are permitted otherwise, the bindings associated with the specifier to:
* if there is a specifier, the type with the specifier must have the same name as the module and bindings associated with the specifier are permitted. * if there is an opaque pointer type with the same name as the module then string and collection bindings are permitted. 2010-04-16 08:54
by -
Changed lines 62-65 from:
* if there an opaque pointer type with the same name as the module string and collection bindings are permitted * bindings to @@LENGTH@@ and @@COUNT@@ are mutually exclusive * * to:
* if there is an opaque pointer type with the same name as the module then string and collection bindings are permitted otherwise, the bindings associated with the specifier are permitted. * if string and collection bindings are permitted then @@LENGTH@@ and @@COUNT@@ bindings are mutually exclusive. * if there is a binding to @@LENGTH@@, then only string bindings are permitted. * if there is a binding to @@COUNT@@, then only collection bindings are permitted. 2010-04-16 08:50
by -
Added lines 54-55:
Overall, "A-Type", "S-Type", "Z-Type", "R-Type", "C-Type" and "V-Type" would seem to be the more consistent set of specifiers. 2010-04-16 08:47
by -
Changed line 45 from:
Since approaches #2 and #3 require a specifier for each semantic type, both necessitate the introduction of a new specifier for collection types. The most obvious mnemonic "C-Type" is already in use for complex number types. Suitable alternatives would be "A-Type" as a mnemonic for "array notation", or "AA-Type" as a mnemonic for "associative array". to:
Since approaches #2 and #3 require a specifier for each semantic type, both necessitate the introduction of a new specifier for collection types. The most obvious mnemonic "C-Type" is not available because it is already in use for complex number types. Suitable alternatives would be "A-Type" as a mnemonic for "array notation", or "AA-Type" as a mnemonic for "associative array". 2010-04-16 08:46
by -
Changed line 41 from:
The syntax of approach #3 emphasises the notion that bindings are a property of the library. Since the definition module of a library also serves as its documentation, this syntax has the advantage that it indicates the semantic model of the library at the top. to:
The syntax of approach #3 emphasises the notion that bindings are a property of the library. Since the definition module of a library also serves as its documentation, this syntax has the advantage that it indicates the semantic model of the library at the top of its documentation. 2010-04-16 07:42
by -
Changed lines 45-46 from:
Since approaches #2 and #3 require a specifier for each semantic type, both to:
Since approaches #2 and #3 require a specifier for each semantic type, both necessitate the introduction of a new specifier for collection types. The most obvious mnemonic "C-Type" is already in use for complex number types. Suitable alternatives would be "A-Type" as a mnemonic for "array notation", or "AA-Type" as a mnemonic for "associative array". Changed line 77 from:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. to:
Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. The required type specifier for collection types should also be chosen with overall consistency in mind. 2010-04-16 07:39
by -
Added lines 74-77:
!!!Conclusion Approach #1 is the least favourable because it introduces inconsistencies, requires more semantic analysis and may inhibit the addition of more semantic types in the future. Approaches #2 and #3 are equally suitable. If it is desired to emphasise bindings as a property of the type, #2 may be given preference. If it is desired to emphasise bindings as a property of the library, #3 may be given preference. 2010-04-16 07:33
by -
Changed lines 62-64 from:
* bindings to LENGTH and COUNT are mutually exclusive * if there is a binding to LENGTH, then only string bindings are permitted * if there is a binding to COUNT, then only collection bindings are permitted to:
* bindings to @@LENGTH@@ and @@COUNT@@ are mutually exclusive * if there is a binding to @@LENGTH@@, then only string bindings are permitted * if there is a binding to @@COUNT@@, then only collection bindings are permitted 2010-04-16 07:32
by -
Changed lines 60-65 from:
to:
* if there is a specifier, the type with the specifier must have the same name as the module. * if there an opaque pointer type with the same name as the module string and collection bindings are permitted. * bindings to LENGTH and COUNT are mutually exclusive * if there is a binding to LENGTH, then only string bindings are permitted * if there is a binding to COUNT, then only collection bindings are permitted Changed lines 68-71 from:
to:
* the type with the specifier must have the same name as the module. * Z, R and C type specifiers can only be used in a record declaration. * S and A type specifiers can only be used in a opaque pointer declaration. Changed lines 74-79 from:
Conclusion to:
* the type specifier is applied to the type with the same name as the module. * if the module header has a Z, R and C specifier, the type must be a record. * if the module header has an S or A specifier, the type must be an opaque pointer. 2010-04-16 07:31
by -
Changed lines 56-59 from:
Static For #1 the static semantics would be as follows: to:
!!!Static Semantics For approach #1 the static semantics would be as follows: Changed lines 66-67 from:
For #2 the static semantics would be as follows: to:
For approach #2 the static semantics would be as follows: Changed line 72 from:
For #3 the static semantics would be as follows: to:
For approach #3 the static semantics would be as follows: 2010-04-16 07:30
by -
Changed line 47 from:
[@TYPE Dictionary = OPAQUE (" to:
[@TYPE Dictionary = OPAQUE ("A-Type"); 2010-04-16 07:29
by -
Added lines 47-49:
[@TYPE Dictionary = OPAQUE ("Collection"); TYPE UniString = OPAQUE ("S-Type");@] Added lines 51-54:
[@TYPE Dictionary = OPAQUE ("Collection"); TYPE UniString = OPAQUE ("String");@] 2010-04-16 07:28
by -
Added lines 46-47:
Another alternative would be "Collection" but this would be inconsistent with other semantic type specifiers. This inconsistency could be resolved by using "String" instead of "S-Type" and reserve single letter based specifiers for numeric types only. 2010-04-16 07:25
by -
Changed line 45 from:
Since approaches #2 and #3 require a specifier for each semantic type, both require to:
Since approaches #2 and #3 require a specifier for each semantic type, both require the introduction of a new specifier for collection types. The most obvious mnemonic "C-Type" is already in use for complex number types. Suitable alternatives would be "A-Type" as a mnemonic for "array notation", or "AA-Type" as a mnemonic for "associative array". 2010-04-16 07:22
by -
Changed lines 33-40 from:
This means they would have to share one set of permitted bindings. Either the [<] and [>] Apporaches #2 and #3 both have consistent syntax and semantics to:
!!!Discussion in Detail With approach #1 string and collection types would have to share one set of permitted bindings. Either the bindings for @@<@@ and @@>@@ would have to be permitted for collection types, or the presence of a binding for @@LENGTH@@ or @@COUNT@@ would have to determine which set of bindings are permitted. The former would leave the semantics of operators @@<@@ and @@>@@ for collection types undefined and open to library implementors. The latter would lead to some overhead in semantic analysis. Either way would introduce some inconsistency into the language. Overall this approach may give the impression that operator bindings for string and collection types were bolted-on afterwards. Adding further semantic types in the future may become difficult without rendering existing source code incompatible. Approaches #2 and #3 both have consistent syntax and semantics. Bindings are only permitted if a semantic type is specified. Every semantic type has a specifier and an associated set of permitted bindings. Both approaches can accommodate the addition of further semantic types in the future without rendering existing source code incompatible. The syntax of approach #2 emphasises the notion that bindings are a property of the type. In the event that the same library also defines other auxiliary types, this syntax has the advantage that it is always clear to which type the semantic type specifier applies. The syntax of approach #3 emphasises the notion that bindings are a property of the library. Since the definition module of a library also serves as its documentation, this syntax has the advantage that it indicates the semantic model of the library at the top. !!!Type Specifier for Collection Types Since approaches #2 and #3 require a specifier for each semantic type, both require a new specifier for collection types to be introduced. The most obvious mnemonic "C-Type" is already in use for complex number types. Suitable alternatives would be "A-Type" as a mnemonic for "array notation", or "AA-Type" as a mnemonic for "associative array". 2010-04-16 06:46
by -
Changed line 28 from:
With this approach the to:
With this approach the syntax is changed to put the type specifier into the module header. Each semantic type requires a type specifier. 2010-04-16 06:35
by -
Changed line 30 from:
[@ to:
[@DEFINITION MODULE SHORTINT ("Z-Type"); Deleted line 33:
2010-04-16 06:35
by -
Changed lines 14-15 from:
to:
With this approach no additional syntax is added. No type specifiers exist for strings and collections. Changed lines 21-23 from:
dynamic to:
With this approach additional syntax is provided for opaque pointer declarations. Each semantic type requires a type specifier. [@TYPE SHORTINT = OPAQUE RECORD ("Z-Type") ... END; TYPE String = OPAQUE ("S-Type");@] Changed lines 28-29 from:
dynamic example: DEFINITION MODULE String to:
With this approach the existing syntax is changed to put the type specifier into the module header. Each semantic type requires a type specifier. [@ DEFINITION MODULE SHORTINT ("Z-Type"); DEFINITION MODULE String ("S-Type");@] 2010-04-16 06:23
by -
Deleted line 15:
Changed line 17 from:
TYPE String = OPAQUE; (* strings and collections *)@] to:
TYPE String = OPAQUE; (* strings and collections share the same bindings *)@] 2010-04-16 06:23
by -
Changed lines 14-16 from:
dynamic example: TYPE String = OPAQUE; (* shared bindings for strings and collections to:
In this approach no additional syntax is added. No type specifiers exist for strings and collections. Examples: [@TYPE SHORTINT = OPAQUE RECORD ("Z-Type") ... END; TYPE String = OPAQUE; (* strings and collections *)@] Changed lines 22-23 from:
to:
static type example: [@TYPE SHORTINT = OPAQUE RECORD ("Z-Type") ... END; dynamic type example: TYPE String = OPAQUE ("S-Type"); 2010-04-16 06:18
by -
Changed line 12 from:
!!!!1) No additional syntax, shared semantics for strings and collections to:
!!!!1) No additional syntax, but shared semantics for strings and collections 2010-04-16 06:17
by -
Changed line 17 from:
!!!!2) Additional syntax to allow semantic type specifier in to:
!!!!2) Additional syntax to allow semantic type specifier in opaque pointer declarations 2010-04-16 06:16
by -
Changed lines 17-18 from:
to:
!!!!2) Additional syntax to allow semantic type specifier in record and opaque pointer declarations Changed line 22 from:
to:
!!!!3) Modified syntax to move semantic type specifier into the module declaration 2010-04-16 06:14
by -
Changed line 3 from:
This article describes three possible approaches how to enforce permitted bindings based on semantic types but also to:
This article describes three possible approaches how to enforce permitted operator bindings based on semantic types but also 2010-04-16 06:11
by -
Changed line 12 from:
!!!!No additional syntax, shared semantics for strings and collections to:
!!!!1) No additional syntax, shared semantics for strings and collections 2010-04-16 06:11
by -
Changed lines 10-12 from:
!!!Possible Solutions #) Specifiers to:
!!!Possible Solutions in Brief !!!!No additional syntax, shared semantics for strings and collections 2010-04-16 06:09
by -
Added lines 1-60:
!!!Synopsis This article describes three possible approaches how to enforce permitted bindings based on semantic types but also taking into account that some semantic types are static in nature while others are dynamic. !!!Problem Description The grammar (status April 14, 2010) defines syntax that allows a semantic type to be specified in a @@RECORD@@ declaration only. If a type is declared as an opaque pointer, such as would be the case for types of dynamic nature, e.g. string and collection types, then there is no syntax to specify a semantic type. !!!Possible Solutions #) Specifiers in RECORD declaration only static example: TYPE SHORTINT = OPAQUE RECORD ("Z-Type") ... END; dynamic example: TYPE String = OPAQUE; (* shared bindings for strings and collections *) #) Specifiers in TYPE declaration, both RECORD and OPAQUE only static example: TYPE SHORTINT = OPAQUE RECORD ("Z-Type") ... END; dynamic example: TYPE String = OPAQUE ("S-Type"); #) Specifiers in MODULE declaration static example: DEFINITION MODULE SHORTINT ("Z-Type"); dynamic example: DEFINITION MODULE String ("S-Type"); Our present grammar defines syntax that matches #1 but we do not have any semantics that allow us to distinguish between different semantic types if the new type is declared as an OPAQUE pointer only. Unless we change or at least amend the syntax, we would have to treat S-Types and collection types as one model. This means they would have to share one set of permitted bindings. Either the [<] and [>] bindings would be allowed for collections even though they do not make much sense, or the presence of a binding for LENGTH or COUNT would determine which set of bindings are permitted. Either way is possible to do without too much overhead but it would nevertheless introduces some level of inconsistency into the language. It may give the impression that S-Types and collections were bolted-on afterwards. Apporaches #2 and #3 both have consistent syntax and semantics. Bindings are only permitted if a semantic type is specified. In that sense both approaches are also conservative. Unless you use the new syntax, you are left with a more conventional Modula-2 behaviour, no bindings. The only disadvantage I see with #2 and #3 is that we have to find a semantic type specifier for collection types and there is no obvious good one like S, Z, R, C and V for the other semantic types. Yet, this is probably just a matter of getting used to. We could use "A-Type" or "AA-Type" as a mnemonic for "array notation" or "associative array". Static semantics For #1 the static semantics would be as follows: 1) if there is a specifier, the type with the specifier must have the same name as the module. 2) if there an opaque pointer type with the same name as the module string and collection bindings are permitted. 3) bindings to LENGTH and COUNT are mutually exclusive 4) if there is a binding to LENGTH, then only string bindings are permitted 5) if there is a binding to COUNT, then only collection bindings are permitted For #2 the static semantics would be as follows: 1) the type with the specifier must have the same name as the module. 2) Z, R and C type specifiers can only be used in a record declaration. 3) S and A type specifiers can only be used in a opaque pointer declaration. For #3 the static semantics would be as follows: 1) the type specifier is applied to the type with the same name as the module. 2) if the module header has a Z, R and C specifier, the type must be a record. 3) if the module header has an S or A specifier, the type must be an opaque pointer. Conclusion |