Interval types - Revision history

Bmeyer: /* Expanded and Void */

2007-07-20T03:24:10Z

‎Expanded and Void

Bmeyer: Fixed terminology (argument vs parameter, generic derivation)

2007-07-20T03:23:02Z

Fixed terminology (argument vs parameter, generic derivation)

Juliant at 03:00, 6 July 2007

2007-07-06T03:00:09Z

Juliant: /* Conclusion */

2007-07-06T02:45:12Z

‎Conclusion

Juliant at 02:16, 6 July 2007

2007-07-06T02:16:41Z

New page

[[Category:ECMA]]
[[Category:Catcall]]
{{Research}}
== Introduction ==

With interval types, the programmer can restrict the conforming types for an entity. This way, the type set which needs to be checked for system validity of a feature call is restricted to a smaller set of types. In addition, certain rules for generic types will prohibit the unsafe use of generics.

== Syntax ==

At every location where a normal type is expected, an interval type can be specified by adding an upper bound for each type:

<e>
LOWER..UPPER
</e>

This specifies an interval of all types between the types <e>LOWER</e> and <e>UPPER</e>.

== Semantics ==

The intention of an interval type is to specify that an entity can only be attached to a type which lies inside the interval. Thus a type declared as <e>ANY..STRING</e> can be attached to an object of dynamic type <e>ANY</e> or dynamic type <e>STRING</e>. It cannot be attached to an object of a type which lies outside this interval, for example <e>INTEGER</e> or <e>PATH_NAME</e>.

Each interval type describes the set of types which belong to the interval. A type belongs to the inverval if it conforms to the lower bound (<e>LOWER</e>) and if the upper bound (<e>UPPER</e>) conforms to it.

<e>
a: A .. C <=> {A, B, C}
b: A .. B <=> {A, B}
c: A .. NONE <=> {A, B, C, ...}
</e>

=== Conformance rules ===

An interval type ''b'' conforms to an interval type ''a'' if it is a sub-interval of ''a''. So if ''a'' fully encloses the interval ''b'', ''b'' conforms to ''a''.

The conformance rules can also be explained by differently:

* An interval type ''b'' conforms to an interval type ''a'' if the set of types described by the interval of ''b'' is a subset of the set described by the interval of ''a''.

:<e>
a := b -- Is valid as {A, B} is a subset of {A, B, C}
</e>

* A type <e>b: C..D</e> conforms to the type <e>a: A..B</e> if <e>C</e> conforms to <e>A</e> and <e>B</e> conforms to <e>D</e>.

Generic conformance is the same as it is now: A generic type ''b'' conforms to a generic type ''a'' if the base class of ''b'' conforms to ''a'' and all generic parameters conform as well.

=== Generic features ===

For features with formal arguments, another rule exists: A call on a feature wich contains a formal argument is only valid if the generic substitution is monomorphic.

This means that a call on a feature <e>f (g: G)</e> of a class <e>X [G]</e> is only valid if <e>G</e> is monomorphic. Thus the type has to be instantitated with <e>X [Y..Y]</e>. So a call to <e>f</e> on a type <e>X [Y..NONE]</e> is not allowed.

=== Default behaviour ===

As a shorthand for interval definition, we define the following default behaviour which is different for ordinary types and for actual generic type parameters. Ordinary types are per default polymorphic and actual formal parameters monomorphic:

<e>
x: T <=> T .. NONE
y: A [T] <=> A [T .. T] .. NONE
</e>

== Examples ==

See the [[introduction to examples]] for information about the classes used.

=== Cats and dogs ===

A feature call on a target ''t'' is only valid if it is valid for all polymorphic types which can possibly be assigned to ''t''. With interval types the set of conforming types can be restriced in order to be able to perform calls to features which are covariantly redefined in descendands by excluding such descendants from the dynamic type set.

<e>
a_none: ANIMAL <=> ANIMAL .. NONE
c_none: CAT <=> ANIMAL .. NONE
d_none: DOG <=> ANIMAL .. NONE
a_a: ANIMAL .. ANIMAL
c_c: CAT .. CAT
d_d: DOG .. DOG
a_c: ANIMAL .. CAT
a_d: ANIMAL .. DOG
</e>

Valid assignments:

<e>
a_none := c_none
a_none := d_none
a_none := a_a
a_none := c_c
a_none := d_d
c_none := c_c
d_none := d_d

a_c := a_a
a_c := c_c
a_d := a_a
a_d := d_d
</e>

Invalid assignments:

<e>
-- Invalid: a_a := a_none
-- Invalid: c_c := c_none
-- Invalid: d_d := d_none
-- Invalid: a_c := c_none
-- Invalid: a_d := d_none
</e>

Valid calls:

<e>
a_none.eat (cat_food)
a_a.eat (food)
a_d.eat (food)
</e>

Invalid calls:

<e>
a_none.eat (food)
</e>

=== A simple generic algorithm ===

It is easy to declare an algorithm which needs only read-access on a list:

