Convertibility semantic

Validity rule

Convert clause rule VNCP:

A Convert_clause in the Convert part of a class C, with current type CT,
is valid if and only if it satisfies the following conditions, for
every Feature_identifier cp_name and every type CONVERSION_TYPE in the clause:

C is effective.
cp_name appears only once in the Feature_list.
cp_name is the final name of some routine cp of C.
cp_name is not a once routine.
CONVERSION_TYPE does not have anchors.
If CT is not generic, CONVERSION_TYPE does not conform to CT.
if CT is generic, CONVERSION_TYPE does not conform to the type obtained from CT 
  by replacing every formal generic parameter by its generic constraint.
cp_name is either a procedure with exactly one formal argument or a function
with return type of type ARG.
if cp_name is a procedure, it is also a creation procedure of C and SOURCE conforms or converts to ARG.
if cp_name is a function, CONVERSION_TYPE is exactly ARG or converts to ARG.
CONVERSION_TYPE’s base type is different from the base type of any other 
conversion type listed in the Convert_clause of C for all listed
procedure, and symmetrically for all listed function.

Conversion Feature VNCP rule as specified in ETL3 draft:

It is valid for a creation procedure cp of a class C, with current
type CT, to be a conversion procedure if and only if it satisfies the
following four conditions for every type SOURCE listed in its
Conversion_types:

  If CT is not generic, SOURCE does not conform to CT.
  If CT is generic, SOURCE does not conform to the type obtained from CT 
  by replacing every formal generic parameter by its generic constraint.
  cp has exactly one formal argument, of a type ARG.
  SOURCE conforms or converts to ARG.
  SOURCE’s base type is different from the base type of any other 
  conversion type listed in the Creation_clause of C.

Note that the above rules is not complete. See Checking below for details on what needs to be checked. Hopefully ETL3 will be updated accordingly.

Checking

We initialize conversion data at degree 4 using the AST, by creating two hash tables in CLASS_C, whose elements are feature_name_id indexed by the type to or from which they convert to or from:

convert_to: HASH_TABLE [INTEGER, CL_TYPE_A]
convert_from: HASH_TABLE [INTEGER, CL_TYPE_A]

Then we ensure that content of convert_to and convert_from is valid from two points of view:

types are valid
features are valid for conversion, i.e. having the right arguments and return types

We also check at this point the incrementality aspect (see below).

Before starting degree 3, we check that there are no 2 classes which both convert to or from each other. That is to say for two classes A and B, if in class A class B appears in convert_to, then in class B class A should not appear in convert_from. Reciprocally, if in class A class B appears in convert_from, then in class B class A should not appear in convert_to.

During degree 3, each time that a type convert but does not conform, we add the associated type information and byte code to perform the conversion call, unless it is for the basic types where we introduce special new byte code for conversions, that way it simplifies our interpreter for melted code (by not having that many switch statements) and makes our C generated code completely blind for basic type conversions (it does what it is told to do).

Note that if during degree 3 the conversion routine does not have a sufficient export status for the current processed class, we should raise an error.

Infix checking

When checking for "a op b" (a of type A, b of type B), we check first if `op' is an operation of `a', then if `B' conforms or converts to the type of the expected parameter of `op'. If not, we check if `A' converts to `B' and if `B' has an infix routine `op' whose argument is of type B.

Incrementality

If a conversion routine is added or removed, what should we do? During degree 3, each time we record a conversion feature, we record a depend unit, so at degree 4, we can perform the same process as for creation procedure to propagate the type checking of code at degree 3 to ensure all the code is still valid.

Convertibility checking

Definition

How do we know if given two types A and B, if A converts to B?

We check that if B has a convert_from structure, that it contains A, if not we check that if A has a convert_to structure, that it contains B.

When check it?

We need to check convertibility after conformance in:

binary operators (for target only)
assignments
argument passing
manifest tuple creation where given type does not match expected type.

Generated code

Nothing special, at degree 3 during byte code generation we have inserted the required byte code information for this. We do a blind generation.

Library changes

INTEGER_8

converts to: INTEGER_16, INTEGER_32, INTEGER_64, REAL, DOUBLE

INTEGER_16

converts to: INTEGER_32, INTEGER_64, REAL, DOUBLE

INTEGER_32

converts to: INTEGER_64, REAL, DOUBLE

INTEGER_64

converts to: REAL, DOUBLE

REAL

converts to: DOUBLE