Changeset 579263a for doc/user/user.tex


Ignore:
Timestamp:
Jun 26, 2017, 4:48:35 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:
bb1cd95
Parents:
e4d829b (diff), 2a7b3ca (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge branch 'master' into designations

Conflicts:

src/InitTweak/FixInit.cc
src/SymTab/Autogen.h
src/SynTree/Initializer.cc
src/SynTree/Initializer.h
src/Tuples/TupleExpansion.cc

File:
1 edited

Legend:

Unmodified
Added
Removed

  • doc/user/user.tex

    re4d829b r579263a  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Fri Jun  2 10:07:51 2017
    14 %% Update Count     : 2128
     13%% Last Modified On : Fri Jun 16 12:00:01 2017
     14%% Update Count     : 2433
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
    … …  
    4343\usepackage[pagewise]{lineno}
    4444\renewcommand{\linenumberfont}{\scriptsize\sffamily}
    45 \input{common}                                          % bespoke macros used in the document
     45\input{common}                                          % common CFA document macros
    4646\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
    4747\usepackage{breakurl}
    … …  
    110110\renewcommand{\subsectionmark}[1]{\markboth{\thesubsection\quad #1}{\thesubsection\quad #1}}
    111111\pagenumbering{roman}
    112 \linenumbers                                            % comment out to turn off line numbering
     112%\linenumbers                                            % comment out to turn off line numbering
    113113
    114114\maketitle
    … …  
    454454the type suffixes ©U©, ©L©, etc. may start with an underscore ©1_U©, ©1_ll© or ©1.0E10_f©.
    455455\end{enumerate}
    456 It is significantly easier to read and enter long constants when they are broken up into smaller groupings (most cultures use comma or period among digits for the same purpose).
     456It is significantly easier to read and enter long constants when they are broken up into smaller groupings (many cultures use comma and/or period among digits for the same purpose).
    457457This extension is backwards compatible, matches with the use of underscore in variable names, and appears in \Index*{Ada} and \Index*{Java} 8.
    458458
    … …  
    464464\begin{cfa}
    465465int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
    466 double ®`®choose®`® = 3.5;
    467 \end{cfa}
    468 Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to a non-keyword name.
     466double ®`®forall®`® = 3.5;
     467\end{cfa}
     468Existing C programs with keyword clashes can be converted by enclosing keyword identifiers in backquotes, and eventually the identifier name can be changed to a non-keyword name.
    469469\VRef[Figure]{f:InterpositionHeaderFile} shows how clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©:
    470470
    … …  
    473473// include file uses the CFA keyword "otype".
    474474#if ! defined( otype )                  §\C{// nesting ?}§
    475 #define otype `otype`
     475#define otype ®`®otype®`®               §\C{// make keyword an identifier}§
    476476#define __CFA_BFD_H__
    477477#endif // ! otype
    … …  
    497497\begin{tabular}{@{}ll@{}}
    498498\begin{cfa}
    499 int *x[5]
     499int * x[5]
    500500\end{cfa}
    501501&
    … …  
    508508For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
    509509\begin{cfa}
    510 int (*f())[5] {...};                    §\C{}§
    511 ... (*f())[3] += 1;
     510int ®(*®f®())[®5®]® {...};                              §\C{definition}§
     511 ... ®(*®f®())[®3®]® += 1;                              §\C{usage}§
    512512\end{cfa}
    513513Essentially, the return type is wrapped around the routine name in successive layers (like an \Index{onion}).
    … …  
    516516\CFA provides its own type, variable and routine declarations, using a different syntax.
    517517The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type.
    518 In the following example, \R{red} is for the base type and \B{blue} is for the qualifiers.
     518In the following example, \R{red} is the base type and \B{blue} is qualifiers.
    519519The \CFA declarations move the qualifiers to the left of the base type, \ie move the blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type.
    520520\begin{quote2}
    … …  
    534534\end{tabular}
    535535\end{quote2}
    536 The only exception is bit field specification, which always appear to the right of the base type.
     536The only exception is \Index{bit field} specification, which always appear to the right of the base type.
    537537% Specifically, the character ©*© is used to indicate a pointer, square brackets ©[©\,©]© are used to represent an array or function return value, and parentheses ©()© are used to indicate a routine parameter.
    538538However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list.
    … …  
    583583\begin{cfa}
    584584int z[ 5 ];
    585 char *w[ 5 ];
    586 double (*v)[ 5 ];
     585char * w[ 5 ];
     586double (* v)[ 5 ];
    587587struct s {
    588588        int f0:3;
    589         int *f1;
    590         int *f2[ 5 ]
     589        int * f1;
     590        int * f2[ 5 ]
    591591};
    592592\end{cfa}
    … …  
    637637\begin{cfa}
    638638int extern x[ 5 ];
    639 const int static *y;
     639const int static * y;
    640640\end{cfa}
    641641&
    … …  
    658658\begin{cfa}
    659659y = (®int *®)x;
    660 i = sizeof(®int *[ 5 ]®);
     660i = sizeof(®int * [ 5 ]®);
    661661\end{cfa}
    662662\end{tabular}
    … …  
    672672C provides a \newterm{pointer type};
    673673\CFA adds a \newterm{reference type}.
    674 These types may be derived from a object or routine type, called the \newterm{referenced type}.
     674These types may be derived from an object or routine type, called the \newterm{referenced type}.
    675675Objects of these types contain an \newterm{address}, which is normally a location in memory, but may also address memory-mapped registers in hardware devices.
    676676An integer constant expression with the value 0, or such an expression cast to type ©void *©, is called a \newterm{null-pointer constant}.\footnote{
    … …  
    729729
    730730A \Index{pointer}/\Index{reference} object is a generalization of an object variable-name, \ie a mutable address that can point to more than one memory location during its lifetime.
    731 (Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime, and like a variable name, may not occupy storage as the literal is embedded directly into instructions.)
     731(Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime, and like a variable name, may not occupy storage if the literal is embedded directly into instructions.)
    732732Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, \eg:
    733733\begin{quote2}
    … …  
    758758\begin{cfa}
    759759p1 = p2;                                                §\C{// p1 = p2\ \ rather than\ \ *p1 = *p2}§
    760 p2 = p1 + x;                                    §\C{// p2 = p1 + x\ \ rather than\ \ *p1 = *p1 + x}§
     760p2 = p1 + x;                                    §\C{// p2 = p1 + x\ \ rather than\ \ *p2 = *p1 + x}§
    761761\end{cfa}
    762762even though the assignment to ©p2© is likely incorrect, and the programmer probably meant:
    … …  
    765765®*®p2 = ®*®p1 + x;                              §\C{// pointed-to value assignment / operation}§
    766766\end{cfa}
    767 The C semantics works well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
     767The C semantics work well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
    768768
    769769However, in most other situations, the pointed-to value is requested more often than the pointer address.
    … …  
    799799For a \CFA reference type, the cancellation on the left-hand side of assignment leaves the reference as an address (\Index{lvalue}):
    800800\begin{cfa}
    801 (&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving address of r1 not variable pointed-to by r1}§
     801(&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving address in r1 not variable pointed-to by r1}§
    802802\end{cfa}
    803803Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}):
    804804\begin{cfa}
    805 (&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address of r2, (\&(\&*)*) cancel giving address of r3}§
     805(&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address in r2, (\&(\&*)*) cancel giving address in r3}§
    806806\end{cfa}
    807807Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth.
    … …  
    824824As for a pointer type, a reference type may have qualifiers:
    825825\begin{cfa}
    826 const int cx = 5;                               §\C{// cannot change cx;}§
    827 const int & cr = cx;                    §\C{// cannot change what cr points to}§
    828 ®&®cr = &cx;                                    §\C{// can change cr}§
    829 cr = 7;                                                 §\C{// error, cannot change cx}§
    830 int & const rc = x;                             §\C{// must be initialized}§
    831 ®&®rc = &x;                                             §\C{// error, cannot change rc}§
    832 const int & const crc = cx;             §\C{// must be initialized}§
    833 crc = 7;                                                §\C{// error, cannot change cx}§
    834 ®&®crc = &cx;                                   §\C{// error, cannot change crc}§
    835 \end{cfa}
    836 Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be the null pointer unless an arbitrary pointer is coerced into the reference}:
    837 \begin{cfa}
    838 int & const cr = *0;                    §\C{// where 0 is the int * zero}§
    839 \end{cfa}
    840 Note, constant reference-types do not prevent addressing errors because of explicit storage-management:
     826const int cx = 5;                                       §\C{// cannot change cx;}§
     827const int & cr = cx;                            §\C{// cannot change what cr points to}§
     828®&®cr = &cx;                                            §\C{// can change cr}§
     829cr = 7;                                                         §\C{// error, cannot change cx}§
     830int & const rc = x;                                     §\C{// must be initialized}§
     831®&®rc = &x;                                                     §\C{// error, cannot change rc}§
     832const int & const crc = cx;                     §\C{// must be initialized}§
     833crc = 7;                                                        §\C{// error, cannot change cx}§
     834®&®crc = &cx;                                           §\C{// error, cannot change crc}§
     835\end{cfa}
     836Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be the null pointer unless an arbitrary pointer is coerced\index{coercion} into the reference}:
     837\begin{cfa}
     838int & const cr = *0;                            §\C{// where 0 is the int * zero}§
     839\end{cfa}
     840Note, constant reference-types do not prevent \Index{addressing errors} because of explicit storage-management:
    841841\begin{cfa}
    842842int & const cr = *malloc();
    843843cr = 5;
    844 delete &cr;
    845 cr = 7;                                                 §\C{// unsound pointer dereference}§
    846 \end{cfa}
    847 
    848 Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
     844free( &cr );
     845cr = 7;                                                         §\C{// unsound pointer dereference}§
     846\end{cfa}
     847
     848The position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
    849849The ©const© qualifier cannot be moved before the pointer/reference qualifier for C style-declarations;
    850 \CFA-style declarations attempt to address this issue:
     850\CFA-style declarations (see \VRef{s:Declarations}) attempt to address this issue:
    851851\begin{quote2}
    852852\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    … …  
    863863\end{tabular}
    864864\end{quote2}
    865 where the \CFA declaration is read left-to-right (see \VRef{s:Declarations}).
     865where the \CFA declaration is read left-to-right.
     866
     867Finally, like pointers, references are usable and composable with other type operators and generators.
     868\begin{cfa}
     869int w, x, y, z, & ar[3] = { x, y, z }; §\C{// initialize array of references}§
     870&ar[1] = &w;                                            §\C{// change reference array element}§
     871typeof( ar[1] ) p;                                      §\C{// (gcc) is int, i.e., the type of referenced object}§
     872typeof( &ar[1] ) q;                                     §\C{// (gcc) is int \&, i.e., the type of reference}§
     873sizeof( ar[1] ) == sizeof( int );       §\C{// is true, i.e., the size of referenced object}§
     874sizeof( &ar[1] ) == sizeof( int *)      §\C{// is true, i.e., the size of a reference}§
     875\end{cfa}
    866876
    867877In contrast to \CFA reference types, \Index*[C++]{\CC{}}'s reference types are all ©const© references, preventing changes to the reference address, so only value assignment is possible, which eliminates half of the \Index{address duality}.
     878Also, \CC does not allow \Index{array}s\index{array!reference} of reference\footnote{
     879The reason for disallowing arrays of reference is unknown, but possibly comes from references being ethereal (like a textual macro), and hence, replaceable by the referant object.}
    868880\Index*{Java}'s reference types to objects (all Java objects are on the heap) are like C pointers, which always manipulate the address, and there is no (bit-wise) object assignment, so objects are explicitly cloned by shallow or deep copying, which eliminates half of the address duality.
     881
     882
     883\subsection{Initialization}
    869884
    870885\Index{Initialization} is different than \Index{assignment} because initialization occurs on the empty (uninitialized) storage on an object, while assignment occurs on possibly initialized storage of an object.
    … …  
    872887Because the object being initialized has no value, there is only one meaningful semantics with respect to address duality: it must mean address as there is no pointed-to value.
    873888In contrast, the left-hand side of assignment has an address that has a duality.
    874 Therefore, for pointer/reference initialization, the initializing value must be an address (\Index{lvalue}) not a value (\Index{rvalue}).
    875 \begin{cfa}
    876 int * p = &x;                           §\C{// must have address of x}§
    877 int & r = x;                            §\C{// must have address of x}§
    878 \end{cfa}
    879 Therefore, it is superfluous to require explicitly taking the address of the initialization object, even though the type is incorrect.
    880 Hence, \CFA allows ©r© to be assigned ©x© because it infers a reference for ©x©, by implicitly inserting a address-of operator, ©&©, and it is an error to put an ©&© because the types no longer match.
    881 Unfortunately, C allows ©p© to be assigned with ©&x© or ©x©, by value, but most compilers warn about the latter assignment as being potentially incorrect.
    882 (\CFA extends pointer initialization so a variable name is automatically referenced, eliminating the unsafe assignment.)
     889Therefore, for pointer/reference initialization, the initializing value must be an address not a value.
     890\begin{cfa}
     891int * p = &x;                                           §\C{// assign address of x}§
     892®int * p = x;®                                          §\C{// assign value of x}§
     893int & r = x;                                            §\C{// must have address of x}§
     894\end{cfa}
     895Like the previous example with C pointer-arithmetic, it is unlikely assigning the value of ©x© into a pointer is meaningful (again, a warning is usually given).
     896Therefore, for safety, this context requires an address, so it is superfluous to require explicitly taking the address of the initialization object, even though the type is incorrect.
     897Note, this is strictly a convenience and safety feature for a programmer.
     898Hence, \CFA allows ©r© to be assigned ©x© because it infers a reference for ©x©, by implicitly inserting a address-of operator, ©&©, and it is an error to put an ©&© because the types no longer match due to the implicit dereference.
     899Unfortunately, C allows ©p© to be assigned with ©&x© (address) or ©x© (value), but most compilers warn about the latter assignment as being potentially incorrect.
    883900Similarly, when a reference type is used for a parameter/return type, the call-site argument does not require a reference operator for the same reason.
    884901\begin{cfa}
    885 int & f( int & r );                             §\C{// reference parameter and return}§
    886 z = f( x ) + f( y );                    §\C{// reference operator added, temporaries needed for call results}§
     902int & f( int & r );                                     §\C{// reference parameter and return}§
     903z = f( x ) + f( y );                            §\C{// reference operator added, temporaries needed for call results}§
    887904\end{cfa}
    888905Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©r© can be locally reassigned within ©f©.
    … …  
    892909z = temp1 + temp2;
    893910\end{cfa}
    894 This implicit referencing is crucial for reducing the syntactic burden for programmers when using references;
     911This \Index{implicit referencing} is crucial for reducing the syntactic burden for programmers when using references;
    895912otherwise references have the same syntactic  burden as pointers in these contexts.
    896913
    … …  
    899916void f( ®const® int & cr );
    900917void g( ®const® int * cp );
    901 f( 3 );                   g( &3 );
    902 f( x + y );             g( &(x + y) );
     918f( 3 );                   g( ®&®3 );
     919f( x + y );             g( ®&®(x + y) );
    903920\end{cfa}
    904921Here, the compiler passes the address to the literal 3 or the temporary for the expression ©x + y©, knowing the argument cannot be changed through the parameter.
    905 (The ©&© is necessary for the pointer-type parameter to make the types match, and is a common requirement for a C programmer.)
     922The ©&© before the constant/expression for the pointer-type parameter (©g©) is a \CFA extension necessary to type match and is a common requirement before a variable in C (\eg ©scanf©).
     923Importantly, ©&3© may not be equal to ©&3©, where the references occur across calls because the temporaries maybe different on each call.
     924
    906925\CFA \emph{extends} this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed-to by the reference parameter and can be changed.\footnote{
    907926If whole program analysis is possible, and shows the parameter is not assigned, \ie it is ©const©, the temporary is unnecessary.}
    … …  
    909928void f( int & r );
    910929void g( int * p );
    911 f( 3 );                   g( &3 );              §\C{// compiler implicit generates temporaries}§
    912 f( x + y );             g( &(x + y) );  §\C{// compiler implicit generates temporaries}§
     930f( 3 );                   g( ®&®3 );            §\C{// compiler implicit generates temporaries}§
     931f( x + y );             g( ®&®(x + y) );        §\C{// compiler implicit generates temporaries}§
    913932\end{cfa}
    914933Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{
    … …  
    917936
    918937%\CFA attempts to handle pointers and references in a uniform, symmetric manner.
    919 However, C handles routine objects in an inconsistent way.
    920 A routine object is both a pointer and a reference (particle and wave).
     938Finally, C handles \Index{routine object}s in an inconsistent way.
     939A routine object is both a pointer and a reference (\Index{particle and wave}).
    921940\begin{cfa}
    922941void f( int i );
    923 void (*fp)( int );
    924 fp = f;                                                 §\C{// reference initialization}§
    925 fp = &f;                                                §\C{// pointer initialization}§
    926 fp = *f;                                                §\C{// reference initialization}§
    927 fp(3);                                                  §\C{// reference invocation}§
    928 (*fp)(3);                                               §\C{// pointer invocation}§
    929 \end{cfa}
    930 A routine object is best described by a ©const© reference:
    931 \begin{cfa}
    932 const void (&fr)( int ) = f;
    933 fr = ...                                                §\C{// error, cannot change code}§
    934 &fr = ...;                                              §\C{// changing routine reference}§
    935 fr( 3 );                                                §\C{// reference call to f}§
    936 (*fr)(3);                                               §\C{// error, incorrect type}§
     942void (*fp)( int );                                      §\C{// routine pointer}§
     943fp = f;                                                         §\C{// reference initialization}§
     944fp = &f;                                                        §\C{// pointer initialization}§
     945fp = *f;                                                        §\C{// reference initialization}§
     946fp(3);                                                          §\C{// reference invocation}§
     947(*fp)(3);                                                       §\C{// pointer invocation}§
     948\end{cfa}
     949While C's treatment of routine objects has similarity to inferring a reference type in initialization contexts, the examples are assignment not initialization, and all possible forms of assignment are possible (©f©, ©&f©, ©*f©) without regard for type.
     950Instead, a routine object should be referenced by a ©const© reference:
     951\begin{cfa}
     952®const® void (®&® fr)( int ) = f;       §\C{// routine reference}§
     953fr = ...                                                        §\C{// error, cannot change code}§
     954&fr = ...;                                                      §\C{// changing routine reference}§
     955fr( 3 );                                                        §\C{// reference call to f}§
     956(*fr)(3);                                                       §\C{// error, incorrect type}§
    937957\end{cfa}
    938958because the value of the routine object is a routine literal, \ie the routine code is normally immutable during execution.\footnote{
    … …  
    940960\CFA allows this additional use of references for routine objects in an attempt to give a more consistent meaning for them.
    941961
    942 This situation is different from inferring with reference type being used ...
    943 
     962
     963\subsection{Address-of Semantics}
     964
     965In C, ©&E© is an rvalue for any expression ©E©.
     966\CFA extends the ©&© (address-of) operator as follows:
     967\begin{itemize}
     968\item
     969if ©R© is an \Index{rvalue} of type ©T &$_1$...&$_r$© where $r \ge 1$ references (©&© symbols) than ©&R© has type ©T ®*®&$_{\color{red}2}$...&$_{\color{red}r}$©, \ie ©T© pointer with $r-1$ references (©&© symbols).
     970
     971\item
     972if ©L© is an \Index{lvalue} of type ©T &$_1$...&$_l$© where $l \ge 0$ references (©&© symbols) then ©&L© has type ©T ®*®&$_{\color{red}1}$...&$_{\color{red}l}$©, \ie ©T© pointer with $l$ references (©&© symbols).
     973\end{itemize}
     974The following example shows the first rule applied to different \Index{rvalue} contexts:
     975\begin{cfa}
     976int x, * px, ** ppx, *** pppx, **** ppppx;
     977int & rx = x, && rrx = rx, &&& rrrx = rrx ;
     978x = rrrx;               // rrrx is an lvalue with type int &&& (equivalent to x)
     979px = &rrrx;             // starting from rrrx, &rrrx is an rvalue with type int *&&& (&x)
     980ppx = &&rrrx;   // starting from &rrrx, &&rrrx is an rvalue with type int **&& (&rx)
     981pppx = &&&rrrx; // starting from &&rrrx, &&&rrrx is an rvalue with type int ***& (&rrx)
     982ppppx = &&&&rrrx; // starting from &&&rrrx, &&&&rrrx is an rvalue with type int **** (&rrrx)
     983\end{cfa}
     984The following example shows the second rule applied to different \Index{lvalue} contexts:
     985\begin{cfa}
     986int x, * px, ** ppx, *** pppx;
     987int & rx = x, && rrx = rx, &&& rrrx = rrx ;
     988rrrx = 2;               // rrrx is an lvalue with type int &&& (equivalent to x)
     989&rrrx = px;             // starting from rrrx, &rrrx is an rvalue with type int *&&& (rx)
     990&&rrrx = ppx;   // starting from &rrrx, &&rrrx is an rvalue with type int **&& (rrx)
     991&&&rrrx = pppx; // starting from &&rrrx, &&&rrrx is an rvalue with type int ***& (rrrx)
     992\end{cfa}
     993
     994
     995\subsection{Conversions}
     996
     997C provides a basic implicit conversion to simplify variable usage:
     998\begin{enumerate}
     999\setcounter{enumi}{-1}
     1000\item
     1001lvalue to rvalue conversion: ©cv T© converts to ©T©, which allows implicit variable dereferencing.
     1002\begin{cfa}
     1003int x;
     1004x + 1;                  // lvalue variable (int) converts to rvalue for expression
     1005\end{cfa}
     1006An rvalue has no type qualifiers (©cv©), so the lvalue qualifiers are dropped.
     1007\end{enumerate}
     1008\CFA provides three new implicit conversion for reference types to simplify reference usage.
     1009\begin{enumerate}
     1010\item
     1011reference to rvalue conversion: ©cv T &© converts to ©T©, which allows implicit reference dereferencing.
     1012\begin{cfa}
     1013int x, &r = x, f( int p );
     1014x = ®r® + f( ®r® );  // lvalue reference converts to rvalue
     1015\end{cfa}
     1016An rvalue has no type qualifiers (©cv©), so the reference qualifiers are dropped.
     1017
     1018\item
     1019lvalue to reference conversion: \lstinline[deletekeywords={lvalue}]@lvalue-type cv1 T@ converts to ©cv2 T &©, which allows implicitly converting variables to references.
     1020\begin{cfa}
     1021int x, &r = ®x®, f( int & p ); // lvalue variable (int) convert to reference (int &)
     1022f( ®x® );               // lvalue variable (int) convert to reference (int &)
     1023\end{cfa}
     1024Conversion can restrict a type, where ©cv1© $\le$ ©cv2©, \eg passing an ©int© to a ©const volatile int &©, which has low cost.
     1025Conversion can expand a type, where ©cv1© $>$ ©cv2©, \eg passing a ©const volatile int© to an ©int &©, which has high cost (\Index{warning});
     1026furthermore, if ©cv1© has ©const© but not ©cv2©, a temporary variable is created to preserve the immutable lvalue.
     1027
     1028\item
     1029rvalue to reference conversion: ©T© converts to ©cv T &©, which allows binding references to temporaries.
     1030\begin{cfa}
     1031int x, & f( int & p );
     1032f( ®x + 3® );   // rvalue parameter (int) implicitly converts to lvalue temporary reference (int &)
     1033®&f®(...) = &x; // rvalue result (int &) implicitly converts to lvalue temporary reference (int &)
     1034\end{cfa}
     1035In both case, modifications to the temporary are inaccessible (\Index{warning}).
     1036Conversion expands the temporary-type with ©cv©, which is low cost since the temporary is inaccessible.
     1037\end{enumerate}
    9441038
    9451039
    9461040\begin{comment}
    947 \section{References}
    948 
    949 By introducing references in parameter types, users are given an easy way to pass a value by reference, without the need for NULL pointer checks.
    950 In structures, a reference can replace a pointer to an object that should always have a valid value.
    951 When a structure contains a reference, all of its constructors must initialize the reference and all instances of this structure must initialize it upon definition.
    952 
    953 The syntax for using references in \CFA is the same as \CC with the exception of reference initialization.
    954 Use ©&© to specify a reference, and access references just like regular objects, not like pointers (use dot notation to access fields).
    955 When initializing a reference, \CFA uses a different syntax which differentiates reference initialization from assignment to a reference.
    956 The ©&© is used on both sides of the expression to clarify that the address of the reference is being set to the address of the variable to which it refers.
    957 
    958 
    9591041From: Richard Bilson <rcbilson@gmail.com>
    9601042Date: Wed, 13 Jul 2016 01:58:58 +0000
    … …  
    11181200\section{Routine Definition}
    11191201
    1120 \CFA also supports a new syntax for routine definition, as well as ISO C and K\&R routine syntax.
     1202\CFA also supports a new syntax for routine definition, as well as \Celeven and K\&R routine syntax.
    11211203The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg:
    11221204\begin{cfa}
    … …  
    11381220in both cases the type is assumed to be void as opposed to old style C defaults of int return type and unknown parameter types, respectively, as in:
    11391221\begin{cfa}
    1140 [§\,§] g();                                             §\C{// no input or output parameters}§
    1141 [ void ] g( void );                             §\C{// no input or output parameters}§
     1222[§\,§] g();                                                     §\C{// no input or output parameters}§
     1223[ void ] g( void );                                     §\C{// no input or output parameters}§
    11421224\end{cfa}
    11431225
    … …  
    11571239\begin{cfa}
    11581240typedef int foo;
    1159 int f( int (* foo) );                   §\C{// foo is redefined as a parameter name}§
     1241int f( int (* foo) );                           §\C{// foo is redefined as a parameter name}§
    11601242\end{cfa}
    11611243The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
    … …  
    11651247C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg:
    11661248\begin{cfa}
    1167 [ int ] f( * int, int * );              §\C{// returns an integer, accepts 2 pointers to integers}§
    1168 [ * int, int * ] f( int );              §\C{// returns 2 pointers to integers, accepts an integer}§
     1249[ int ] f( * int, int * );                      §\C{// returns an integer, accepts 2 pointers to integers}§
     1250[ * int, int * ] f( int );                      §\C{// returns 2 pointers to integers, accepts an integer}§
    11691251\end{cfa}
    11701252The reason for allowing both declaration styles in the new context is for backwards compatibility with existing preprocessor macros that generate C-style declaration-syntax, as in:
    11711253\begin{cfa}
    11721254#define ptoa( n, d ) int (*n)[ d ]
    1173 int f( ptoa( p, 5 ) ) ...               §\C{// expands to int f( int (*p)[ 5 ] )}§
    1174 [ int ] f( ptoa( p, 5 ) ) ...   §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§
     1255int f( ptoa( p, 5 ) ) ...                       §\C{// expands to int f( int (*p)[ 5 ] )}§
     1256[ int ] f( ptoa( p, 5 ) ) ...           §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§
    11751257\end{cfa}
    11761258Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms.
    … …  
    11941276        int z;
    11951277        ... x = 0; ... y = z; ...
    1196         ®return;® §\C{// implicitly return x, y}§
     1278        ®return;®                                                       §\C{// implicitly return x, y}§
    11971279}
    11981280\end{cfa}
    … …  
    12041286[ int x, int y ] f() {
    12051287        ...
    1206 } §\C{// implicitly return x, y}§
     1288}                                                                               §\C{// implicitly return x, y}§
    12071289\end{cfa}
    12081290In this case, the current values of ©x© and ©y© are returned to the calling routine just as if a ©return© had been encountered.
     1291
     1292Named return values may be used in conjunction with named parameter values;
     1293specifically, a return and parameter can have the same name.
     1294\begin{cfa}
     1295[ int x, int y ] f( int, x, int y ) {
     1296        ...
     1297}                                                                               §\C{// implicitly return x, y}§
     1298\end{cfa}
     1299This notation allows the compiler to eliminate temporary variables in nested routine calls.
     1300\begin{cfa}
     1301[ int x, int y ] f( int, x, int y );    §\C{// prototype declaration}§
     1302int a, b;
     1303[a, b] = f( f( f( a, b ) ) );
     1304\end{cfa}
     1305While the compiler normally ignores parameters names in prototype declarations, here they are used to eliminate temporary return-values by inferring that the results of each call are the inputs of the next call, and ultimately, the left-hand side of the assignment.
     1306Hence, even without the body of routine ©f© (separate compilation), it is possible to perform a global optimization across routine calls.
     1307The compiler warns about naming inconsistencies between routine prototype and definition in this case, and behaviour is \Index{undefined} if the programmer is inconsistent.
    12091308
    12101309
    … …  
    12141313as well, parameter names are optional, \eg:
    12151314\begin{cfa}
    1216 [ int x ] f ();                                 §\C{// returning int with no parameters}§
    1217 [ * int ] g (int y);                    §\C{// returning pointer to int with int parameter}§
    1218 [ ] h (int,char);                               §\C{// returning no result with int and char parameters}§
    1219 [ * int,int ] j (int);                  §\C{// returning pointer to int and int, with int parameter}§
     1315[ int x ] f ();                                                 §\C{// returning int with no parameters}§
     1316[ * int ] g (int y);                                    §\C{// returning pointer to int with int parameter}§
     1317[ ] h ( int, char );                                    §\C{// returning no result with int and char parameters}§
     1318[ * int, int ] j ( int );                               §\C{// returning pointer to int and int, with int parameter}§
    12201319\end{cfa}
    12211320This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa).
    … …  
    12251324\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    12261325\begin{cfa}
    1227 [ int ] f(int), g;
     1326[ int ] f( int ), g;
    12281327\end{cfa}
    12291328&
    12301329\begin{cfa}
    1231 int f(int), g(int);
     1330int f( int ), g( int );
    12321331\end{cfa}
    12331332\end{tabular}
    … …  
    12351334Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} \eg:
    12361335\begin{cfa}
    1237 extern [ int ] f (int);
    1238 static [ int ] g (int);
     1336extern [ int ] f ( int );
     1337static [ int ] g ( int );
    12391338\end{cfa}
    12401339
    … …  
    12441343The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg:
    12451344\begin{cfa}
    1246 * [ int x ] () fp;                      §\C{// pointer to routine returning int with no parameters}§
    1247 * [ * int ] (int y) gp;         §\C{// pointer to routine returning pointer to int with int parameter}§
    1248 * [ ] (int,char) hp;            §\C{// pointer to routine returning no result with int and char parameters}§
    1249 * [ * int,int ] (int) jp;       §\C{// pointer to routine returning pointer to int and int, with int parameter}§
     1345* [ int x ] () fp;                                              §\C{// pointer to routine returning int with no parameters}§
     1346* [ * int ] (int y) gp;                                 §\C{// pointer to routine returning pointer to int with int parameter}§
     1347* [ ] (int,char) hp;                                    §\C{// pointer to routine returning no result with int and char parameters}§
     1348* [ * int,int ] ( int ) jp;                             §\C{// pointer to routine returning pointer to int and int, with int parameter}§
    12501349\end{cfa}
    12511350While parameter names are optional, \emph{a routine name cannot be specified};
    12521351for example, the following is incorrect:
    12531352\begin{cfa}
    1254 * [ int x ] f () fp;            §\C{// routine name "f" is not allowed}§
     1353* [ int x ] f () fp;                                    §\C{// routine name "f" is not allowed}§
    12551354\end{cfa}
    12561355
    … …  
    12581357\section{Named and Default Arguments}
    12591358
    1260 Named and default arguments~\cite{Hardgrave76}\footnote{
     1359Named\index{named arguments}\index{arguments!named} and default\index{default arguments}\index{arguments!default} arguments~\cite{Hardgrave76}\footnote{
    12611360Francez~\cite{Francez77} proposed a further extension to the named-parameter passing style, which specifies what type of communication (by value, by reference, by name) the argument is passed to the routine.}
    12621361are two mechanisms to simplify routine call.
    … …  
    14391538        int ;                                   §\C{// disallowed, unnamed field}§
    14401539        int *;                                  §\C{// disallowed, unnamed field}§
    1441         int (*)(int);                   §\C{// disallowed, unnamed field}§
     1540        int (*)( int );                 §\C{// disallowed, unnamed field}§
    14421541};
    14431542\end{cfa}
    … …  
    15621661}
    15631662int main() {
    1564         * [int](int) fp = foo();        §\C{// int (*fp)(int)}§
     1663        * [int]( int ) fp = foo();      §\C{// int (*fp)( int )}§
    15651664        sout | fp( 3 ) | endl;
    15661665}
    … …  
    26832782
    26842783
    2685 \subsection{Constructors and Destructors}
     2784\section{Constructors and Destructors}
    26862785
    26872786\CFA supports C initialization of structures, but it also adds constructors for more advanced initialization.
    … …  
    30143113
    30153114
     3115\begin{comment}
    30163116\section{Generics}
    30173117
    … …  
    32203320        }
    32213321\end{cfa}
     3322\end{comment}
    32223323
    32233324
    … …  
    32793380        Complex *p3 = new(0.5, 1.0); // allocate + 2 param constructor
    32803381}
    3281 
    32823382\end{cfa}
    32833383
    … …  
    32913391
    32923392
     3393\begin{comment}
    32933394\subsection{Unsafe C Constructs}
    32943395
    … …  
    33013402The exact set of unsafe C constructs that will be disallowed in \CFA has not yet been decided, but is sure to include pointer arithmetic, pointer casting, etc.
    33023403Once the full set is decided, the rules will be listed here.
     3404\end{comment}
    33033405
    33043406
    33053407\section{Concurrency}
    3306 
    3307 Today's processors for nearly all use cases, ranging from embedded systems to large cloud computing servers, are composed of multiple cores, often heterogeneous.
    3308 As machines grow in complexity, it becomes more difficult for a program to make the most use of the hardware available.
    3309 \CFA includes built-in concurrency features to enable high performance and improve programmer productivity on these multi-/many-core machines.
    33103408
    33113409Concurrency support in \CFA is implemented on top of a highly efficient runtime system of light-weight, M:N, user level threads.
    … …  
    33143412This enables a very familiar interface to all programmers, even those with no parallel programming experience.
    33153413It also allows the compiler to do static type checking of all communication, a very important safety feature.
    3316 This controlled communication with type safety has some similarities with channels in \Index*{Go}, and can actually implement
    3317 channels exactly, as well as create additional communication patterns that channels cannot.
     3414This controlled communication with type safety has some similarities with channels in \Index*{Go}, and can actually implement channels exactly, as well as create additional communication patterns that channels cannot.
    33183415Mutex objects, monitors, are used to contain mutual exclusion within an object and synchronization across concurrent threads.
    33193416
    3320 Three new keywords are added to support these features:
    3321 
    3322 monitor creates a structure with implicit locking when accessing fields
    3323 
    3324 mutex implies use of a monitor requiring the implicit locking
    3325 
    3326 task creates a type with implicit locking, separate stack, and a thread
     3417\begin{figure}
     3418\begin{cfa}
     3419#include <fstream>
     3420#include <coroutine>
     3421
     3422coroutine Fibonacci {
     3423        int fn;                                                         §\C{// used for communication}§
     3424};
     3425void ?{}( Fibonacci * this ) {
     3426        this->fn = 0;
     3427}
     3428void main( Fibonacci * this ) {
     3429        int fn1, fn2;                                           §\C{// retained between resumes}§
     3430        this->fn = 0;                                           §\C{// case 0}§
     3431        fn1 = this->fn;
     3432        suspend();                                                      §\C{// return to last resume}§
     3433
     3434        this->fn = 1;                                           §\C{// case 1}§
     3435        fn2 = fn1;
     3436        fn1 = this->fn;
     3437        suspend();                                                      §\C{// return to last resume}§
     3438
     3439        for ( ;; ) {                                            §\C{// general case}§
     3440                this->fn = fn1 + fn2;
     3441                fn2 = fn1;
     3442                fn1 = this->fn;
     3443                suspend();                                              §\C{// return to last resume}§
     3444        } // for
     3445}
     3446int next( Fibonacci * this ) {
     3447        resume( this );                                         §\C{// transfer to last suspend}§
     3448        return this->fn;
     3449}
     3450int main() {
     3451        Fibonacci f1, f2;
     3452        for ( int i = 1; i <= 10; i += 1 ) {
     3453                sout | next( &f1 ) | ' ' | next( &f2 ) | endl;
     3454        } // for
     3455}
     3456\end{cfa}
     3457\caption{Fibonacci Coroutine}
     3458\label{f:FibonacciCoroutine}
     3459\end{figure}
     3460
     3461
     3462\subsection{Coroutine}
     3463
     3464\Index{Coroutines} are the precursor to tasks.
     3465\VRef[Figure]{f:FibonacciCoroutine} shows a coroutine that computes the \Index*{Fibonacci} numbers.
    33273466
    33283467
    … …  
    33393478\end{cfa}
    33403479
     3480\begin{figure}
     3481\begin{cfa}
     3482#include <fstream>
     3483#include <kernel>
     3484#include <monitor>
     3485#include <thread>
     3486
     3487monitor global_t {
     3488        int value;
     3489};
     3490
     3491void ?{}(global_t * this) {
     3492        this->value = 0;
     3493}
     3494
     3495static global_t global;
     3496
     3497void increment3( global_t * mutex this ) {
     3498        this->value += 1;
     3499}
     3500void increment2( global_t * mutex this ) {
     3501        increment3( this );
     3502}
     3503void increment( global_t * mutex this ) {
     3504        increment2( this );
     3505}
     3506
     3507thread MyThread {};
     3508
     3509void main( MyThread* this ) {
     3510        for(int i = 0; i < 1_000_000; i++) {
     3511                increment( &global );
     3512        }
     3513}
     3514int main(int argc, char* argv[]) {
     3515        processor p;
     3516        {
     3517                MyThread f[4];
     3518        }
     3519        sout | global.value | endl;
     3520}
     3521\end{cfa}
     3522\caption{Atomic-Counter Monitor}
     3523\caption{f:AtomicCounterMonitor}
     3524\end{figure}
     3525
     3526\begin{comment}
    33413527Since a monitor structure includes an implicit locking mechanism, it does not make sense to copy a monitor;
    33423528it is always passed by reference.
    … …  
    33853571}
    33863572\end{cfa}
     3573\end{comment}
    33873574
    33883575
    … …  
    33923579A task provides mutual exclusion like a monitor, and also has its own execution state and a thread of control.
    33933580Similar to a monitor, a task is defined like a structure:
     3581
     3582\begin{figure}
     3583\begin{cfa}
     3584#include <fstream>
     3585#include <kernel>
     3586#include <stdlib>
     3587#include <thread>
     3588
     3589thread First  { signal_once * lock; };
     3590thread Second { signal_once * lock; };
     3591
     3592void ?{}( First * this, signal_once* lock ) { this->lock = lock; }
     3593void ?{}( Second * this, signal_once* lock ) { this->lock = lock; }
     3594
     3595void main( First * this ) {
     3596        for ( int i = 0; i < 10; i += 1 ) {
     3597                sout | "First : Suspend No." | i + 1 | endl;
     3598                yield();
     3599        }
     3600        signal( this->lock );
     3601}
     3602
     3603void main( Second * this ) {
     3604        wait( this->lock );
     3605        for ( int i = 0; i < 10; i += 1 ) {
     3606                sout | "Second : Suspend No." | i + 1 | endl;
     3607                yield();
     3608        }
     3609}
     3610
     3611int main( void ) {
     3612        signal_once lock;
     3613        sout | "User main begin" | endl;
     3614        {
     3615                processor p;
     3616                {
     3617                        First  f = { &lock };
     3618                        Second s = { &lock };
     3619                }
     3620        }
     3621        sout | "User main end" | endl;
     3622}
     3623\end{cfa}
     3624\caption{Simple Tasks}
     3625\label{f:SimpleTasks}
     3626\end{figure}
     3627
     3628
     3629\begin{comment}
    33943630\begin{cfa}
    33953631type Adder = task {
    … …  
    34453681\end{cfa}
    34463682
    3447 
    34483683\subsection{Cooperative Scheduling}
    34493684
    … …  
    35583793}
    35593794\end{cfa}
    3560 
    3561 
     3795\end{comment}
     3796
     3797
     3798\begin{comment}
    35623799\section{Modules and Packages }
    35633800
    3564 \begin{comment}
    35653801High-level encapsulation is useful for organizing code into reusable units, and accelerating compilation speed.
    35663802\CFA provides a convenient mechanism for creating, building and sharing groups of functionality that enhances productivity and improves compile time.
    … …  
    42264462
    42274463
     4464\begin{comment}
    42284465\subsection[Comparing Key Features of CFA]{Comparing Key Features of \CFA}
    42294466
    … …  
    46034840
    46044841
    4605 \begin{comment}
    46064842\subsubsection{Modules / Packages}
    46074843
    … …  
    46834919}
    46844920\end{cfa}
    4685 \end{comment}
    46864921
    46874922
    … …  
    48445079
    48455080\subsection{Summary of Language Comparison}
    4846 
    4847 
    4848 \subsubsection[C++]{\CC}
     5081\end{comment}
     5082
     5083
     5084\subsection[C++]{\CC}
    48495085
    48505086\Index*[C++]{\CC{}} is a general-purpose programming language.
    … …  
    48675103
    48685104
    4869 \subsubsection{Go}
     5105\subsection{Go}
    48705106
    48715107\Index*{Go}, also commonly referred to as golang, is a programming language developed at Google in 2007 [.].
    … …  
    48835119
    48845120
    4885 \subsubsection{Rust}
     5121\subsection{Rust}
    48865122
    48875123\Index*{Rust} is a general-purpose, multi-paradigm, compiled programming language developed by Mozilla Research.
    … …  
    48975133
    48985134
    4899 \subsubsection{D}
     5135\subsection{D}
    49005136
    49015137The \Index*{D} programming language is an object-oriented, imperative, multi-paradigm system programming
    … …  
    50095245\item[Rationale:] keywords added to implement new semantics of \CFA.
    50105246\item[Effect on original feature:] change to semantics of well-defined feature. \\
    5011 Any ISO C programs using these keywords as identifiers are invalid \CFA programs.
     5247Any \Celeven programs using these keywords as identifiers are invalid \CFA programs.
    50125248\item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}).
    50135249\item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.
    … …  
    52295465hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}).
    52305466All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling.
     5467For \Index*[C++]{\CC{}}, the name-mangling issue is handled implicitly because most C header-files are augmented with checks for preprocessor variable ©__cplusplus©, which adds appropriate ©extern "C"© qualifiers.
    52315468
    52325469
    … …  
    53115548}
    53125549
    5313 // §\CFA§ safe initialization/copy
     5550// §\CFA§ safe initialization/copy, i.e., implicit size specification
    53145551forall( dtype T | sized(T) ) T * memset( T * dest, char c );§\indexc{memset}§
    53155552forall( dtype T | sized(T) ) T * memcpy( T * dest, const T * src );§\indexc{memcpy}§
    … …  
    54215658\leavevmode
    54225659\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5423 forall( otype T | { int ?<?( T, T ); } )
    5424 T min( T t1, T t2 );§\indexc{min}§
    5425 
    5426 forall( otype T | { int ?>?( T, T ); } )
    5427 T max( T t1, T t2 );§\indexc{max}§
    5428 
    5429 forall( otype T | { T min( T, T ); T max( T, T ); } )
    5430 T clamp( T value, T min_val, T max_val );§\indexc{clamp}§
    5431 
    5432 forall( otype T )
    5433 void swap( T * t1, T * t2 );§\indexc{swap}§
     5660forall( otype T | { int ?<?( T, T ); } ) T min( T t1, T t2 );§\indexc{min}§
     5661forall( otype T | { int ?>?( T, T ); } ) T max( T t1, T t2 );§\indexc{max}§
     5662forall( otype T | { T min( T, T ); T max( T, T ); } ) T clamp( T value, T min_val, T max_val );§\indexc{clamp}§
     5663forall( otype T ) void swap( T * t1, T * t2 );§\indexc{swap}§
    54345664\end{cfa}
    54355665
Note: See TracChangeset for help on using the changeset viewer.