Index: doc/user/user.tex =================================================================== --- doc/user/user.tex (revision 0642216de9210d21de06af3779a92d1cceff6a80) +++ doc/user/user.tex (revision 27caf8d03f24f559d9889acd368b5bcca03135c4) @@ -11,6 +11,6 @@ %% Created On : Wed Apr 6 14:53:29 2016 %% Last Modified By : Peter A. Buhr -%% Last Modified On : Wed May 17 22:42:11 2017 -%% Update Count : 1685 +%% Last Modified On : Fri May 19 11:54:31 2017 +%% Update Count : 1735 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -668,5 +668,5 @@ One way to conceptualize the null pointer is that no variable is placed at this address, so the null-pointer address can be used to denote an uninitialized pointer/reference object; \ie the null pointer is guaranteed to compare unequal to a pointer to any object or routine.} -An address is \newterm{sound}, if it points to a valid memory location in scope, \ie has not been freed. +An address is \newterm{sound}, if it points to a valid memory location in scope, \ie within the program's execution-environment and has not been freed. Dereferencing an \newterm{unsound} address, including the null pointer, is \Index{undefined}, often resulting in a \Index{memory fault}. @@ -717,8 +717,8 @@ \end{quote2} Finally, the immutable nature of a variable's address and the fact that there is no storage for the variable pointer means pointer assignment\index{pointer!assignment}\index{assignment!pointer} is impossible. -Therefore, the expression ©x = y© has only one meaning, ©*x = *y©, \ie manipulate values, which is why explicitly writing the dereferences is unnecessary even though it occurs implicitly as part of instruction decoding. +Therefore, the expression ©x = y© has only one meaning, ©*x = *y©, \ie manipulate values, which is why explicitly writing the dereferences is unnecessary even though it occurs implicitly as part of \Index{instruction decoding}. A \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. -(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.) +(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.) Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, \eg: \begin{quote2} @@ -736,7 +736,7 @@ \end{quote2} -Notice, an address has a duality\index{address!duality}: a location in memory or the value at that location. +Notice, an address has a \Index{duality}\index{address!duality}: a location in memory or the value at that location. In many cases, a compiler might be able to infer the best meaning for these two cases. -For example, \Index*{Algol68}~\cite{Algol68} inferences pointer dereferencing to select the best meaning for each pointer usage +For example, \Index*{Algol68}~\cite{Algol68} infers pointer dereferencing to select the best meaning for each pointer usage \begin{cfa} p2 = p1 + x; §\C{// compiler infers *p2 = *p1 + x;}§ @@ -745,5 +745,5 @@ Unfortunately, automatic dereferencing does not work in all cases, and so some mechanism is necessary to fix incorrect choices. -Rather than dereference inferencing, most programming languages pick one implicit dereferencing semantics, and the programmer explicitly indicates the other to resolve address-duality. +Rather than inferring dereference, most programming languages pick one implicit dereferencing semantics, and the programmer explicitly indicates the other to resolve address-duality. In C, objects of pointer type always manipulate the pointer object's address: \begin{cfa} @@ -768,5 +768,5 @@ \end{cfa} -To support this common case, a reference type is introduced in \CFA, denoted by ©&©, which is the opposite dereference semantics to a pointer type, making the value at the pointed-to location the implicit semantics for dereferencing. +To support this common case, a reference type is introduced in \CFA, denoted by ©&©, which is the opposite dereference semantics to a pointer type, making the value at the pointed-to location the implicit semantics for dereferencing (similar but not the same as \CC \Index{reference type}s). \begin{cfa} int x, y, ®&® r1, ®&® r2, ®&&® r3; @@ -783,15 +783,16 @@ ®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15); \end{cfa} -When a reference operation appears beside a dereference operation, \eg ©&*©, they cancel out.\footnote{ +When a reference operation appears beside a dereference operation, \eg ©&*©, they cancel out. +However, in C, the cancellation always yields a value (\Index{rvalue}).\footnote{ The unary ©&© operator yields the address of its operand. If the operand has type ``type'', the result has type ``pointer to type''. If the operand is the result of a unary ©*© operator, neither that operator nor the ©&© operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue.~\cite[\S~6.5.3.2--3]{C11}} -Hence, assigning to a reference requires the address of the reference variable (\Index{lvalue}): -\begin{cfa} -(&®*®)r1 = &x; §\C{// (\&*) cancel giving variable r1 not variable pointed-to by r1}§ +For a \CFA reference type, the cancellation on the left-hand side of assignment leaves the reference as an address (\Index{lvalue}): +\begin{cfa} +(&®*®)r1 = &x; §\C{// (\&*) cancel giving address of r1 not variable pointed-to by r1}§ \end{cfa} Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}): \begin{cfa} -(&(&®*®)®*®)r3 = &(&®*®)r2; §\C{// (\&*) cancel giving address of r2, (\&(\&*)*) cancel giving variable r3}§ +(&(&®*®)®*®)r3 = &(&®*®)r2; §\C{// (\&*) cancel giving address of r2, (\&(\&*)*) cancel giving address of r3}§ \end{cfa} Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth. @@ -810,5 +811,5 @@ \end{cfa} Furthermore, both types are equally performant, as the same amount of dereferencing occurs for both types. -Therefore, the choice between them is based solely on whether the address is dereferenced frequently or infrequently, which dictates the amount of dereferencing aid from the compiler. +Therefore, the choice between them is based solely on whether the address is dereferenced frequently or infrequently, which dictates the amount of implicit dereferencing aid from the compiler. As for a pointer type, a reference type may have qualifiers: @@ -828,7 +829,8 @@ int & const cr = *0; §\C{// where 0 is the int * zero}§ \end{cfa} -Note, constant reference types do not prevent addressing errors because of explicit storage-management: +Note, constant reference-types do not prevent addressing errors because of explicit storage-management: \begin{cfa} int & const cr = *malloc(); +cr = 5; delete &cr; cr = 7; §\C{// unsound pointer dereference}§ @@ -854,28 +856,38 @@ where the \CFA declaration is read left-to-right (see \VRef{s:Declarations}). -In contract 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}. -\Index*{Java}'s reference types to objects (because 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. +In 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}. +\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. \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. There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, return/temporary binding. -For reference initialization (like pointer), the initializing value must be an address (\Index{lvalue}) not a value (\Index{rvalue}). -\begin{cfa} -int * p = &x; §\C{// both \&x and x are possible interpretations in C}§ -int & r = x; §\C{// x unlikely interpretation, because of auto-dereferencing}§ -\end{cfa} -C allows ©p© to be assigned with ©&x© or ©x© (many compilers warn about the latter assignment). -\CFA allows ©r© to be assigned ©x© only because it inferences a dereference for ©x©, by implicitly inserting a address-of operator, ©&©, before the initialization expression because a reference behaves like the variable name it is pointing-to. -Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference operator for the same reason. -\begin{cfa} -int & f( int & rp ); §\C{// reference parameter and return}§ +Because 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. +In contrast, the left-hand side of assignment has an address that has a duality. +Therefore, for pointer/reference initialization, the initializing value must be an address (\Index{lvalue}) not a value (\Index{rvalue}). +\begin{cfa} +int * p = &x; §\C{// must have address of x}§ +int & r = x; §\C{// must have address of x}§ +\end{cfa} +Therefore, it is superfluous to require explicitly taking the address of the initialization object, even though the type is incorrect. +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. +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. +(\CFA extends pointer initialization so a variable name is automatically referenced, eliminating the unsafe assignment.) +Similarly, 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. +\begin{cfa} +int & f( int & r ); §\C{// reference parameter and return}§ z = f( x ) + f( y ); §\C{// reference operator added, temporaries needed for call results}§ \end{cfa} -Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©rp© can be locally reassigned within ©f©. +Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©r© can be locally reassigned within ©f©. Since operator routine ©?+?© takes its arguments by value, the references returned from ©f© are used to initialize compiler generated temporaries with value semantics that copy from the references. +\begin{cfa} +int temp1 = f( x ), temp2 = f( y ); +z = temp1 + temp2; +\end{cfa} +This implicit referencing is crucial for reducing the syntactic burden for programmers when using references; +otherwise references have the same syntactic burden as pointers in these contexts. When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions. \begin{cfa} -void f( ®const® int & crp ); -void g( ®const® int * cpp ); +void f( ®const® int & cr ); +void g( ®const® int * cp ); f( 3 ); g( &3 ); f( x + y ); g( &(x + y) ); @@ -883,8 +895,9 @@ Here, 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. (The ©&© is necessary for the pointer-type parameter to make the types match, and is a common requirement for a C programmer.) -\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. -\begin{cfa} -void f( int & rp ); -void g( int * pp ); +\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{ +If whole program analysis is possible, and shows the parameter is not assigned, \ie it is ©const©, the temporary is unnecessary.} +\begin{cfa} +void f( int & r ); +void g( int * p ); f( 3 ); g( &3 ); §\C{// compiler implicit generates temporaries}§ f( x + y ); g( &(x + y) ); §\C{// compiler implicit generates temporaries}§ @@ -894,22 +907,30 @@ The implicit conversion allows seamless calls to any routine without having to explicitly name/copy the literal/expression to allow the call. -While \CFA attempts to handle pointers and references in a uniform, symmetric manner, C handles routine objects in an inconsistent way: a routine object is both a pointer and a reference (particle and wave). -\begin{cfa} -void f( int p ) {...} -void (*fp)( int ) = &f; §\C{// pointer initialization}§ -void (*fp)( int ) = f; §\C{// reference initialization}§ +%\CFA attempts to handle pointers and references in a uniform, symmetric manner. +However, C handles routine objects in an inconsistent way. +A routine object is both a pointer and a reference (particle and wave). +\begin{cfa} +void f( int i ); +void (*fp)( int ); +fp = f; §\C{// reference initialization}§ +fp = &f; §\C{// pointer initialization}§ +fp = *f; §\C{// reference initialization}§ +fp(3); §\C{// reference invocation}§ (*fp)(3); §\C{// pointer invocation}§ -fp(3); §\C{// reference invocation}§ \end{cfa} A routine object is best described by a ©const© reference: \begin{cfa} -const void (&fp)( int ) = f; -fp( 3 ); -fp = ... §\C{// error, cannot change code}§ -&fp = ...; §\C{// changing routine reference}§ +const void (&fr)( int ) = f; +fr = ... §\C{// error, cannot change code}§ +&fr = ...; §\C{// changing routine reference}§ +fr( 3 ); §\C{// reference call to f}§ +(*fr)(3); §\C{// error, incorrect type}§ \end{cfa} because the value of the routine object is a routine literal, \ie the routine code is normally immutable during execution.\footnote{ Dynamic code rewriting is possible but only in special circumstances.} \CFA allows this additional use of references for routine objects in an attempt to give a more consistent meaning for them. + +This situation is different from inferring with reference type being used ... + @@ -1529,5 +1550,5 @@ int main() { * [int](int) fp = foo(); §\C{// int (*fp)(int)}§ - sout | fp( 3 ) | endl; + sout | fp( 3 ) | endl; } \end{cfa} @@ -2145,5 +2166,5 @@ ®int j = 0;® §\C{// disallowed}§ case 1: - { + { ®int k = 0;® §\C{// allowed at different nesting levels}§ ...