Changeset ef3b335 for doc/aaron_comp_II
- Timestamp:
- Jul 21, 2016, 4:15:36 PM (8 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:
- 31e46b8, 4e05d27, b44a7c5
- Parents:
- 481ad06
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/aaron_comp_II/comp_II.tex
r481ad06 ref3b335 164 164 C does not have a traditionally-defined inheritance hierarchy of types, but the C standard's rules for the ``usual arithmetic conversions'' define which of the built-in types are implicitly convertable to which other types, and the relative cost of any pair of such conversions from a single source type. 165 165 \CFA adds to the usual arithmetic conversions rules for determining the cost of binding a polymorphic type variable in a function call; such bindings are cheaper than any \emph{unsafe} (narrowing) conversion, \eg ©int© to ©char©, but more expensive than any \emph{safe} (widening) conversion, \eg ©int© to ©double©. 166 The expression resolution problem, then, is to find the unique minimal-cost interpretation of each expression in the program, where all identifiers must be matched to a declaration, implicit conversions or polymorphic bindings of the result of an expression may increase the cost of the expression, and which subexpression interpretation is minimal-cost may be disambiguated by context. 166 The expression resolution problem, then, is to find the unique minimal-cost interpretation of each expression in the program, where all identifiers must be matched to a declaration and implicit conversions or polymorphic bindings of the result of an expression may increase the cost of the expression. 167 Note that which subexpression interpretation is minimal-cost may require contextual information to disambiguate. 167 168 168 169 \subsubsection{User-generated Implicit Conversions} … … 200 201 Aside from giving users the ability to create more parameterized types than just the built-in pointer, array \& function types, the combination of generic types with polymorphic functions and implicit conversions makes the edge case where a polymorphic function can match its own assertions much more common, as follows: 201 202 \begin{itemize} 202 \item A polymorphic implicit conversion (such as the built-in conversion from ©void*© to any other pointer type) applied to an expression can produce an expression of any type.203 \item If we attempt to use a generic type with ©otype© parameters (such as ©box© above) for this type, the ©otype© parameters on the constructors, \etc will also need to be resolved, and will have no constraints on what they may be.203 \item Given an expression in an untyped context, such as a top-level function call with no assignment of return values, apply a polymorphic implicit conversion to the expression that can produce multiple types (the built-in conversion from ©void*© to any other pointer type is one, but not the only). 204 \item When attempting to use a generic type with ©otype© parameters (such as ©box© above) for the result type of the expression, the resolver will also need to decide what type to use for the ©otype© parameters on the constructors and related functions, and will have no constraints on what they may be. 204 205 \item Attempting to match some yet-to-be-determined specialization of the generic type to this ©otype© parameter will create a recursive case of the default constructor, \etc matching their own type assertions, creating an unboundedly deep nesting of the generic type inside itself. 205 206 \end{itemize} … … 207 208 208 209 \subsection{Tuple Types} 209 \CFA adds \emph{tuple types} to C, a facility for referring to multiple values with one name.210 \CFA adds \emph{tuple types} to C, a facility for referring to multiple values with a single identifier. 210 211 A variable may name a tuple, and a function may return one. 211 212 Particularly relevantly for resolution, a tuple may be automatically \emph{destructured} into a list of values, as in the ©swap© function below: … … 217 218 218 219 x = swap( x ); // destructure [char, char] x into two elements of parameter list 219 // ^ can't use int x , not enough arguments to swap220 // ^ can't use int x for parameter, not enough arguments to swap 220 221 \end{lstlisting} 221 222 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. 222 223 223 224 \subsection{Reference Types} 224 The author, in collaboration with the rest of the \CFA research team, has been designing a \emph{reference type} for \CFA.225 The author, in collaboration with the rest of the \CFA research team, has been designing \emph{reference types} for \CFA. 225 226 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 (\ iea ©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 References preserve C's existing qualifier-dropping lvalue-to-rvalue conversion (\eg 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 228 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 229 These reference conversions may also chain with the other implicit type conversions. … … 230 231 231 232 \subsection{Literal Types} 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 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 234 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 235 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. … … 236 237 237 238 \subsection{Deleted Function Declarations} 238 One final proposal for \CFA with an impact on the expression resolver is \emph{deleted function declarations}; in \CC 11, a function declaration can be deleted as below:239 One final proposal for \CFA with an impact on the expression resolver is \emph{deleted function declarations}; in \CCeleven, a function declaration can be deleted as below: 239 240 \begin{lstlisting} 240 241 int somefn(char) = delete;
Note: See TracChangeset
for help on using the changeset viewer.