Changeset e2ef6bf for doc/generic_types


Ignore:
Timestamp:
Apr 17, 2017, 6:11:56 PM (8 years ago)
Author:
Peter A. Buhr <pabuhr@…>
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:
7aa78b4
Parents:
0751d4d2
Message:

remove folded examples

File:
1 edited

Legend:

Unmodified
Added
Removed

  • doc/generic_types/generic_types.tex

    r0751d4d2 re2ef6bf  
    278278
    279279Finally, \CFA allows variable overloading:
    280 \lstDeleteShortInline@%
    281 \par\smallskip
    282 \begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}}
     280%\lstDeleteShortInline@%
     281%\par\smallskip
     282%\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}}
    283283\begin{lstlisting}
    284284short int MAX = ...;
    285285int MAX = ...;
    286286double MAX = ...;
    287 \end{lstlisting}
    288 &
    289 \begin{lstlisting}
    290 short int s = MAX;  // select correct MAX
     287short int s = MAX;  $\C{// select correct MAX}$
    291288int i = MAX;
    292289double d = MAX;
    293290\end{lstlisting}
    294 \end{tabular}
    295 \smallskip\par\noindent
    296 \lstMakeShortInline@%
     291%\end{lstlisting}
     292%&
     293%\begin{lstlisting}
     294%\end{tabular}
     295%\smallskip\par\noindent
     296%\lstMakeShortInline@%
    297297Here, the single name @MAX@ replaces all the C type-specific names: @SHRT_MAX@, @INT_MAX@, @DBL_MAX@.
    298298As well, restricted constant overloading is allowed for the values @0@ and @1@, which have special status in C, \eg the value @0@ is both an integer and a pointer literal, so its meaning depends on context.
    … …  
    585585Tuple flattening recursively expands a tuple into the list of its basic components.
    586586Tuple structuring packages a list of expressions into a value of tuple type, \eg:
    587 \lstDeleteShortInline@%
    588 \par\smallskip
    589 \begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}}
     587%\lstDeleteShortInline@%
     588%\par\smallskip
     589%\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}}
    590590\begin{lstlisting}
    591591int f( int, int );
    … …  
    593593int h( int, [int, int] );
    594594[int, int] x;
    595 \end{lstlisting}
    596 &
    597 \begin{lstlisting}
    598595int y;
    599 f( x );                 $\C[1in]{// flatten}$
     596f( x );                 $\C{// flatten}$
    600597g( y, 10 );             $\C{// structure}$
    601 h( x, y );              $\C{// flatten and structure}\CRT{}$
    602 \end{lstlisting}
    603 \end{tabular}
    604 \smallskip\par\noindent
    605 \lstMakeShortInline@%
     598h( x, y );              $\C{// flatten and structure}$
     599\end{lstlisting}
     600%\end{lstlisting}
     601%&
     602%\begin{lstlisting}
     603%\end{tabular}
     604%\smallskip\par\noindent
     605%\lstMakeShortInline@%
    606606In the call to @f@, @x@ is implicitly flattened so the components of @x@ are passed as the two arguments.
    607607In the call to @g@, the values @y@ and @10@ are structured into a single argument of type @[int, int]@ to match the parameter type of @g@.
    … …  
    614614An assignment where the left side is a tuple type is called \emph{tuple assignment}.
    615615There are two kinds of tuple assignment depending on whether the right side of the assignment operator has a tuple type or a non-tuple type, called \emph{multiple} and \emph{mass assignment}, respectively.
    616 \lstDeleteShortInline@%
    617 \par\smallskip
    618 \begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}}
     616%\lstDeleteShortInline@%
     617%\par\smallskip
     618%\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}}
    619619\begin{lstlisting}
    620620int x = 10;
    621621double y = 3.5;
    622622[int, double] z;
    623 
    624 \end{lstlisting}
    625 &
    626 \begin{lstlisting}
    627 z = [x, y];             $\C[1in]{// multiple assignment}$
     623z = [x, y];             $\C{// multiple assignment}$
    628624[x, y] = z;             $\C{// multiple assignment}$
    629625z = 10;                 $\C{// mass assignment}$
    630 [y, x] = 3.14;  $\C{// mass assignment}\CRT{}$
    631 \end{lstlisting}
    632 \end{tabular}
    633 \smallskip\par\noindent
    634 \lstMakeShortInline@%
     626[y, x] = 3.14;  $\C{// mass assignment}$
     627\end{lstlisting}
     628%\end{lstlisting}
     629%&
     630%\begin{lstlisting}
     631%\end{tabular}
     632%\smallskip\par\noindent
     633%\lstMakeShortInline@%
    635634Both kinds of tuple assignment have parallel semantics, so that each value on the left and right side is evaluated before any assignments occur.
    636635As a result, it is possible to swap the values in two variables without explicitly creating any temporary variables or calling a function, \eg, @[x, y] = [y, x]@.
    … …  
    656655Here, the mass assignment sets all members of @s@ to zero.
    657656Since tuple-index expressions are a form of member-access expression, it is possible to use tuple-index expressions in conjunction with member tuple expressions to manually restructure a tuple (\eg rearrange, drop, and duplicate components).
    658 \lstDeleteShortInline@%
    659 \par\smallskip
    660 \begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}}
     657%\lstDeleteShortInline@%
     658%\par\smallskip
     659%\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}}
    661660\begin{lstlisting}
    662661[int, int, long, double] x;
    663662void f( double, long );
    664 
    665 \end{lstlisting}
    666 &
    667 \begin{lstlisting}
    668 x.[0, 1] = x.[1, 0];    $\C[1in]{// rearrange: [x.0, x.1] = [x.1, x.0]}$
    669 f( x.[0, 3] );            $\C{// drop: f(x.0, x.3)}\CRT{}$
    670 [int, int, int] y = x.[2, 0, 2]; // duplicate: [y.0, y.1, y.2] = [x.2, x.0.x.2]
    671 \end{lstlisting}
    672 \end{tabular}
    673 \smallskip\par\noindent
    674 \lstMakeShortInline@%
     663x.[0, 1] = x.[1, 0];    $\C{// rearrange: [x.0, x.1] = [x.1, x.0]}$
     664f( x.[0, 3] );            $\C{// drop: f(x.0, x.3)}$
     665[int, int, int] y = x.[2, 0, 2]; $\C{// duplicate: [y.0, y.1, y.2] = [x.2, x.0.x.2]}$
     666\end{lstlisting}
     667%\end{lstlisting}
     668%&
     669%\begin{lstlisting}
     670%\end{tabular}
     671%\smallskip\par\noindent
     672%\lstMakeShortInline@%
    675673It is also possible for a member access to contain other member accesses, \eg:
    676674\begin{lstlisting}
    … …  
    861859is transformed into:
    862860\begin{lstlisting}
    863 // generated before the first 2-tuple
    864861forall(dtype T0, dtype T1 | sized(T0) | sized(T1)) struct _tuple2 {
    865         T0 field_0;
     862        T0 field_0;                     $\C{// generated before the first 2-tuple}$
    866863        T1 field_1;
    867864};
    868865_tuple2(int, int) f() {
    869866        _tuple2(double, double) x;
    870         // generated before the first 3-tuple
    871867        forall(dtype T0, dtype T1, dtype T2 | sized(T0) | sized(T1) | sized(T2)) struct _tuple3 {
    872                 T0 field_0;
     868                T0 field_0;             $\C{// generated before the first 3-tuple}$
    873869                T1 field_1;
    874870                T2 field_2;
    … …  
    877873}
    878874\end{lstlisting}
    879 Tuple expressions are then simply converted directly into compound literals:
    880 \begin{lstlisting}
    881 [5, 'x', 1.24];
    882 \end{lstlisting}
    883 becomes:
    884 \begin{lstlisting}
    885 (_tuple3(int, char, double)){ 5, 'x', 1.24 };
    886 \end{lstlisting}
     875Tuple expressions are then simply converted directly into compound literals, \eg @[5, 'x', 1.24]@ becomes @(_tuple3(int, char, double)){ 5, 'x', 1.24 }@.
    887876
    888877\begin{comment}
    … …  
    955944The experiment uses element types @int@ and @pair(_Bool, char)@, and pushes $N=40M$ elements on a generic stack, copies the stack, clears one of the stacks, finds the maximum value in the other stack, and prints $N/2$ (to reduce graph height) constants.
    956945
    957 The structure of each benchmark implemented is: C with @void *@-based polymorphism, \CFA with the presented features, \CC with templates, and \CC using only class inheritance for polymorphism, called \CCV.
    958 The \CCV variant illustrates an alternative object-oriented idiom where all objects inherit from a base @object@ class, mimicking a Java-like interface;
    959 hence runtime checks are necessary to safely down-cast objects.
    960 The most notable difference among the implementations is in memory layout of generic types: \CFA and \CC inline the stack and pair elements into corresponding list and pair nodes, while C and \CCV lack such a capability and instead must store generic objects via pointers to separately-allocated objects.
    961 For the print benchmark, idiomatic printing is used: the C and \CFA variants used @stdio.h@, while the \CC and \CCV variants used @iostream@; preliminary tests show this distinction has little runtime impact.
    962 Note, the C benchmark uses unchecked casts as there is no runtime mechanism to perform such checks, while \CFA and \CC provide type-safety statically.
    963 
    964946\begin{figure}
    965947\begin{lstlisting}[xleftmargin=3\parindentlnth,aboveskip=0pt,belowskip=0pt]
    … …  
    991973\label{fig:BenchmarkTest}
    992974\end{figure}
     975
     976The structure of each benchmark implemented is: C with @void *@-based polymorphism, \CFA with the presented features, \CC with templates, and \CC using only class inheritance for polymorphism, called \CCV.
     977The \CCV variant illustrates an alternative object-oriented idiom where all objects inherit from a base @object@ class, mimicking a Java-like interface;
     978hence runtime checks are necessary to safely down-cast objects.
     979The most notable difference among the implementations is in memory layout of generic types: \CFA and \CC inline the stack and pair elements into corresponding list and pair nodes, while C and \CCV lack such a capability and instead must store generic objects via pointers to separately-allocated objects.
     980For the print benchmark, idiomatic printing is used: the C and \CFA variants used @stdio.h@, while the \CC and \CCV variants used @iostream@; preliminary tests show this distinction has little runtime impact.
     981Note, the C benchmark uses unchecked casts as there is no runtime mechanism to perform such checks, while \CFA and \CC provide type-safety statically.
    993982
    994983Figure~\ref{fig:eval} and Table~\ref{tab:eval} show the results of running the benchmark in Figure~\ref{fig:BenchmarkTest} and its C, \CC, and \CCV equivalents.
Note: See TracChangeset for help on using the changeset viewer.