Conversion rules - Revision history

Conaclos: naming convention

2013-05-20T10:27:12Z

naming convention

Seilerm at 04:25, 17 February 2007

2007-02-17T04:25:05Z

Seilerm at 22:55, 25 January 2007

2007-01-25T22:55:14Z

Seilerm at 00:19, 25 January 2007

2007-01-25T00:19:44Z

Seilerm at 21:56, 23 January 2007

2007-01-23T21:56:13Z

Seilerm at 20:42, 23 January 2007

2007-01-23T20:42:51Z

Seilerm at 19:08, 23 January 2007

2007-01-23T19:08:56Z

Seilerm at 15:35, 23 January 2007

2007-01-23T15:35:24Z

Show changes

Seilerm at 23:28, 22 January 2007

2007-01-22T23:28:42Z

Seilerm at 23:23, 22 January 2007

2007-01-22T23:23:10Z

@@ Line 23: / Line 23: @@
 <code>[eiffel,N]
-class A [G]
+class
 convert
-    to_a: {A [G]}
+    as_a: {A [G]}
 feature
-    to_a: A [G]
+    as_a: A [G]
         do end
 end
 </code>
@@ Line 54: / Line 58: @@
 <code>[eiffel,N]
-class A [G]
+class
 convert
-    to_a: {A [STRING]}
+    as_a: {A [STRING]}
 feature
-    to_a: A [STRING]
+    as_a: A [STRING]
         do end
 end
 </code>
@@ Line 81: / Line 89: @@
 <code>[eiffel,N]
-class A [G,H]
+class
 convert
-    to_a: {A [G,G]}
+    as_a: {A [G,G]}
 feature
-    to_a: A [G,G]
+    as_a: A [G,G]
        do end
 end
 </code>
@@ Line 110: / Line 122: @@
 end
-class B [G]
+class
 inherit
-      A [ANY]
+   A [ANY]
 convert
-    to_b: {A [STRING]}
+    as_b: {A [STRING]}
 feature
-    to_b: A [STRING]
+    as_b: A [STRING]
         do end
 end
 </code>
@@ Line 142: / Line 159: @@
 end
-class B [G -> INTEGER,H -> DOUBLE]
+class
 inherit
-      A [G,H]
+   A [G,H]
 convert
-    to_a: {A [DOUBLE,INTEGER]}
+    as_a: {A [DOUBLE,INTEGER]}
 feature
-    to_a: A [DOUBLE,INTEGER]
+    as_a: A [DOUBLE,INTEGER]
         do end
 end
 </eiffel>
@@ Line 172: / Line 193: @@
 end
-class B [G -> INTEGER_REF]
+class
 inherit
-      A [G]
+   A [G]
 convert
-    to_a: {A [DOUBLE]}
+    as_a: {A [DOUBLE]}
 feature
-    to_a: A [DOUBLE]
+    as_a: A [DOUBLE]
         do end
 end
 </eiffel>
@@ Line 277: / Line 303: @@
 It can be quite tricky to check this rule as for example:
 <eiffel>
-class B [G -> H, H -> G]
+class
 inherit
     A [G]
 convert
-    to_a: {A [STRING]}
+    as_a: {A [STRING]}
 feature
-    to_a: A [STRING]
+    as_a: A [STRING]
        do end
 end
 </eiffel>
@@ Line 306: / Line 337: @@
 <eiffel>
-class A [G]
+class
 convert
-    to_a: {A [STRING]}
+    as_a: {A [STRING]}
 end
 </eiffel>
@@ Line 322: / Line 356: @@
 class X
 convert
-    to_y: {Y}
+    as_y: {Y}
 feature
-    to_y: Y
+    as_y: Y
        do end
 end
@@ Line 335: / Line 369: @@
+    Y
 end
-class TEST
+class
 feature
     test
@@ Line 350: / Line 386: @@
     needs_y (y: Y)
        do end
 end
 </eiffel>

