19.11.2014 Views

The Fortress Language Specification - CiteSeerX

The Fortress Language Specification - CiteSeerX

The Fortress Language Specification - CiteSeerX

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

coercions:<br />

T U ⇐⇒ T ♦ U ∧ T −〉 U ∧ U−〉 T ∧ T ≬ U<br />

⇐⇒ T ♦ U<br />

∧ (∀A : A→T =⇒ A ♦ U)<br />

∧ (∀B : B →U =⇒ B ♦ T)<br />

∧ (∀A, B : A→T ∧ B →U =⇒ A ♦ B)<br />

Note that if T U then no type is substitutable for both T and U.<br />

<strong>The</strong> Incompatibility Rule for Functions and Functional Methods: Suppose that f (P) and f (Q) are two distinct<br />

function or functional method declarations both visible at some point Z in a <strong>Fortress</strong> program (Z need not be the site<br />

of a call). If P Q then f (P) and f (Q) are valid overloadings.<br />

<strong>The</strong> Incompatibility Rule for Dotted Methods: Suppose that P 0 .f (P) and Q 0 .f (Q) are two distinct dotted method<br />

declarations provided by a trait or object C. If P Q then P 0 .f (P) and Q 0 .f (Q) are valid overloadings.<br />

33.4 More Specific Rule<br />

If neither the Subtype Rule nor the Incompatibility Rule holds for a pair of overloaded declarations then they may<br />

still be valid overloadings if the More Specific Rule is satisfied. <strong>The</strong> More Specific Rule requires that for any two<br />

declarations there exists a third applicable declaration that is at least as specific as both.<br />

This rule is complicated by the fact that functions and functional methods can overload. Recall that functional methods<br />

can be viewed semantically as top-level functions, as described in Section 9.2. However, treating functional methods<br />

as top-level functions for determining valid overloading is too restrictive. In the following example:<br />

trait Z<br />

opr −(self): Z<br />

end<br />

trait R<br />

opr −(self): R<br />

end<br />

if the functional methods were interpreted as top-level functions then this program would define two top-level functions<br />

with parameter types Z and R . <strong>The</strong>se declarations would be statically rejected as invalid overloadings because there<br />

is no relation between Z and R ; another trait may extend them both without declaring its own version of the functional<br />

method which may lead to an ambiguous call at run time. To allow such overloading, we define different restrictions<br />

on overloaded function declarations and overloaded functional method declarations. When function and functional<br />

method declarations are overloaded, the more restrictive rule for function declarations is used. This rule follows.<br />

<strong>The</strong> More Specific Rule for Functions and Functional Methods: Suppose that f (P) and f (Q) are two function<br />

or functional method declarations both visible at some point Z in a <strong>Fortress</strong> program (Z need not be the site of a call)<br />

such that neither P nor Q is a subtype of the other and P and Q are not incompatible with one another. Let S be the<br />

set of types that P defines coercions from and T be the set of types that Q defines coercions from. f (P) and f (Q) are<br />

valid overloadings if all of the following hold:<br />

• either P ♦ Q or there is a declaration f (P ∩ Q) visible at Z, and<br />

• either P ⊳ Q or Q ⊳ P or for all P ′ ∈ S and Q ′ ∈ T one of the two conditions holds:<br />

229

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!