Changeset f92aa32 for doc/rob_thesis/variadic.tex
- Timestamp:
- Apr 7, 2017, 6:25:23 PM (8 years ago)
- 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
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/rob_thesis/variadic.tex
rc51b5a3 rf92aa32 3 3 %====================================================================== 4 4 5 \section{Design Criteria} % TO OD: better section name???5 \section{Design Criteria} % TODO: better section name??? 6 6 C provides variadic functions through the manipulation of @va_list@ objects. 7 7 A variadic function is one which contains at least one parameter, followed by @...@ as the last token in the parameter list. 8 8 In particular, some form of \emph{argument descriptor} is needed to inform the function of the number of arguments and their types. 9 9 Two common argument descriptors are format strings or counter parameters. 10 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.10 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. 11 11 This required repetition is error prone, because it is easy for the user to add or remove arguments without updating the argument descriptor. 12 12 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. 64 64 65 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.66 For example, consider a @new@ function that allocates memory using @malloc@ and constructs the result,using arbitrary arguments.65 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. 66 For example, consider a @new@ function that allocates memory using @malloc@, and constructs the result using arbitrary arguments. 67 67 \begin{cfacode} 68 68 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]@. 111 111 In order to finish the resolution of @sum@, an assertion parameter that matches @int sum(int, int)@ is required. 112 Like in the previous iteration, (0) is not a valid candi ate, so (1) is examined with @Params@ bound to @[int]@, requiring the assertion @int sum(int)@.112 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)@. 113 113 Next, (0) fails, and to satisfy (1) @Params@ is bound to @[]@, requiring an assertion @int sum()@. 114 114 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. 174 174 The \CFA translator imposes a limitation on the depth of the recursion for assertion satisfaction. 175 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.175 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. 176 176 The limit is set low due to inefficiencies in the current implementation of the \CFA expression resolver. 177 177 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. 178 178 179 179 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. 180 Furthermore, it might be desirable to disallow polymorphic functions to use C variadic syntax to encourage a Cforallstyle.180 Furthermore, it might be desirable to disallow polymorphic functions to use C variadic syntax to encourage a \CFA style. 181 181 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. 182 182
Note: See TracChangeset
for help on using the changeset viewer.