Ignore:
Timestamp:
Apr 7, 2017, 6:25:23 PM (5 years ago)
Author:
Rob Schluntz <rschlunt@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc
Children:
2ccb93c
Parents:
c51b5a3
Message:

thesis conclusions and editting pass

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/rob_thesis/variadic.tex

    rc51b5a3 rf92aa32  
    33%======================================================================
    44
    5 \section{Design Criteria} % TOOD: better section name???
     5\section{Design Criteria} % TODO: better section name???
    66C provides variadic functions through the manipulation of @va_list@ objects.
    77A variadic function is one which contains at least one parameter, followed by @...@ as the last token in the parameter list.
    88In particular, some form of \emph{argument descriptor} is needed to inform the function of the number of arguments and their types.
    99Two 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.
     10It 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.
    1111This required repetition is error prone, because it is easy for the user to add or remove arguments without updating the argument descriptor.
    1212In addition, C requires the programmer to hard code all of the possible expected types.
     
    6363Likewise, when inferring assertion @g@, an exact match is found.
    6464
    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.
     65This 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.
     66For example, consider a @new@ function that allocates memory using @malloc@, and constructs the result using arbitrary arguments.
    6767\begin{cfacode}
    6868struct Array;
     
    110110In 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]@.
    111111In 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 candiate, so (1) is examined with @Params@ bound to @[int]@, requiring the assertion @int sum(int)@.
     112Like 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)@.
    113113Next, (0) fails, and to satisfy (1) @Params@ is bound to @[]@, requiring an assertion @int sum()@.
    114114Finally, (0) matches and (1) fails, which terminates the recursion.
     
    173173A notable limitation of this approach is that it heavily relies on recursive assertions.
    174174The \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.
     175Currently, 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.
    176176The limit is set low due to inefficiencies in the current implementation of the \CFA expression resolver.
    177177There 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.
    178178
    179179C 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 Cforall style.
     180Furthermore, it might be desirable to disallow polymorphic functions to use C variadic syntax to encourage a \CFA style.
    181181Aside 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.
    182182
Note: See TracChangeset for help on using the changeset viewer.