Ignore:
Timestamp:
Sep 17, 2018, 4:21:10 PM (6 years ago)
Author:
Aaron Moss <a3moss@…>
Branches:
ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, no_list, persistent-indexer, pthread-emulation, qualifiedEnum
Children:
4075228, 4c42a5f, 72b0573, d21d01e5
Parents:
f9c7d27
Message:

Finish first draft of background chapter

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/aaron_moss_PhD/phd/background.tex

    rf9c7d27 r91a950c  
    7373Together, \CFA{}'s backward-compatibility with C and the inclusion of this operator overloading feature imply that \CFA{} must select among function overloads using a method compatible with C's ``usual arithmetic conversions''\cit{}, so as to present user programmers with only a single set of overloading rules.
    7474
    75 \subsection{Polymorphic Functions}
     75\subsubsection{Special Literal Types}
     76
     77Literal !0! is also used polymorphically in C; it may be either integer zero or the null value of any pointer type.
     78\CFA{} provides a special type for the !0! literal, !zero_t!, so that users can define a zero value for their own types without being forced to create a conversion from an integer or pointer type (though \CFA{} also includes implicit conversions from !zero_t! to the integer and pointer types for backward compatibility).
     79
     80According to the C standard\cit{}, !0! is the only false value; any value that compares equal to zero is false, while any value that does not is true.
     81By this rule, boolean contexts such as !if ( x )! can always be equivalently rewritten as \lstinline{if ( (x) != 0 )}.
     82\CFACC{} applies this rewriting in all boolean contexts, so any type !T! can be made ``truthy'' (that is, given a boolean interpretation) in \CFA{} by defining an operator overload \lstinline{int ?!=?(T, zero_t)}; unlike \CC{} prior to the addition of explicit casts in \CCeleven{}, this design does not add comparability or convertablity to arbitrary integer types.
     83
     84\CFA{} also includes a special type for !1!, !one_t!; like !zero_t!, !one_t! has built-in implicit conversions to the various integral types so that !1! maintains its expected semantics in legacy code.
     85The addition of !one_t! allows generic algorithms to handle the unit value uniformly for types where it is meaningful; a simple example of this is that polymorphic functions\footnote{discussed in Section~\ref{poly-func-sec}} in the \CFA{} prelude define !++x! and !x++! in terms of !x += 1!, allowing users to idiomatically define all forms of increment for a type !T! by defining the single function !T& ?+=?(T&, one_t)!; analogous overloads for the decrement operators are also present, and programmers can override any of these functions for a particular type if desired.
     86
     87\CFA{} previously allowed !0! and !1! to be the names of polymorphic variables, with separate overloads for !int 0!, !int 1!, and !forall(dtype T) T* 0!.
     88As revealed in my own work on generic types (Chapter~\ref{generic-chap}), the parameteric polymorphic zero variable was not generalizable to other types; though all null pointers have the same in-memory representation, the same cannot be said of the zero values of arbitrary types.
     89As such, variables that could represent !0! and !1! were phased out in favour of functions that could generate those values for a given type as appropriate.
     90
     91\subsection{Polymorphic Functions} \label{poly-func-sec}
    7692
    7793The most significant feature \CFA{} adds is parametric-polymorphic functions.
     
    309325\end{cfa}
    310326
    311 \subsubsection{0 and 1 Literals}
    312 
    313 % TODO mention own motivating contribution
    314 
    315 % TODO mention future work in user-defined implicit conversions
    316 
    317327\subsubsection{Tuple Types}
    318328
    319 % TODO "precludes some matching strategies"
     329\CFA{} adds \emph{tuple types} to C, a syntactic facility for referring to lists of values anonymously or with a single identifier.
     330An identifier may name a tuple, a function may return one, and a tuple may be implicitly \emph{destructured} into its component values.
     331The implementation of tuples in \CFACC{}'s code generation is based on the generic types introduced in Chapter~\ref{generic-chap}, with one compiler-generated generic type for each tuple arity.
     332This allows tuples to take advantage of the same runtime optimizations available to generic types, while reducing code bloat.
     333An extended presentation of the tuple features of \CFA{} can be found in \cite{Moss18}, but the following example shows the basics:
     334
     335\begin{cfa}
     336[char, char] x = ['!', '?']; $\C{// (1); tuple type and expression syntax}$
     337int x = 2; $\C{// (2)}$
     338
     339forall(otype T)
     340[T, T] swap( T a, T b ) { $\C{// (3)}$
     341        return [b, a]; $\C{// one-line swap syntax}$
     342}
     343
     344x = swap( x ); $\C{// destructure [char, char] x into two elements}$
     345$\C{// cannot use int x, not enough arguments}$
     346
     347void swap( int, char, char ); $\C{// (4)}$
     348
     349swap( x, x ); $\C{// (4) on (2), (1)}$
     350$\C{// not (3) on (2), (2) due to polymorphism cost}$
     351\end{cfa}
     352
     353Tuple destructuring breaks the one-to-one relationship between identifiers and values.
     354This precludes some argument-parameter matching strategies for expression resolution, as well as cheap interpretation filters based on comparing number of parameters and arguments.
     355As an example, in the call to !swap( x, x )! above, the second !x! can be resolved starting at the second or third parameter of !swap!, depending which interpretation of !x! was chosen for the first argument.
Note: See TracChangeset for help on using the changeset viewer.