The MEF specification doesn't discuss or implicit about
Expressions' parameter and return value types.
Example 1.
<parameter name="type-unsafe">
<div>
<int value="42"/>
<bool value="true"/>
</div>
</parameter>
Strictly, Example 1 expression doesn't make sense.
This would produce type errors in strongly-typed system (e.g, Haskell);
however, weakly-typed languages would succeed with implicit bool->int conversion.
Example 2.
<parameter name="integer-div">
<div>
<int value="42"/>
<int value="4"/>
</div>
</parameter>
<parameter name="float-div">
<div>
<float value="42"/>
<float value="4"/>
</div>
</parameter>
Example 2 is overloading with integer division returning integer
and float division returning float;
Note that these overloads return different values (10 vs. 10.5)
and have different semantics
even though the argument values are equal.
Example 3.
<parameter name="implicit-cast">
<ite>
<int value="42"/> <!-- This is condition -->
<float value="1.0"/>
<int value="1"/>
</ite>
</parameter>
Examples 3 would produce type errors in strongly-typed system,
weak system would convert 42 into true and succeed;
moreover, due to type mismatch in different arms of the expression,
the return type is float.
The simplest solution from specification and implementation points of view
is to adopt the weak typing of the C language with no overloading.
If an Expression needs to be generic (e.g., div, mul),
the parameter and return types can be float.
I suspect that the MEF authors being C programmers
assumed the C-type system for numbers but forgot to mention it :).
The MEF specification doesn't discuss or implicit about
Expressions' parameter and return value types.
Example 1.
Strictly, Example 1 expression doesn't make sense.
This would produce type errors in strongly-typed system (e.g, Haskell);
however, weakly-typed languages would succeed with implicit
bool->intconversion.Example 2.
Example 2 is overloading with integer division returning integer
and float division returning float;
Note that these overloads return different values (10 vs. 10.5)
and have different semantics
even though the argument values are equal.
Example 3.
Examples 3 would produce type errors in strongly-typed system,
weak system would convert
42intotrueand succeed;moreover, due to type mismatch in different arms of the expression,
the return type is
float.The simplest solution from specification and implementation points of view
is to adopt the weak typing of the C language with no overloading.
If an Expression needs to be generic (e.g.,
div,mul),the parameter and return types can be
float.I suspect that the MEF authors being C programmers
assumed the C-type system for numbers but forgot to mention it :).