Index: doc/generic_types/generic_types.tex =================================================================== --- doc/generic_types/generic_types.tex (revision 0751d4d25dc15cf3da8caa8e7469061c2478b283) +++ doc/generic_types/generic_types.tex (revision e2ef6bf06cedeef7b851efde81da89a65a5c8011) @@ -278,21 +278,21 @@ Finally, \CFA allows variable overloading: -\lstDeleteShortInline@% -\par\smallskip -\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}} +%\lstDeleteShortInline@% +%\par\smallskip +%\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}} \begin{lstlisting} short int MAX = ...; int MAX = ...; double MAX = ...; -\end{lstlisting} -& -\begin{lstlisting} -short int s = MAX; // select correct MAX +short int s = MAX; $\C{// select correct MAX}$ int i = MAX; double d = MAX; \end{lstlisting} -\end{tabular} -\smallskip\par\noindent -\lstMakeShortInline@% +%\end{lstlisting} +%& +%\begin{lstlisting} +%\end{tabular} +%\smallskip\par\noindent +%\lstMakeShortInline@% Here, the single name @MAX@ replaces all the C type-specific names: @SHRT_MAX@, @INT_MAX@, @DBL_MAX@. As 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. @@ -585,7 +585,7 @@ Tuple flattening recursively expands a tuple into the list of its basic components. Tuple structuring packages a list of expressions into a value of tuple type, \eg: -\lstDeleteShortInline@% -\par\smallskip -\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}} +%\lstDeleteShortInline@% +%\par\smallskip +%\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}} \begin{lstlisting} int f( int, int ); @@ -593,15 +593,15 @@ int h( int, [int, int] ); [int, int] x; -\end{lstlisting} -& -\begin{lstlisting} int y; -f( x ); $\C[1in]{// flatten}$ +f( x ); $\C{// flatten}$ g( y, 10 ); $\C{// structure}$ -h( x, y ); $\C{// flatten and structure}\CRT{}$ -\end{lstlisting} -\end{tabular} -\smallskip\par\noindent -\lstMakeShortInline@% +h( x, y ); $\C{// flatten and structure}$ +\end{lstlisting} +%\end{lstlisting} +%& +%\begin{lstlisting} +%\end{tabular} +%\smallskip\par\noindent +%\lstMakeShortInline@% In the call to @f@, @x@ is implicitly flattened so the components of @x@ are passed as the two arguments. In 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@. @@ -614,23 +614,22 @@ An assignment where the left side is a tuple type is called \emph{tuple assignment}. There 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. -\lstDeleteShortInline@% -\par\smallskip -\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}} +%\lstDeleteShortInline@% +%\par\smallskip +%\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}} \begin{lstlisting} int x = 10; double y = 3.5; [int, double] z; - -\end{lstlisting} -& -\begin{lstlisting} -z = [x, y]; $\C[1in]{// multiple assignment}$ +z = [x, y]; $\C{// multiple assignment}$ [x, y] = z; $\C{// multiple assignment}$ z = 10; $\C{// mass assignment}$ -[y, x] = 3.14; $\C{// mass assignment}\CRT{}$ -\end{lstlisting} -\end{tabular} -\smallskip\par\noindent -\lstMakeShortInline@% +[y, x] = 3.14; $\C{// mass assignment}$ +\end{lstlisting} +%\end{lstlisting} +%& +%\begin{lstlisting} +%\end{tabular} +%\smallskip\par\noindent +%\lstMakeShortInline@% Both kinds of tuple assignment have parallel semantics, so that each value on the left and right side is evaluated before any assignments occur. As 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]@. @@ -656,21 +655,20 @@ Here, the mass assignment sets all members of @s@ to zero. Since 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). -\lstDeleteShortInline@% -\par\smallskip -\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}} +%\lstDeleteShortInline@% +%\par\smallskip +%\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}} \begin{lstlisting} [int, int, long, double] x; void f( double, long ); - -\end{lstlisting} -& -\begin{lstlisting} -x.[0, 1] = x.[1, 0]; $\C[1in]{// rearrange: [x.0, x.1] = [x.1, x.0]}$ -f( x.[0, 3] ); $\C{// drop: f(x.0, x.3)}\CRT{}$ -[int, int, int] y = x.[2, 0, 2]; // duplicate: [y.0, y.1, y.2] = [x.2, x.0.x.2] -\end{lstlisting} -\end{tabular} -\smallskip\par\noindent -\lstMakeShortInline@% +x.[0, 1] = x.[1, 0]; $\C{// rearrange: [x.0, x.1] = [x.1, x.0]}$ +f( x.[0, 3] ); $\C{// drop: f(x.0, x.3)}$ +[int, int, int] y = x.[2, 0, 2]; $\C{// duplicate: [y.0, y.1, y.2] = [x.2, x.0.x.2]}$ +\end{lstlisting} +%\end{lstlisting} +%& +%\begin{lstlisting} +%\end{tabular} +%\smallskip\par\noindent +%\lstMakeShortInline@% It is also possible for a member access to contain other member accesses, \eg: \begin{lstlisting} @@ -861,14 +859,12 @@ is transformed into: \begin{lstlisting} -// generated before the first 2-tuple forall(dtype T0, dtype T1 | sized(T0) | sized(T1)) struct _tuple2 { - T0 field_0; + T0 field_0; $\C{// generated before the first 2-tuple}$ T1 field_1; }; _tuple2(int, int) f() { _tuple2(double, double) x; - // generated before the first 3-tuple forall(dtype T0, dtype T1, dtype T2 | sized(T0) | sized(T1) | sized(T2)) struct _tuple3 { - T0 field_0; + T0 field_0; $\C{// generated before the first 3-tuple}$ T1 field_1; T2 field_2; @@ -877,12 +873,5 @@ } \end{lstlisting} -Tuple expressions are then simply converted directly into compound literals: -\begin{lstlisting} -[5, 'x', 1.24]; -\end{lstlisting} -becomes: -\begin{lstlisting} -(_tuple3(int, char, double)){ 5, 'x', 1.24 }; -\end{lstlisting} +Tuple expressions are then simply converted directly into compound literals, \eg @[5, 'x', 1.24]@ becomes @(_tuple3(int, char, double)){ 5, 'x', 1.24 }@. \begin{comment} @@ -955,11 +944,4 @@ The 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. -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. -The \CCV variant illustrates an alternative object-oriented idiom where all objects inherit from a base @object@ class, mimicking a Java-like interface; -hence runtime checks are necessary to safely down-cast objects. -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. -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. -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. - \begin{figure} \begin{lstlisting}[xleftmargin=3\parindentlnth,aboveskip=0pt,belowskip=0pt] @@ -991,4 +973,11 @@ \label{fig:BenchmarkTest} \end{figure} + +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. +The \CCV variant illustrates an alternative object-oriented idiom where all objects inherit from a base @object@ class, mimicking a Java-like interface; +hence runtime checks are necessary to safely down-cast objects. +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. +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. +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. Figure~\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.