Changeset ef3b335

Timestamp:

Jul 21, 2016, 4:15:36 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:

31e46b8, 4e05d27, b44a7c5

Parents:

481ad06

Message:

Minor edits to comp II draft

Location:

doc

Files:

• LaTeXmacros/common.tex (modified) (1 diff)
• aaron_comp_II/comp_II.tex (modified) (6 diffs)

doc/LaTeXmacros/common.tex

@@ -41 +41 @@
 \newcommand{\CFL}{Cforall\xspace}                        % set language text name
 \newcommand{\CC}{\rm C\kern-.1em\hbox{+\kern-.25em+}\xspace} % CC symbolic name
+\newcommand{\CCeleven}{\rm C\kern-.1em\hbox{+\kern-.25em+}11\xspace} % C++11 symbolic name
 \def\c11{ISO/IEC C} % C11 name (cannot have numbers in latex command name)
 

doc/aaron_comp_II/comp_II.tex

@@ -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. 
 \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©. 
-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.
+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. 
+Note that which subexpression interpretation is minimal-cost may require contextual information to disambiguate.
 
 \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:
 \begin{itemize} 
-\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.
-\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.
+\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).
+\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.
 \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.
 \end{itemize}
@@ -207 +208 @@
 
 \subsection{Tuple Types}
-\CFA adds \emph{tuple types} to C, a facility for referring to multiple values with one name. 
+\CFA adds \emph{tuple types} to C, a facility for referring to multiple values with a single identifier. 
 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:
@@ -217 +218 @@
 
 x = swap( x ); // destructure [char, char] x into two elements of parameter list
-// ^ can't use int x, not enough arguments to swap
+// ^ can't use int x for parameter, 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}
-The author, in collaboration with the rest of the \CFA research team, has been designing a \emph{reference type} for \CFA. 
+The author, in collaboration with the rest of the \CFA research team, has been designing \emph{reference types} 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. 
+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. 
 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. 
@@ -230 +231 @@
 
 \subsection{Literal Types}
-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©. 
+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. 
@@ -236 +237 @@
 
 \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:
+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:
 \begin{lstlisting}
 int somefn(char) = delete;