\chapter{Introduction}

This thesis is exploratory work I did to understand, fix, and extend the \CFA type-system, specifically, the type resolver used to select polymorphic types among overloaded names.
The \CFA type-system has a number of unique features making it different from all other programming languages.

Overloading allows programmers to use the most meaningful names without fear of name clashes within a program or from external sources, like include files.
\begin{quote}
There are only two hard things in Computer Science: cache invalidation and naming things. --- Phil Karlton
\end{quote}
Experience from \CC and \CFA developers is that the type system implicitly and correctly disambiguates the majority of overloaded names, \ie it is rare to get an incorrect selection or ambiguity, even among hundreds of overloaded (variables and) functions.
In many cases, a programmer has no idea there are name clashes, as they are silently resolved, simplifying the development process.
Depending on the language, ambiguous cases are resolved using some form of qualification and/or casting.

One of the key goals in \CFA is to push the boundary on overloading, and hence, overload resolution.


\subsection{Operator Overloading}

Virtually all programming languages overload the arithmetic operators across the basic types using the number and type of parameters and returns.
Like \CC, \CFA also allows these operators to be overloaded with user-defined types.
The syntax for operator names uses the @'?'@ character to denote a parameter, \eg prefix and infix increment operators: @?++@, @++?@, and @?+?@.
\begin{cfa}
struct S { int i, j };
S @?+?@( S op1, S op2 ) { return (S){ op1.i + op2.i, op1.j + op2.j }; }
S s1, s2;
s1 = s1 @+@ s2;		 	$\C[1.75in]{// infix call}$
s1 = @?+?@( s1, s2 );	$\C{// direct call}\CRT$
\end{cfa}
The type system examines each call size and selects the best matching overloaded function based on the number and types of the arguments.
If there are mixed-mode operands, @2 + 3.5@, the type system, like in C/\CC, attempts (safe) conversions, converting the argument type(s) to the parameter type(s).


\subsection{Function Overloading}

Both \CFA and \CC allow function names to be overloaded, as long as their prototypes differ in the number and type of parameters and returns.
\begin{cfa}
void f( void );			$\C[1.75in]{// (1): no parameter}$
void f( char );			$\C{// (2): overloaded on the number and parameter type}$
void f( int, int );		$\C{// (3): overloaded on the number and parameter type}$
f( 'A' );				$\C{// select (2)}\CRT$
\end{cfa}
In this case, the name @f@ is overloaded depending on the number and parameter types.
The type system examines each call size and selects the best match based on the number and types of the arguments.
Here, there is a perfect match for the call, @f( 'A' )@ with the number and parameter type of function (2).

Ada, Scala, and \CFA type-systems also use the return type in resolving a call, to pinpoint the best overloaded name.
\begin{cfa}
int f( void );			$\C[1.75in]{// (4); overloaded on return type}$
double f( void );		$\C{// (5); overloaded on return type}$
int i = f();			$\C{// select (4)}$
double d = f();			$\C{// select (5)}\CRT$
\end{cfa}


\subsection{Variable Overloading}
Unlike almost all programming languages, \CFA has variable overloading within a scope, along with shadow overloading in nested scopes.
\begin{cfa}
void foo( double d );
int v;				    $\C[1.75in]{// (1)}$
double v;				$\C{// (2) variable overloading}$
foo( v );				$\C{// select (2)}$
{
	int v;				$\C{// (3) shadow overloading}$
	double v;			$\C{// (4) and variable overloading}$
	foo( v );			$\C{// select (4)}\CRT$
}
\end{cfa}
The \CFA type system simply treats overloaded variables as an overloaded function returning a value with no parameters.
Hence, no significant effort is required to support this feature.