Single-level call rule and generics - Revision history

Bmeyer: /* Monomorphic formal generics */

2007-11-05T18:25:05Z

‎Monomorphic formal generics

2007-11-05T18:18:57Z

‎Monomorphic formal generics

2007-11-05T18:11:53Z

‎Monomorphic formal generics

2007-11-05T18:11:34Z

2007-11-05T18:11:12Z

2007-11-05T18:10:03Z

2007-11-04T17:44:56Z

Monomorphic

2007-07-14T18:58:07Z

‎Monomorph formal generics

2007-07-14T18:32:06Z

‎Monomorph formal generics

2007-07-14T01:01:23Z

@@ Line 37: / Line 37: @@
 The first idea is to be able to mark a formal generic as monomorphic:
 <e>
-class X [monomorphic G -> NUMERIC]
+class X [monomorphic G -> NUMERIC] feature
    f (g1, g2: G): G

← Older revision		Revision as of 18:18, 5 November 2007
Line 48:		Line 48:

	The class can then only be generically derived with monomorphic types, i.e. using [[interval types]] <e>X [INTEGER..INTEGER]</e> or <e>X [REAL..REAL]</e>.		The class can then only be generically derived with monomorphic types, i.e. using [[interval types]] <e>X [INTEGER..INTEGER]</e> or <e>X [REAL..REAL]</e>.
		+
		+	[Comment by BM 5 Nov 2007: this does not seem desirable as there is nothing
		+	wrong with the class, only with the feature.]

	For the check we can now assume that <e>G</e> will be monomorphic. This helps a little bit further: For every feature argument which is <e>like Current</e> we can assume that the exact type will be given. But this works only for covariant features which have <e>like Current</e> arguments which are never redefined into something else. Take the following classes for an example:		For the check we can now assume that <e>G</e> will be monomorphic. This helps a little bit further: For every feature argument which is <e>like Current</e> we can assume that the exact type will be given. But this works only for covariant features which have <e>like Current</e> arguments which are never redefined into something else. Take the following classes for an example:

@@ Line 47: / Line 47: @@
 </e>
-The generic class can then only be generically derived with monomorphic types, i.e. using [[interval types]] <e>X [INTEGER..INTEGER]</e> or <e>X [REAL..REAL]</e>.
+The class can then only be generically derived with monomorphic types, i.e. using [[interval types]] <e>X [INTEGER..INTEGER]</e> or <e>X [REAL..REAL]</e>.
 For the check we can now assume that <e>G</e> will be monomorphic. This helps a little bit further: For every feature argument which is <e>like Current</e> we can assume that the exact type will be given. But this works only for covariant features which have <e>like Current</e> arguments which are never redefined into something else. Take the following classes for an example:

@@ Line 29: / Line 29: @@
 The problem is that the formal generic <e>G</e> is always assumed to be of any type which satisfies the constraint, so normally the formal generic is polymorphic.
-As the above example show, the use of features on formal generic parameters which are covariantly redefined is severely limited. But as the purpose of <e>NUMERIC</e> is exactly to allow creation of generic algorithms over numeric types, this has to be addressed (Note that also <e>COMPARABLE</e> is a problem).
+As the above example show, the use of features on formal generic parameters which are covariantly redefined is severely limited. But as the purpose of <e>NUMERIC</e> is exactly to allow creation of generic algorithms over numeric types, this has to be addressed (Note that <e>COMPARABLE</e> is also a problem).
 == Possible solutions ==

@@ Line 3: / Line 3: @@
 == Problem ==
-The single-level call rule says that every call has to be valid for all possible dynamic types of an entity. So for a formal generic <e>G</e> this means that the call has to be valid for all possible descendants of the constraint (or at least for every instantiation which happens in a system).
+The single-level call rule says that every call has to be valid for all possible dynamic types of an entity. So for a formal generic <e>G</e> this means that the call has to be valid for all possible descendants of the constraint (or at least for every generic derivation that occurs in a system).
 Let's look at an example using <e>NUMERIC</e>:
@@ Line 47: / Line 47: @@
 </e>
-The generic class can then only be instantiated with monomorphic types, i.e. using [[interval types]] <e>X [INTEGER..INTEGER]</e> or <e>X [REAL..REAL]</e>.
+The generic class can then only be generically derived with monomorphic types, i.e. using [[interval types]] <e>X [INTEGER..INTEGER]</e> or <e>X [REAL..REAL]</e>.
 For the check we can now assume that <e>G</e> will be monomorphic. This helps a little bit further: For every feature argument which is <e>like Current</e> we can assume that the exact type will be given. But this works only for covariant features which have <e>like Current</e> arguments which are never redefined into something else. Take the following classes for an example:

@@ Line 33: / Line 33: @@
 == Possible solutions ==
-=== Monomorph formal generics ===
+=== Monomorphic formal generics ===
-The first idea is to be able to mark a formal generic as monomorph:
+The first idea is to be able to mark a formal generic as monomorphic:
 <e>
-class X [monomorph G -> NUMERIC]
+class X [monomorphic G -> NUMERIC]
    f (g1, g2: G): G
@@ Line 75: / Line 75: @@
 <e>
-class X [monomorph G -> A]
+class X [monomorphic G -> A]
 feature
+   f

@@ Line 88: / Line 88: @@
 The call to <e>g1.f</e> is not valid since <e>G</e> could be of type <e>C</e>, and then the argument has to be of type <e>D</e>. So now, not even the <e>like Current</e> feature is callable with monomorphic generics. Basically it is the same as the declaration without ''monomorphic'' for the generic.
-So this solution works only for the case of <e>like Current</e> features which are never redefined. Only then it can be guaranteed for a monomorphic generic formal, that the signature will match the formal generic exactly. Other covariant features have still to be valid for all possible descendants.
+So this solution works only for the case of <e>like Current</e> features never change the signature. Only then it can be guaranteed for a monomorphic generic formal, that the signature will match the formal generic exactly. Other covariant features have still to be valid for all possible descendants.
 For the case of <e>NUMERIC</e> and <e>COMPARABLE</e> the use of monomorphic formal arguments would work as they define only <e>like Current</e> features which are normally kept that way in subclasses. A more general mechanism would be nice but at the moment it is unclear how such a mechanism should look like.

@@ Line 90: / Line 90: @@
 So this solution works only for the case of <e>like Current</e> features which are never redefined. Only then it can be guaranteed for a monomorphic generic formal, that the signature will match the formal generic exactly. Other covariant features have still to be valid for all possible descendants.
-For the case of <e>NUMERIC</e> and <e>COMPARABLE</e> the use of monomorphic formal arguments would work as they define only <e>like Current</e> features which are normally not redefined in subclasses. A more general mechanism would be nice but at the moment it is unclear how such a mechanism should look like.
+For the case of <e>NUMERIC</e> and <e>COMPARABLE</e> the use of monomorphic formal arguments would work as they define only <e>like Current</e> features which are normally kept that way in subclasses. A more general mechanism would be nice but at the moment it is unclear how such a mechanism should look like.
-−
 === Remodeling library ===

@@ Line 1: / Line 1: @@
 [[Category:ECMA]]
 [[Category:Catcall]]
 == Problem ==