Changeset f92aa32 for doc/rob_thesis/variadic.tex

Timestamp:

Apr 7, 2017, 6:25:23 PM (7 years ago)

Author:

Rob Schluntz <rschlunt@…>

Branches:

ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc

Children:

2ccb93c

Parents:

c51b5a3

Message:

thesis conclusions and editting pass

File:

• doc/rob_thesis/variadic.tex (modified) (4 diffs)

doc/rob_thesis/variadic.tex

@@ -3 +3 @@
 %======================================================================
 
-\section{Design Criteria} % TOOD: better section name???
+\section{Design Criteria} % TODO: better section name???
 C provides variadic functions through the manipulation of @va_list@ objects.
 A variadic function is one which contains at least one parameter, followed by @...@ as the last token in the parameter list.
 In particular, some form of \emph{argument descriptor} is needed to inform the function of the number of arguments and their types.
 Two common argument descriptors are format strings or counter parameters.
-It is important to note that both of these mechanisms are inherently redundant, because they require the user to specify information that the compiler knows explicitly.
+It is important to note that both of these mechanisms are inherently redundant, because they require the user to explicitly specify information that the compiler already knows.
 This required repetition is error prone, because it is easy for the user to add or remove arguments without updating the argument descriptor.
 In addition, C requires the programmer to hard code all of the possible expected types.
@@ -63 +63 @@
 Likewise, when inferring assertion @g@, an exact match is found.
 
-This approach is strict with respect to argument structure by nature, which makes it syntactically awkward to use in ways that the existing tuple design is not.
-For example, consider a @new@ function that allocates memory using @malloc@ and constructs the result, using arbitrary arguments.
+This approach is strict with respect to argument structure, by nature, which makes it syntactically awkward to use in ways that the existing tuple design is not.
+For example, consider a @new@ function that allocates memory using @malloc@, and constructs the result using arbitrary arguments.
 \begin{cfacode}
 struct Array;
@@ -110 +110 @@
 In order to call (1), @10@ is matched with @x@, and the argument resolution moves on to the argument pack @rest@, which consumes the remainder of the argument list and @Params@ is bound to @[20, 30]@.
 In order to finish the resolution of @sum@, an assertion parameter that matches @int sum(int, int)@ is required.
-Like in the previous iteration, (0) is not a valid candiate, so (1) is examined with @Params@ bound to @[int]@, requiring the assertion @int sum(int)@.
+Like in the previous iteration, (0) is not a valid candidate, so (1) is examined with @Params@ bound to @[int]@, requiring the assertion @int sum(int)@.
 Next, (0) fails, and to satisfy (1) @Params@ is bound to @[]@, requiring an assertion @int sum()@.
 Finally, (0) matches and (1) fails, which terminates the recursion.
@@ -173 +173 @@
 A notable limitation of this approach is that it heavily relies on recursive assertions.
 The \CFA translator imposes a limitation on the depth of the recursion for assertion satisfaction.
-Currently, the limit is set to 4, which means that the first iteration of the @sum@ function is limited to at most 5 arguments, while the second iteration can support up to 6 arguments.
+Currently, the limit is set to 4, which means that the first version of the @sum@ function is limited to at most 5 arguments, while the second version can support up to 6 arguments.
 The limit is set low due to inefficiencies in the current implementation of the \CFA expression resolver.
 There is ongoing work to improve the performance of the resolver, and with noticeable gains, the limit can be relaxed to allow longer argument lists to @ttype@ functions.
 
 C variadic syntax and @ttype@ polymorphism probably should not be mixed, since it is not clear where to draw the line to decide which arguments belong where.
-Furthermore, it might be desirable to disallow polymorphic functions to use C variadic syntax to encourage a Cforall style.
+Furthermore, it might be desirable to disallow polymorphic functions to use C variadic syntax to encourage a \CFA style.
 Aside from calling C variadic functions, it is not obvious that there is anything that can be done with C variadics that could not also be done with @ttype@ parameters.