<e>
class PERSON_PRINTER
feature
print_all (a_list: LIST [PERSON..NONE])
-- Print all attributes of each person in the list.
do
from
a_list.start
until
a_list.after
do
-- Reading is valid on a covariant list
a_list.item.print
end
end
end

class EXAMPLE
feature
make
local
l_students: LIST [STUDENT] <=> LIST [STUDENT..STUDENT]
l_professors: LIST [PROFESSOR] <=> LIST [PROFESSOR..PROFESSOR]
l_person_printer: PERSON_PRINTER
do
create l_person_printer
-- LIST [STUDENT..STUDENT] conforms to LIST [PERSON..NONE]
l_person_printer.print_all (l_students)
-- LIST [PROFESSOR..PROFESSOR] conforms to LIST [PERSON..NONE]
l_person_printer.print_all (l_professor)
end
end
</e>

== Issues ==

=== Generic features ===

The rule about calling features with formal parameters is too restrictive. Let's look at the following code:

<e>
deferred class COMPONENT
end

class COMPOSITE
inherit COMPONENT
feature
components: LIST [COMPONENT]
end
</e>

What should the type of feature <e>components</e> be? In order to be able to call <e>extend</e> on the list, it has to be monomorphic, thus <e>LIST [COMPONENT..COMPONENT]</e>. But since the argument type is now <e>COMPONENT..COMPONENT</e> we actually cannot add anything to the list as no descendant of <e>COMPONENT</e> is in the interval. Actually, since <e>COMPONENT</e> is deferred nothing can be added to the list at all.

But if we define the list as <e>LIST [COMPONENT..NONE]</e> - thus allowing descendants of <e>COMPONENT</e> in the list - then the rule about features with formal arguments disallows any calls to feature <e>extend</e> as the argument is not monomorphic anymore.

=== Expanded and Void ===

Look at the following code snippet:

<e>
local
any_none: ANY..NONE
any_string: ANY..STRING
do
-- invalid as NONE does not conform to INTEGER
any_none := 5
-- invalid as NONE is not in the interval ANY..STRING
any_string := Void
end
</e>

It illustrates two problems in conjunction with <e>NONE</e>:

* The first is that <e>NONE</e> does not conform to expanded types. This makes it impossible to declare a type interval which includes all types in the system, reference or expanded. This prevents the programmer to write code which works with reference types and expanded types, say a generic print algorithm.
* The second one is that <e>Void</e> is of type <e>NONE</e>. This raises the question how <e>Void</e> should be assigned to an interval type of references, or how such a type is initialized in the first place.

== Conclusion ==

The rule about features with formal parameters must be changed to make this solution usable as otherwise the use of generics is restricted too much.

The problem with <e>Void</e> and <e>NONE</e> can easily be solved by declaring that <e>NONE</e> inherits from all types regardless of reference or expanded status. To solve the problem of assigning <e>Void</e> to an interval type it can be defined that <e>Void</e> is of any (detached) reference type. That way it can be assigned to any interval of a refernce type, even a monomorphic one, and it is still disallowed to assign it to expanded types.

@@ Line 48: / Line 48: @@
 For features with formal arguments, another rule exists: A call on a feature which contains a formal argument is only valid if the generic substitution is monomorphic.
-This means that a call on a feature <e>f (g: G)</e> of a class <e>X [G]</e> is only valid if <e>G</e> is monomorphic. Thus the type has to be instantiated with <e>X [Y..Y]</e>. So a call to <e>f</e> on a type <e>X [Y..NONE]</e> is not allowed.
+This means that a call on a feature <e>f (g: G)</e> of a class <e>X [G]</e> is only valid if <e>G</e> is monomorphic. Thus the type has to be generically derived with <e>X [Y..Y]</e>. So a call to <e>f</e> on a type <e>X [Y..NONE]</e> is not allowed.
 === Default behaviour ===
@@ Line 161: / Line 161: @@
 === Generic features ===
-The rule about calling features with formal parameters is too restrictive. Let's look at the following code:
+The rule about calling features with formal arguments is too restrictive. Let's look at the following code:
 <e>
@@ Line 201: / Line 201: @@
 == Conclusion ==
-The rule about features with formal parameters must be changed to make this solution usable as otherwise the use of generics is restricted too much.
+The rule about features with formal arguments must be changed to make this solution usable as otherwise the use of generics is restricted too much.
 The problem with <e>Void</e> and <e>NONE</e> can easily be solved by declaring that <e>NONE</e> inherits from all types regardless of reference or expanded status. To solve the problem of assigning <e>Void</e> to an interval type it can be defined that <e>Void</e> is of any (detached) reference type. You could for example say that <e>Void</e> always has the type of the lower bound of the target interval if this type is a (detached) reference type. That way it can be assigned to any interval of a reference type, even a monomorphic one, and it is still disallowed to assign it to expanded types.

@@ Line 20: / Line 20: @@
 The intention of an interval type is to specify that an entity can only be attached to a type which lies inside the interval. Thus a type declared as <e>ANY..STRING</e> can be attached to an object of dynamic type <e>ANY</e> or dynamic type <e>STRING</e>. It cannot be attached to an object of a type which lies outside this interval, for example <e>INTEGER</e> or <e>PATH_NAME</e>.
