Changeset 7ba60dd for doc/aaron_comp_II


Ignore:
Timestamp:
Jul 21, 2016, 12:05:38 PM (5 years ago)
Author:
Aaron Moss <a3moss@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, ctor, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc
Children:
481ad06
Parents:
0318c7a
Message:

Added tuples, references, literals, and deleted functions to complete draft of comp II section 2

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/aaron_comp_II/comp_II.tex

    r0318c7a r7ba60dd  
    206206As discussed above, any \CFA expression resolver must handle this possible infinite recursion somehow, but the combination of generic types with other language features makes this particular edge case occur somewhat frequently in user code.
    207207
    208 \subsection{Multiple Return Values}
     208\subsection{Tuple Types}
     209\CFA adds \emph{tuple types} to C, a facility for referring to multiple values with one name.
     210A variable may name a tuple, and a function may return one.
     211Particularly relevantly for resolution, a tuple may be automatically \emph{destructured} into a list of values, as in the ©swap© function below:
     212\begin{lstlisting}
     213[char, char] x = [ '!', '?' ];
     214int x = 42;
     215
     216forall(otype T) [T, T] swap( T a, T b ) { return [b, a]; }
     217
     218x = swap( x ); // destructure [char, char] x into two elements of parameter list
     219// ^ can't use int x, not enough arguments to swap
     220\end{lstlisting}
     221Tuple destructuring means that the mapping from the position of a subexpression in the argument list to the position of a paramter in the function declaration is not straightforward, as some arguments may be expandable to different numbers of parameters, like ©x© above.
    209222
    210223\subsection{Reference Types}
    211 % TODO discuss rvalue-to-lvalue conversion here
     224The author, in collaboration with the rest of the \CFA research team, has been designing a \emph{reference type} for \CFA.
     225Given some type ©T©, a ©T&© (``reference to ©T©'') is essentially an automatically dereferenced pointer; with these semantics most of the C standard's discussions of lvalues can be expressed in terms of references instead, with the benefit of being able to express the difference between the reference and non-reference version of a type in user code.
     226References preserve C's existing qualifier-dropping lvalue-to-rvalue conversion (\ie a ©const volatile int&© can be implicitly converted to a bare ©int©); the reference proposal also adds a rvalue-to-lvalue conversion to \CFA, implemented by storing the value in a new compiler-generated temporary and passing a reference to the temporary.
     227These two conversions can chain, producing a qualifier-dropping conversion for references, for instance converting a reference to a ©const int© into a reference to a non-©const int© by copying the originally refered to value into a fresh temporary and taking a reference to this temporary.
     228These reference conversions may also chain with the other implicit type conversions.
     229The main implication of this for expression resolution is the multiplication of available implicit conversions, though in a restricted context that may be able to be treated efficiently as a special case.
    212230
    213231\subsection{Literal Types}
    214 % TODO talk about zero_t, one_t here, implication that some common expressions will have many outbound implicit conversions
    215 
    216 \subsection{Deletable Functions}
     232Another proposal currently under consideration for the \CFA type system is assigning special types to the literal values ©0© and ©1©, say ©zero_t© and ©one_t©.
     233Implicit conversions from these types would allow ©0© and ©1© to be considered as values of many different types, depending on context, allowing expression desugarings like ©if ( x ) {}© $\Rightarrow$ ©if ( x != 0 ) {}© to be implemented efficiently and precicely.
     234This is a generalization of C's existing behaviour of treating ©0© as either an integer zero or a null pointer constant, and treating either of those values as boolean false.
     235The main implication for expression resolution is that the frequently encountered expressions ©0© and ©1© may have a significant number of valid interpretations.
     236
     237\subsection{Deleted Function Declarations}
     238One final proposal for \CFA with an impact on the expression resolver is \emph{deleted function declarations}; in \CC11, a function declaration can be deleted as below:
     239\begin{lstlisting}
     240int somefn(char) = delete;
     241\end{lstlisting}
     242To add a similar feature to \CFA would involve including the deleted function declarations in expression resolution along with the normal declarations, but producing a compiler error if the deleted function was the best resolution.
     243How conflicts should be handled between resolution of an expression to both a deleted and a non-deleted function is a small but open research question.
    217244
    218245\section{Expression Resolution}
    219246% TODO cite Baker, Cormack, etc.
    220 
    221 \subsection{Symbol Table}
    222 % TODO not sure this is sufficiently novel, but it is an improvement to CFA-CC
    223247
    224248\section{Completion Timeline}
Note: See TracChangeset for help on using the changeset viewer.