@@ Line 1: / Line 1: @@
 [[Category:Compiler]]
 [[Category:ECMA]]
 ==Introduction==

@@ Line 297: / Line 297: @@
 ====Level 2: Type declaration====
 This solution is much easier to check and to explain to a user (as there is now a particular failing instance). With this solution the difficult part, which is to check that there is no valid generic derivation of CT which is conform to the TARGET, is avoided. The check is done at every generic type derivation where there are any conversion rules for the corresponding base class. So there are possibly more checks necessary compared to a level 1 check.
 ===='''Level 3: Attachment'''====
 The check is done for every attachment (<e>a := b</e>). This seems to be even more expensive than a level 2 check as one has to check for each attachment both: conformance and conversion.
@@ Line 317: / Line 318: @@
 ==Appendix==
 ====Conversion principle at runtime====
-The ''Conversion Principle'' can be violated at runtime:
+Through the class <e>INTERNAL</e> one is able to create new types at runtime. With this ability it is possible to violate the ''Conversion Principle'' at runtime.
 <eiffel>
 class X

@@ Line 143: / Line 143: @@
 end
-class B [G->INTEGER,H->DOUBLE]
+class B [G -> INTEGER,H -> DOUBLE]
 inherit
        A [G,H]
@@ Line 155: / Line 155: @@
 '''VYCQ(3)''':
-  Is <e>B[INTEGER,DOUBLE]</e> conform to <e>A[DOUBLE,INTEGER]</e>?
+  Is <e>B [INTEGER,DOUBLE]</e> conform to <e> A[DOUBLE,INTEGER]</e>?
 The answer is '''no''' and thus the code regarded as valid.
@@ Line 173: / Line 173: @@
 end
-class B [G->INTEGER_REF]
+class B [G -> INTEGER_REF]
 inherit
        A [G]
@@ Line 278: / Line 278: @@
 It can be quite tricky to check this rule as for example:
 <eiffel>
-class B [G->H,H->G]
+class B [G -> H, H -> G]
 inherit
     A [G]

@@ Line 243: / Line 243: @@
 The answer is '''yes''' and therefore the code '''invalid'''. But it should be '''valid''' because the constraint INTEGER_REF and the fact that DOUBLE is frozen make it impossible to create a type which satisfies both, the conformance to INTEGER_REF and to DOUBLE.
-==Pattern matching rule==
+One could avoid this shortcoming by a more complex definition of the wildcard type:
 In case we check a class, which has at least one formal generic type parameter we want to find out, whether it is possible to derive a type which is conform to the constraint and to the type where we convert to. If such a type exists, the conversion is invalid as it violates the ''Conversion Principle''.

@@ Line 13: / Line 13: @@
 * 8.15.3 Validity: ''Conversion principle'': No type may both conform and convert to another.
-This has to be verified for all static types. At runtime for dynamic types this principle cannot be easily guaranteed.
+This has to be verified for all static types.
 ==Examples==
 As the conversion rules are strongly dual, each example can be transformed to show the issue for its sibling.
@@ Line 197: / Line 199: @@
 [[Image:Type-conversion-illustration.png|thumb|Type Diagram]]
-If we take the inheritance hierarchy of an Eiffel system it can be abstracted to a directed acyclic graph. A an valid type T for conversion has the following properties:
+If we take the inheritance hierarchy of an Eiffel system it can be abstracted to a directed acyclic graph. A an valid type (TARGET) for conversion has the following properties:
 * The constraint does not conform to it (VYC*(3)).
-* There exists no valid generic derivation of CT which is conform to it.
+* There exists no valid generic derivation of CT which is conform to the TARGET.
 All these properties include the normal cases (for example CT contains no formals).
@@ Line 219: / Line 221: @@
 * VYCQ'(2) ''FTN(CT)'' does not conform to ''TARGET''
-To complete and take the
+====Wildcard rule applied to some examples====
-−
-−
-====New rule applied to some examples====
 '''Example 4 for VYCQ'(2):'''