-Each interval type describes the set of types which belong to the interval. A type belongs to the inverval if it conforms to the lower bound (<e>LOWER</e>) and if the upper bound (<e>UPPER</e>) conforms to it.
+Each interval type describes the set of types which belong to the interval. A type belongs to the interval if it conforms to the lower bound (<e>LOWER</e>) and if the upper bound (<e>UPPER</e>) conforms to it.
 <e>
@@ Line 46: / Line 46: @@
 === Generic features ===
-For features with formal arguments, another rule exists: A call on a feature wich contains a formal argument is only valid if the generic substitution is monomorphic.
+For features with formal arguments, another rule exists: A call on a feature which contains a formal argument is only valid if the generic substitution is monomorphic.
-This means that a call on a feature <e>f (g: G)</e> of a class <e>X [G]</e> is only valid if <e>G</e> is monomorphic. Thus the type has to be instantitated with <e>X [Y..Y]</e>. So a call to <e>f</e> on a type <e>X [Y..NONE]</e> is not allowed.
+This means that a call on a feature <e>f (g: G)</e> of a class <e>X [G]</e> is only valid if <e>G</e> is monomorphic. Thus the type has to be instantiated with <e>X [Y..Y]</e>. So a call to <e>f</e> on a type <e>X [Y..NONE]</e> is not allowed.
 === Default behaviour ===
@@ Line 65: / Line 65: @@
 === Cats and dogs ===
-A feature call on a target ''t'' is only valid if it is valid for all polymorphic types which can possibly be assigned to ''t''. With interval types the set of conforming types can be restriced in order to be able to perform calls to features which are covariantly redefined in descendands by excluding such descendants from the dynamic type set.
+A feature call on a target ''t'' is only valid if it is valid for all polymorphic types which can possibly be assigned to ''t''. With interval types the set of conforming types can be restricted in order to be able to perform calls to features which are covariantly redefined in descendants by excluding such descendants from the dynamic type set.
 <e>
@@ Line 203: / Line 203: @@
 The rule about features with formal parameters must be changed to make this solution usable as otherwise the use of generics is restricted too much.
-The problem with <e>Void</e> and <e>NONE</e> can easily be solved by declaring that <e>NONE</e> inherits from all types regardless of reference or expanded status. To solve the problem of assigning <e>Void</e> to an interval type it can be defined that <e>Void</e> is of any (detached) reference type. You could for example say that <e>Void</e> always has the type of the lower bound of the target interval if this type is a (detached) reference type. That way it can be assigned to any interval of a refernce type, even a monomorphic one, and it is still disallowed to assign it to expanded types.
+The problem with <e>Void</e> and <e>NONE</e> can easily be solved by declaring that <e>NONE</e> inherits from all types regardless of reference or expanded status. To solve the problem of assigning <e>Void</e> to an interval type it can be defined that <e>Void</e> is of any (detached) reference type. You could for example say that <e>Void</e> always has the type of the lower bound of the target interval if this type is a (detached) reference type. That way it can be assigned to any interval of a reference type, even a monomorphic one, and it is still disallowed to assign it to expanded types.

← Older revision		Revision as of 02:45, 6 July 2007
Line 203:		Line 203:
	The rule about features with formal parameters must be changed to make this solution usable as otherwise the use of generics is restricted too much.		The rule about features with formal parameters must be changed to make this solution usable as otherwise the use of generics is restricted too much.

−	The problem with <e>Void</e> and <e>NONE</e> can easily be solved by declaring that <e>NONE</e> inherits from all types regardless of reference or expanded status. To solve the problem of assigning <e>Void</e> to an interval type it can be defined that <e>Void</e> is of any (detached) reference type. That way it can be assigned to any interval of a refernce type, even a monomorphic one, and it is still disallowed to assign it to expanded types.	+	The problem with <e>Void</e> and <e>NONE</e> can easily be solved by declaring that <e>NONE</e> inherits from all types regardless of reference or expanded status. To solve the problem of assigning <e>Void</e> to an interval type it can be defined that <e>Void</e> is of any (detached) reference type. You could for example say that <e>Void</e> always has the type of the lower bound of the target interval if this type is a (detached) reference type. That way it can be assigned to any interval of a refernce type, even a monomorphic one, and it is still disallowed to assign it to expanded types.

@@ Line 196: / Line 196: @@
 It illustrates two problems in conjunction with <e>NONE</e>:
-* The first is that <e>NONE</e> does not conform to expanded types. This makes it impossible to declare a type interval which includes all types in the system, reference or expanded. This prevents the programmer to write code which works with reference types and expanded types, say a generic print algorithm.
+* The first is that <e>NONE</e> does not conform to expanded types. This makes it impossible to declare a type interval which includes all types in the system, reference or expanded. This prevents the programmer from writing code that works with reference types and expanded types, say a generic print algorithm.
 * The second one is that <e>Void</e> is of type <e>NONE</e>. This raises the question how <e>Void</e> should be assigned to an interval type of references, or how such a type is initialized in the first place.