Changeset ef3b335


Ignore:
Timestamp:
Jul 21, 2016, 4:15:36 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:
31e46b8, 4e05d27, b44a7c5
Parents:
481ad06
Message:

Minor edits to comp II draft

Location:
doc
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • doc/LaTeXmacros/common.tex

    r481ad06 ref3b335  
    4141\newcommand{\CFL}{Cforall\xspace}                        % set language text name
    4242\newcommand{\CC}{\rm C\kern-.1em\hbox{+\kern-.25em+}\xspace} % CC symbolic name
     43\newcommand{\CCeleven}{\rm C\kern-.1em\hbox{+\kern-.25em+}11\xspace} % C++11 symbolic name
    4344\def\c11{ISO/IEC C} % C11 name (cannot have numbers in latex command name)
    4445
  • doc/aaron_comp_II/comp_II.tex

    r481ad06 ref3b335  
    164164C 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.
    165165\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.
     166The 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.
     167Note that which subexpression interpretation is minimal-cost may require contextual information to disambiguate.
    167168
    168169\subsubsection{User-generated Implicit Conversions}
     
    200201Aside 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:
    201202\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.
    204205\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.
    205206\end{itemize}
     
    207208
    208209\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.
    210211A variable may name a tuple, and a function may return one.
    211212Particularly relevantly for resolution, a tuple may be automatically \emph{destructured} into a list of values, as in the ©swap© function below:
     
    217218
    218219x = swap( x ); // destructure [char, char] x into two elements of parameter list
    219 // ^ can't use int x, not enough arguments to swap
     220// ^ can't use int x for parameter, not enough arguments to swap
    220221\end{lstlisting}
    221222Tuple 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.
    222223
    223224\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.
     225The author, in collaboration with the rest of the \CFA research team, has been designing \emph{reference types} for \CFA.
    225226Given 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.
     227References 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.
    227228These 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.
    228229These reference conversions may also chain with the other implicit type conversions.
     
    230231
    231232\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©.
     233Another 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©.
    233234Implicit 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.
    234235This 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.
     
    236237
    237238\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:
     239One 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:
    239240\begin{lstlisting}
    240241int somefn(char) = delete;
Note: See TracChangeset for help on using the changeset viewer.