@@ Line 242: / Line 241: @@
   Is <e>B [*]</e> conform to <e>A [DOUBLE]</e>?
-The answer is '''yes''' and therefore the code '''valid'''. But it should be '''invalid''' because the constraint INTEGER_REF and the fact that DOUBLE is frozen make it impossible to create a type which satisfies both, the conformance to INTEGER_REF and to DOUBLE.
+The answer is '''yes''' and therefore the code '''invalid'''. But it should be '''valid''' because the constraint INTEGER_REF and the fact that DOUBLE is frozen make it impossible to create a type which satisfies both, the conformance to INTEGER_REF and to DOUBLE.
 ==Pattern matching rule==
@@ Line 286: / Line 285: @@
 We would obtain a TTC which looks like this: B[STRING,G]<br>
 Now one would have to define, whether this type satisfies the constraint or not.
-==Relaxed rule==
+==Drop the Conversion Principle==
-As it turns out to be quite tricky to check validity as soon as formal generic type parameters are used one could also be a little bit more relaxed and say the following is valid code:
+As a radical alternative one could also be totally open and say the following is valid code:
 <eiffel>
@@ Line 298: / Line 307: @@
 </eiffel>
 As soon as we find out statically that we have type conformance in a particular case, we do not do a conversion. So one would only do a conversion if it is necessary.
-This seems to be ok as the conversion principle anyway can be violated at runtime.
+Actually this rule would drop the conversion principle at all.
-==Appendix: Conversion principle at runtime==
+==Appendix==
 The ''Conversion Principle'' can be violated at runtime:
 <eiffel>

@@ Line 36: / Line 36: @@
 What VYCQ(3) asks is the following
-  Is A [ANY] conform to A [G]?
+  Is <e>A [ANY]</e> conform to <e>A [G]</e>?
 The answer is '''no''' and thus the code regarded as valid.
@@ Line 65: / Line 65: @@
 The interesting rule is again '''VYCQ(3)''':
-  Is A [ANY] conform to A [STRING]?
+  Is <e>A [ANY]</e> conform to <e>A [STRING]</e>?
 The answer is '''no''' and thus the code regarded as valid.
@@ Line 91: / Line 91: @@
 '''VYCQ(3)''':
-  Is A [ANY,ANY] conform to A [G,G]?
+  Is <e>A [ANY,ANY]</e> conform to <e>A [G,G]</e>?
 The answer is '''no''' and thus the code regarded as valid.
@@ Line 122: / Line 122: @@
 '''VYCQ(3)''':
-  Is B [ANY] conform to A [STRING]?
+  Is <e>B [ANY]</e> conform to <e>A [STRING]</e>?
 The answer is '''no''' and thus the code regarded as valid.
@@ Line 153: / Line 153: @@
 '''VYCQ(3)''':
-  Is B[INTEGER,DOUBLE] conform to A[DOUBLE,INTEGER]?
+  Is <e>B[INTEGER,DOUBLE]</e> conform to <e>A[DOUBLE,INTEGER]</e>?
 The answer is '''no''' and thus the code regarded as valid.
@@ Line 183: / Line 183: @@
 '''VYCQ(3)''':
-  Is B [INTEGER_REF] conform to A [DOUBLE]?
+  Is <e>B [INTEGER_REF]</e> conform to <e>A [DOUBLE]</e>?
 The answer is '''no''' and thus the code regarded as valid.
@@ Line 226: / Line 226: @@
 '''Example 4 for VYCQ'(2):'''
-   Is B [*] conform to A [STRING]?
+   Is <e>B [*]</e> conform to <e>A [STRING]</e>?
 The answer is '''no''' and therefore the code '''valid'''.<br>
@@ Line 234: / Line 234: @@
 '''Example 5 for VYCQ'(2):'''
