Changeset 7ba60dd for doc/aaron_comp_II/comp_II.tex
- Timestamp:
- Jul 21, 2016, 12:05:38 PM (9 years ago)
- 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
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/aaron_comp_II/comp_II.tex
r0318c7a r7ba60dd 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. 207 207 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. 210 A variable may name a tuple, and a function may return one. 211 Particularly 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 = [ '!', '?' ]; 214 int x = 42; 215 216 forall(otype T) [T, T] swap( T a, T b ) { return [b, a]; } 217 218 x = 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} 221 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. 209 222 210 223 \subsection{Reference Types} 211 % TODO discuss rvalue-to-lvalue conversion here 224 The author, in collaboration with the rest of the \CFA research team, has been designing a \emph{reference type} for \CFA. 225 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. 226 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. 227 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. 228 These reference conversions may also chain with the other implicit type conversions. 229 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. 212 230 213 231 \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} 232 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©. 233 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. 234 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. 235 The 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} 238 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: 239 \begin{lstlisting} 240 int somefn(char) = delete; 241 \end{lstlisting} 242 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. 243 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. 217 244 218 245 \section{Expression Resolution} 219 246 % 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-CC223 247 224 248 \section{Completion Timeline}
Note: See TracChangeset
for help on using the changeset viewer.