Changeset 7ba60dd

Timestamp:

Jul 21, 2016, 12:05:38 PM (8 years ago)

Author:

Aaron Moss <a3moss@…>

Branches:

ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, ctor, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, 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:

• doc/aaron_comp_II/comp_II.tex (modified) (1 diff)

doc/aaron_comp_II/comp_II.tex

@@ -206 +206 @@
 As 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.
 
-\subsection{Multiple Return Values}
+\subsection{Tuple Types}
+\CFA adds \emph{tuple types} to C, a facility for referring to multiple values with one name. 
+A variable may name a tuple, and a function may return one. 
+Particularly relevantly for resolution, a tuple may be automatically \emph{destructured} into a list of values, as in the ©swap© function below:
+\begin{lstlisting}
+[char, char] x = [ '!', '?' ];
+int x = 42;
+
+forall(otype T) [T, T] swap( T a, T b ) { return [b, a]; }
+
+x = swap( x ); // destructure [char, char] x into two elements of parameter list
+// ^ can't use int x, not enough arguments to swap
+\end{lstlisting}
+Tuple 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.
 
 \subsection{Reference Types}
-% TODO discuss rvalue-to-lvalue conversion here
+The author, in collaboration with the rest of the \CFA research team, has been designing a \emph{reference type} for \CFA. 
+Given 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. 
+References 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. 
+These 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. 
+These reference conversions may also chain with the other implicit type conversions. 
+The 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.
 
 \subsection{Literal Types}
-% TODO talk about zero_t, one_t here, implication that some common expressions will have many outbound implicit conversions
-
-\subsection{Deletable Functions}
+Another 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©. 
+Implicit 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. 
+This 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. 
+The main implication for expression resolution is that the frequently encountered expressions ©0© and ©1© may have a significant number of valid interpretations.
+
+\subsection{Deleted Function Declarations}
+One 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:
+\begin{lstlisting}
+int somefn(char) = delete;
+\end{lstlisting}
+To 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. 
+How 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.
 
 \section{Expression Resolution}
 % TODO cite Baker, Cormack, etc.
-
-\subsection{Symbol Table}
-% TODO not sure this is sufficiently novel, but it is an improvement to CFA-CC
 
 \section{Completion Timeline}