-  Is B [INTEGER,DOUBLE] conform to A [DOUBLE,INTEGER]?
+  Is <e>B [INTEGER,DOUBLE]</e> conform to <e>A [DOUBLE,INTEGER]</e>?
 The answer is '''no''' and therefore the code '''valid'''.
@@ Line 240: / Line 240: @@
 '''Example 6 for VYCQ'(2):'''
-  Is B [*] conform to A [DOUBLE]?
+  Is <e>B [*]</e> conform to <e>A [DOUBLE]</e>?
 The answer is '''yes''' and therefore the code '''valid'''. But it should be '''invalid''' because the constraint INTEGER_REF and the fact that DOUBLE is frozen make it impossible to create a type which satisfies both, the conformance to INTEGER_REF and to DOUBLE.
@@ Line 253: / Line 253: @@
 * If CT inherits from the base class of TARGET, we call that derivation of the same base class CPCT (for corresponding parent of CT).
   In Example 6:
-  B inherits from A.
+  <e>B</e> inherits from <e>A</e>.
-  TARGET: A [DOUBLE]
+  TARGET: <e>A [DOUBLE]</e>
-  CPCT: A [G]
+  CPCT: <e>A [G]</e>
 If that is true, the generic derivation might contain formal generic parameters. We perform a pattern matching and replace the formals with the according derivation found in the type we convert to.
@@ Line 261: / Line 261: @@
   Formal G in CPCT has position 1.
-  The type at position 1 in TARGET is DOUBLE.
+  The type at position 1 in TARGET is <e>DOUBLE</e>.
-  We replace the formal G in CT with DOUBLE and obtain TTC: B [DOUBLE]
+  We replace the formal G in CT with <e>DOUBLE</e> and obtain TTC: <e>B [DOUBLE]</e>
 We take this type and check whether it satisfies the constraint and is conform to the type we convert to. If both hold at the same time there exists a valid derivation of CT and therefore the ''Conversion Principle'' violated.
 * Check whether TTC is a valid generic derivation of CT and whether it conforms to TARGET
-  B [DOUBLE] does '''not''' satisfy the constraint (INTEGER_REF).
+  <e>B [DOUBLE]</e> does '''not''' satisfy the constraint (<e>INTEGER_REF</e>).
-  B [DOUBLE] is conform to TARGET (A [DOUBLE]).
+  <e>B [DOUBLE]</e> is conform to TARGET (<e>A [DOUBLE]</e>).
   As not both statements hold it is a valid conversion.

@@ Line 210: / Line 210: @@
 We define an additional function ''FTN'' which replaces every formal generic with another type:
-* By a wildcard type, which is conform to anything if the formals constraint type is not frozen.
+* By a wildcard type (*), which is conform to anything if the formals constraint type is not frozen.
 * By the (single) frozen type which occurs in the constraint of the formal.
@@ Line 226: / Line 226: @@
 '''Example 4 for VYCQ'(2):'''
-   Is B[WILDCARD] conform to A[STRING]?
+   Is B[*] conform to A[STRING]?
 The answer is '''no''' and therefore the code '''valid'''.<br>
@@ Line 240: / Line 240: @@
 '''Example 6 for VYCQ'(2):'''
-  Is B[WILDCARD] conform to A[DOUBLE]?
+  Is B[*] conform to A[DOUBLE]?
 The answer is '''yes''' and therefore the code '''valid'''. But it should be '''invalid''' because the constraint INTEGER_REF and the fact that DOUBLE is frozen make it impossible to create a type which satisfies both, the conformance to INTEGER_REF and to DOUBLE.

@@ Line 194: / Line 194: @@
 ==Understanding the matter==
 If we take the inheritance hierarchy of an Eiffel system it can be abstracted to a directed acyclic graph. A an valid type T for conversion has the following properties:
@@ Line 201: / Line 203: @@
 All these properties include the normal cases (for example CT contains no formals).
-The following illustration shows where conversion is valid and where not and might help to visualize the various issues a little bit.
+The illustration on the right shows where conversion is valid and might help to visualize the matter a little bit.