Context Navigation

Reverse Diff

user.tex [0642216:3dafd83]

File:

: 1 edited

doc/user/user.tex (modified) (39 diffs)

Legend:

: Unmodified
: Added
: Removed

doc/user/user.tex

-                      r0642216
+                      r3dafd83
 %% 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 : Mon May 15 18:29:58 2017
+%% Update Count     : 1598
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \author{
 \huge \CFA Team \medskip \\
 \Large Richard Bilson, Peter A. Buhr, Thierry Delisle, \smallskip \\
+\Large Peter A. Buhr, Richard Bilson, Thierry Delisle, \smallskip \\
 \Large Glen Ditchfield, Rodolfo G. Esteves, Aaron Moss, Rob Schluntz
 }% author
 …
 As stated, the goal of the \CFA project is to engineer modern language features into C in an evolutionary rather than revolutionary way.
 \CC~\cite{C++14,C++} is an example of a similar project;
+\CC~\cite{c++,ANSI14:C++} is an example of a similar project;
 however, it largely extended the language, and did not address many existing problems.\footnote{%
 Two important existing problems addressed were changing the type of character literals from ©int© to ©char© and enumerator from ©int© to the type of its enumerators.}
 …
 The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type.
 In the following example, \R{red} is for the base type and \B{blue} is for the qualifiers.
 The \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.
+The \CFA declarations move the qualifiers to the left of the base type, i.e., 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.
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 …
 \section{Pointer/Reference}
+\section{Pointer / Reference}
 C provides a \newterm{pointer type};
 \CFA adds a \newterm{reference type}.
+These types may be derived from a object or routine type, called the \newterm{referenced type}.
+Objects of these types contain an \newterm{address}, which is normally a location in memory, but may also address memory-mapped registers in hardware devices.
+An integer constant expression with the value 0, or such an expression cast to type ©void *©, is called a \newterm{null-pointer constant}.\footnote{
+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.
+Dereferencing an \newterm{unsound} address, including the null pointer, is \Index{undefined}, often resulting in a \Index{memory fault}.
+A program \newterm{object} is a region of data storage in the execution environment, the contents of which can represent values.
+In most cases, objects are located in memory at an address, and the variable name for an object is an implicit address to the object generated by the compiler and automatically dereferenced, as in:
+Both types contain an \newterm{address}, which is normally a location in memory.
+Special addresses are used to denote certain states or access co-processor memory.
+By convention, no variable is placed at address 0, so addresses like 0, 1, 2, 3 are often used to denote no-value or other special states.
+Often dereferencing a special state causes a \Index{memory fault}, so checking is necessary during execution.
+If the programming language assigns addresses, a program's execution is \Index{sound}, i.e., all addresses are to valid memory locations.
+C allows programmers to assign addresses, so there is the potential for incorrect addresses, both inside and outside of the computer address-space.
+Program variables are implicit pointers to memory locations generated by the compiler and automatically dereferenced, as in:
 \begin{quote2}
 \begin{tabular}{@{}ll@{\hspace{2em}}l@{}}
+\begin{tabular}{@{}lll@{}}
 \begin{cfa}
 int x;
 …
 \end{quote2}
 where the right example is how the compiler logically interprets the variables in the left example.
+Since a variable name only points to one address during its lifetime, it is an \Index{immutable} \Index{pointer};
+hence, the implicit type of pointer variables ©x© and ©y© are constant pointers in the compiler interpretation.
+In general, variable addresses are stored in instructions instead of loaded from memory, and hence may not occupy storage.
+These approaches are contrasted in the following:
+Since a variable name only points to one location during its lifetime, it is an \Index{immutable} \Index{pointer};
+hence, variables ©x© and ©y© are constant pointers in the compiler interpretation.
+In general, variable addresses are stored in instructions instead of loaded independently, so an instruction fetch implicitly loads a variable's address.
 \begin{quote2}
 \begin{tabular}{@{}l|l@{}}
-\multicolumn{1}{c|}{explicit variable address} & \multicolumn{1}{c}{implicit variable address} \\
-\hline
 \begin{cfa}
 lda             r1,100                  // load address of x
 ld               r2,(r1)                  // load value of x
+ld              r2,(r1)                   // load value of x
 lda             r3,104                  // load address of y
 st               r2,(r3)                  // store x into y
+st              r2,(r3)                   // store x into y
 \end{cfa}
+&
 …
 \end{tabular}
 \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.
 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.)
+Finally, the immutable nature of a variable's address and the fact that there is no storage for a variable address means pointer assignment\index{pointer!assignment}\index{assignment!pointer} is impossible.
+Therefore, the expression ©x = y© only has one meaning, ©*x = *y©, i.e., manipulate values, which is why explicitly writing the dereferences is unnecessary even though it occurs implicitly as part of instruction decoding.
+A \Index{pointer}/\Index{reference} is a generalization of a variable name, i.e., 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 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}
 \begin{tabular}{@{}l@{\hspace{2em}}l@{}}
+\begin{tabular}{@{}ll@{}}
 \begin{cfa}
 int x, y, ®*® p1, ®*® p2, ®**® p3;
 …
 \end{cfa}
+&
 \raisebox{-0.5\totalheight}{\input{pointer2.pstex_t}}
+\raisebox{-0.45\totalheight}{\input{pointer2.pstex_t}}
 \end{tabular}
 \end{quote2}
 Notice, an address has a 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
+In many cases, a compiler might be able to infer the meaning:
 \begin{cfa}
 p2 = p1 + x;                                    §\C{// compiler infers *p2 = *p1 + x;}§
 \end{cfa}
 Algol68 infers the following deferencing ©*p2 = *p1 + x©, because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
+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.
+In C, objects of pointer type always manipulate the pointer object's address:
+\begin{cfa}
+p1 = p2;                                                §\C{// p1 = p2\ \ rather than\ \ *p1 = *p2}§
+p2 = p1 + x;                                    §\C{// p2 = p1 + x\ \ rather than\ \ *p1 = *p1 + x}§
+\end{cfa}
+even though the assignment to ©p2© is likely incorrect, and the programmer probably meant:
+because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
+\Index*{Algol68}~\cite{Algol68} inferences pointer dereferencing to select the best meaning for each pointer usage.
+However, in C, the following cases are ambiguous, especially with pointer arithmetic:
+\begin{cfa}
+p1 = p2;                                                §\C{// p1 = p2\ \ or\ \ *p1 = *p2}§
+p1 = p1 + 1;                                    §\C{// p1 = p1 + 1\ \ or\ \ *p1 = *p1 + 1}§
+\end{cfa}
+Most languages pick one meaning as the default and the programmer explicitly indicates the other meaning to resolve the address-duality ambiguity\index{address! ambiguity}.
+In C, the default meaning for pointers is to manipulate the pointer's address and the pointed-to value is explicitly accessed by the dereference operator ©*©.
 \begin{cfa}
 p1 = p2;                                                §\C{// pointer address assignment}§
 ®*®p2 = ®*®p1 + x;                              §\C{// pointed-to value assignment / operation}§
 \end{cfa}
 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©).
+*p1 = *p1 + 1;                                  §\C{// pointed-to value assignment / operation}§
+\end{cfa}
+which works well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
 However, in most other situations, the pointed-to value is requested more often than the pointer address.
 …
 \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 switch the default meaning for an address requires a new kind of pointer, called a \newterm{reference} denoted by ©&©.
 \begin{cfa}
 int x, y, ®&® r1, ®&® r2, ®&&® r3;
 …
 Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example.
 Hence, a reference behaves like the variable name for the current variable it is pointing-to.
+One way to conceptualize a reference is via a rewrite rule, where the compiler inserts a dereference operator before the reference variable for each reference qualifier in a declaration, so the previous example becomes:
+The simplest way to understand a reference is to imagine the compiler inserting a dereference operator before the reference variable for each reference qualifier in a declaration, \eg:
+\begin{cfa}
+r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15);
+\end{cfa}
+is rewritten as:
 \begin{cfa}
 ®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15);
 …
 (&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address of r2, (\&(\&*)*) cancel giving variable r3}§
 \end{cfa}
+Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth.
+Fundamentally, pointer and reference objects are functionally interchangeable because both contain addresses.
+Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth, and pointer and reference values are interchangeable because both contain addresses.
 \begin{cfa}
 int x, *p1 = &x, **p2 = &p1, ***p3 = &p2,
 …
 &&&r3 = p3;                                             §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§
 \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.
+As for a pointer type, a reference type may have qualifiers:
+Finally, implicit dereferencing and cancellation are a static (compilation) phenomenon not a dynamic one.
+That is, all implicit dereferencing and any cancellation is carried out prior to the start of the program, so reference performance is equivalent to pointer performance.
+A programmer selects a pointer or reference type solely on whether the address is dereferenced frequently or infrequently, which dictates the amount of direct aid from the compiler;
+otherwise, everything else is equal.
+Interestingly, \Index*[C++]{\CC} deals with the address duality by making the pointed-to value the default, and prevent\-ing changes to the reference address, which eliminates half of the duality.
+\Index*{Java} deals with the address duality by making address assignment the default and requiring field assignment (direct or indirect via methods), i.e., there is no builtin bit-wise or method-wise assignment, which eliminates half of the duality.
+As for a pointer, a reference may have qualifiers:
 \begin{cfa}
 const int cx = 5;                               §\C{// cannot change cx;}§
 …
 ®&®cr = &cx;                                    §\C{// can change cr}§
 cr = 7;                                                 §\C{// error, cannot change cx}§
 int & const rc = x;                             §\C{// must be initialized}§
+int & const rc = x;                             §\C{// must be initialized, \CC reference}§
 ®&®rc = &x;                                             §\C{// error, cannot change rc}§
 const int & const crc = cx;             §\C{// must be initialized}§
+const int & const crc = cx;             §\C{// must be initialized, \CC reference}§
 crc = 7;                                                §\C{// error, cannot change cx}§
 ®&®crc = &cx;                                   §\C{// error, cannot change crc}§
 \end{cfa}
+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}:
+\begin{cfa}
+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:
+\begin{cfa}
+int & const cr = *malloc();
+delete &cr;
+cr = 7;                                                 §\C{// unsound pointer dereference}§
+\end{cfa}
+Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be ©0© unless an arbitrary pointer is assigned to the reference}, \eg:
+\begin{cfa}
+int & const r = *0;                             §\C{// where 0 is the int * zero}§
+\end{cfa}
+Otherwise, the compiler is managing the addresses for type ©& const© not the programmer, and by a programming discipline of only using references with references, address errors can be prevented.
 Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
 The ©const© qualifier cannot be moved before the pointer/reference qualifier for C style-declarations;
 …
 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.
 \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 * p = &x;                                   §\C{// both \&x and x are possible interpretations}§
 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.
+Hence, the compiler implicitly inserts a reference operator, ©&©, before the initialization expression.
+Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference operator.
 \begin{cfa}
 int & f( int & rp );                    §\C{// reference parameter and return}§
 …
 \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©.
 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.
+Since ©?+?© 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.
 When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions.
 …
 \end{cfa}
 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.)
+(The ©&© is necessary for the pointer 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}
 …
 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).
+While \CFA attempts to handle pointers and references in a uniform, symmetric manner, C handles routine variables in an inconsistent way: a routine variable is both a pointer and a reference (particle and wave).
 \begin{cfa}
 void f( int p ) {...}
 …
 fp(3);                                                  §\C{// reference invocation}§
 \end{cfa}
 A routine object is best described by a ©const© reference:
+A routine variable is best described by a ©const© reference:
 \begin{cfa}
 const void (&fp)( int ) = f;
 …
 &fp = ...;                                              §\C{// changing routine reference}§
 \end{cfa}
 because the value of the routine object is a routine literal, \ie the routine code is normally immutable during execution.\footnote{
+because the value of the routine variable is a routine literal, i.e., 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.
+\begin{comment}
+\section{References}
+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.
+In structures, a reference can replace a pointer to an object that should always have a valid value.
+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.
+The syntax for using references in \CFA is the same as \CC with the exception of reference initialization.
+Use ©&© to specify a reference, and access references just like regular objects, not like pointers (use dot notation to access fields).
+When initializing a reference, \CFA uses a different syntax which differentiates reference initialization from assignment to a reference.
+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.
+From: Richard Bilson <rcbilson@gmail.com>
+Date: Wed, 13 Jul 2016 01:58:58 +0000
+Subject: Re: pointers / references
+To: "Peter A. Buhr" <pabuhr@plg2.cs.uwaterloo.ca>
+As a general comment I would say that I found the section confusing, as you move back and forth
+between various real and imagined programming languages. If it were me I would rewrite into two
+subsections, one that specifies precisely the syntax and semantics of reference variables and
+another that provides the rationale.
+I don't see any obvious problems with the syntax or semantics so far as I understand them. It's not
+obvious that the description you're giving is complete, but I'm sure you'll find the special cases
+as you do the implementation.
+My big gripes are mostly that you're not being as precise as you need to be in your terminology, and
+that you say a few things that aren't actually true even though I generally know what you mean.
+C provides a pointer type; CFA adds a reference type. Both types contain an address, which is normally a
+location in memory.
+An address is not a location in memory; an address refers to a location in memory. Furthermore it
+seems weird to me to say that a type "contains" an address; rather, objects of that type do.
+Special addresses are used to denote certain states or access co-processor memory. By
+convention, no variable is placed at address 0, so addresses like 0, 1, 2, 3 are often used to denote no-value
+or other special states.
+This isn't standard C at all. There has to be one null pointer representation, but it doesn't have
+to be a literal zero representation and there doesn't have to be more than one such representation.
+Often dereferencing a special state causes a memory fault, so checking is necessary
+during execution.
+I don't see the connection between the two clauses here. I feel like if a bad pointer will not cause
+a memory fault then I need to do more checking, not less.
+If the programming language assigns addresses, a program's execution is sound, \ie all
+addresses are to valid memory locations.
+You haven't said what it means to "assign" an address, but if I use my intuitive understanding of
+the term I don't see how this can be true unless you're assuming automatic storage management.
+Program variables are implicit pointers to memory locations generated by the compiler and automatically
+dereferenced, as in:
+There is no reason why a variable needs to have a location in memory, and indeed in a typical
+program many variables will not. In standard terminology an object identifier refers to data in the
+execution environment, but not necessarily in memory.
+A pointer/reference is a generalization of a variable name, \ie a mutable address that can point to more
+than one memory location during its lifetime.
+I feel like you're off the reservation here. In my world there are objects of pointer type, which
+seem to be what you're describing here, but also pointer values, which can be stored in an object of
+pointer type but don't necessarily have to be. For example, how would you describe the value denoted
+by "&main" in a C program? I would call it a (function) pointer, but that doesn't satisfy your
+definition.
+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, e.g.:
+As with my general objection regarding your definition of variables, there is no reason why a
+pointer variable (object of pointer type) needs to occupy memory.
+p2 = p1 + x; // compiler infers *p2 = *p1 + x;
+What language are we in now?
+pointer usage. However, in C, the following cases are ambiguous, especially with pointer arithmetic:
+p1 = p2; // p1 = p2 or *p1 = *p2
+This isn't ambiguous. it's defined to be the first option.
+p1 = p1 + 1; // p1 = p1 + 1 or *p1 = *p1 + 1
+Again, this statement is not ambiguous.
+example. Hence, a reference behaves like the variable name for the current variable it is pointing-to. The
+simplest way to understand a reference is to imagine the compiler inserting a dereference operator before
+the reference variable for each reference qualifier in a declaration, e.g.:
+It's hard for me to understand who the audience for this part is. I think a practical programmer is
+likely to be satisfied with "a reference behaves like the variable name for the current variable it
+is pointing-to," maybe with some examples. Your "simplest way" doesn't strike me as simpler than
+that. It feels like you're trying to provide a more precise definition for the semantics of
+references, but it isn't actually precise enough to be a formal specification. If you want to
+express the semantics of references using rewrite rules that's a great way to do it, but lay the
+rules out clearly, and when you're showing an example of rewriting keep your
+references/pointers/values separate (right now, you use \eg "r3" to mean a reference, a pointer,
+and a value).
+Cancellation works to arbitrary depth, and pointer and reference values are interchangeable because both
+contain addresses.
+Except they're not interchangeable, because they have different and incompatible types.
+Interestingly, C++ deals with the address duality by making the pointed-to value the default, and prevent-
+ing changes to the reference address, which eliminates half of the duality. Java deals with the address duality
+by making address assignment the default and requiring field assignment (direct or indirect via methods),
+\ie there is no builtin bit-wise or method-wise assignment, which eliminates half of the duality.
+I can follow this but I think that's mostly because I already understand what you're trying to
+say. I don't think I've ever heard the term "method-wise assignment" and I don't see you defining
+it. Furthermore Java does have value assignment of basic (non-class) types, so your summary here
+feels incomplete. (If it were me I'd drop this paragraph rather than try to save it.)
+Hence, for type & const, there is no pointer assignment, so &rc = &x is disallowed, and the address value
+cannot be 0 unless an arbitrary pointer is assigned to the reference.
+Given the pains you've taken to motivate every little bit of the semantics up until now, this last
+clause ("the address value cannot be 0") comes out of the blue. It seems like you could have
+perfectly reasonable semantics that allowed the initialization of null references.
+In effect, the compiler is managing the
+addresses for type & const not the programmer, and by a programming discipline of only using references
+with references, address errors can be prevented.
+Again, is this assuming automatic storage management?
+rary binding. For reference initialization (like pointer), the initializing value must be an address (lvalue) not
+a value (rvalue).
+This sentence appears to suggest that an address and an lvalue are the same thing.
+int * p = &x; // both &x and x are possible interpretations
+Are you saying that we should be considering "x" as a possible interpretation of the initializer
+"&x"? It seems to me that this expression has only one legitimate interpretation in context.
+int & r = x; // x unlikely interpretation, because of auto-dereferencing
+You mean, we can initialize a reference using an integer value? Surely we would need some sort of
+cast to induce that interpretation, no?
+Hence, the compiler implicitly inserts a reference operator, &, before the initialization expression.
+But then the expression would have pointer type, which wouldn't be compatible with the type of r.
+Similarly,
+when a reference is used for a parameter/return type, the call-site argument does not require a reference
+operator.
+Furthermore, it would not be correct to use a reference operator.
+The implicit conversion allows
+seamless calls to any routine without having to explicitly name/copy the literal/expression to allow the call.
+While C' attempts to handle pointers and references in a uniform, symmetric manner, C handles routine
+variables in an inconsistent way: a routine variable is both a pointer and a reference (particle and wave).
+After all this talk of how expressions can have both pointer and value interpretations, you're
+disparaging C because it has expressions that have both pointer and value interpretations?
+On Sat, Jul 9, 2016 at 4:18 PM Peter A. Buhr <pabuhr@plg.uwaterloo.ca> wrote:
+> Aaron discovered a few places where "&"s are missing and where there are too many "&", which are
+> corrected in the attached updated. None of the text has changed, if you have started reading
+> already.
+\end{comment}
+\CFA allows this additional use of references for routine variables in an attempt to give a more consistent meaning for them.
 …
 because
 Currently, there are no \Index{lambda} expressions, \ie unnamed routines because routine names are very important to properly select the correct routine.
 \section{Tuples}
+Currently, there are no \Index{lambda} expressions, i.e., unnamed routines because routine names are very important to properly select the correct routine.
+\section{Lexical List}
 In C and \CFA, lists of elements appear in several contexts, such as the parameter list for a routine call.
 …
 [ v+w, x*y, 3.14159, f() ]
 \end{cfa}
 Tuples are permitted to contain sub-tuples (\ie nesting), such as ©[ [ 14, 21 ], 9 ]©, which is a 2-element tuple whose first element is itself a tuple.
+Tuples are permitted to contain sub-tuples (i.e., nesting), such as ©[ [ 14, 21 ], 9 ]©, which is a 2-element tuple whose first element is itself a tuple.
 Note, a tuple is not a record (structure);
 a record denotes a single value with substructure, whereas a tuple is multiple values with no substructure (see flattening coercion in Section 12.1).
 …
 tuple does not have structure like a record; a tuple is simply converted into a list of components.
 \begin{rationale}
 The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; \ie a statement such as ©g( f() )© is not supported.
+The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; i.e., a statement such as ©g( f() )© is not supported.
 Using a temporary variable to store the  results of the inner routine and then passing this variable to the outer routine works, however.
 \end{rationale}
 …
 This requirement is the same as for comma expressions in argument lists.
 Type qualifiers, \ie const and volatile, may modify a tuple type.
 The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], \ie the qualifier is distributed across all of the types in the tuple, \eg:
+Type qualifiers, i.e., const and volatile, may modify a tuple type.
+The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], i.e., the qualifier is distributed across all of the types in the tuple, \eg:
 \begin{cfa}
 const volatile [ int, float, const int ] x;
 …
 ©w© is implicitly opened to yield a tuple of four values, which are then assigned individually.
 A \newterm{flattening coercion} coerces a nested tuple, \ie a tuple with one or more components, which are themselves tuples, into a flattened tuple, which is a tuple whose components are not tuples, as in:
+A \newterm{flattening coercion} coerces a nested tuple, i.e., a tuple with one or more components, which are themselves tuples, into a flattened tuple, which is a tuple whose components are not tuples, as in:
 \begin{cfa}
 [ a, b, c, d ] = [ 1, [ 2, 3 ], 4 ];
 …
 \end{cfa}
 \index{lvalue}
 The left-hand side is a tuple of \emph{lvalues}, which is a list of expressions each yielding an address, \ie any data object that can appear on the left-hand side of a conventional assignment statement.
+The left-hand side is a tuple of \emph{lvalues}, which is a list of expressions each yielding an address, i.e., any data object that can appear on the left-hand side of a conventional assignment statement.
 ©$\emph{expr}$© is any standard arithmetic expression.
 Clearly, the types of the entities being assigned must be type compatible with the value of the expression.
 …
 [ x1, y1 ] = z = 0;
 \end{cfa}
 As in C, the rightmost assignment is performed first, \ie assignment parses right to left.
+As in C, the rightmost assignment is performed first, i.e., assignment parses right to left.
 …
 \section{Labelled Continue/Break}
+\section{Labelled Continue / Break}
 While C provides ©continue© and ©break© statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
 …
 With ©goto©, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
 Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting existing constructs.
 The implicit targets of the current ©continue© and ©break©, \ie the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
+The implicit targets of the current ©continue© and ©break©, i.e., the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
 …
 Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic.
 As well, the declaration of ©z© cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized.
 The key observation is that the ©switch© statement branches into control structure, \ie there are multiple entry points into its statement body.
+The key observation is that the ©switch© statement branches into control structure, i.e., there are multiple entry points into its statement body.
 \end{enumerate}
 …
 the number of ©switch© statements is small,
 \item
 most ©switch© statements are well formed (\ie no \Index*{Duff's device}),
+most ©switch© statements are well formed (i.e., no \Index*{Duff's device}),
 \item
 the ©default© clause is usually written as the last case-clause,
 …
 \item
 Eliminating default fall-through has the greatest potential for affecting existing code.
 However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, \ie a list of ©case© clauses executing common code, \eg:
+However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, i.e., a list of ©case© clauses executing common code, \eg:
 \begin{cfa}
 case 1:  case 2:  case 3: ...
 …
 The following \CC-style \Index{manipulator}s allow control over implicit seperation.
 Manipulators \Indexc{sepOn}\index{manipulator!sepOn@©sepOn©} and \Indexc{sepOff}\index{manipulator!sepOff@©sepOff©} \emph{locally} toggle printing the separator, \ie the seperator is adjusted only with respect to the next printed item.
+Manipulators \Indexc{sepOn}\index{manipulator!sepOn@©sepOn©} and \Indexc{sepOff}\index{manipulator!sepOff@©sepOff©} \emph{locally} toggle printing the separator, i.e., the seperator is adjusted only with respect to the next printed item.
 \begin{cfa}[mathescape=off,belowskip=0pt]
 sout | sepOn | 1 | 2 | 3 | sepOn | endl;        §\C{// separator at start of line}§
 …
 3
 \end{cfa}
 Manipulators \Indexc{sepDisable}\index{manipulator!sepDisable@©sepDisable©} and \Indexc{sepEnable}\index{manipulator!sepEnable@©sepEnable©} \emph{globally} toggle printing the separator, \ie the seperator is adjusted with respect to all subsequent printed items, unless locally adjusted.
+Manipulators \Indexc{sepDisable}\index{manipulator!sepDisable@©sepDisable©} and \Indexc{sepEnable}\index{manipulator!sepEnable@©sepEnable©} \emph{globally} toggle printing the separator, i.e., the seperator is adjusted with respect to all subsequent printed items, unless locally adjusted.
 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
 sout | sepDisable | 1 | 2 | 3 | endl;           §\C{// globally turn off implicit separation}§
 …
 \caption{Constructors and Destructors}
 \end{figure}
+\begin{comment}
+\section{References}
+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.
+In structures, a reference can replace a pointer to an object that should always have a valid value.
+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.
+The syntax for using references in \CFA is the same as \CC with the exception of reference initialization.
+Use ©&© to specify a reference, and access references just like regular objects, not like pointers (use dot notation to access fields).
+When initializing a reference, \CFA uses a different syntax which differentiates reference initialization from assignment to a reference.
+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.
+\end{comment}
 …
 \section{Incompatible}
 The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{C++14}.
+The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{ANSI14:C++}.
 \begin{enumerate}
 …
 Personß.ßFace pretty;                   §\C{// type defined inside}§
 \end{cfa}
 In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, \ie the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing.
+In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, i.e., the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing.
 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}.
 Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
 …
 \end{tabular}
 \end{quote2}
 For the prescribed head-files, \CFA uses header interposition to wraps these includes in an ©extern "C"©;
+For the prescribed head-files, \CFA implicitly wraps their includes in an ©extern "C"©;
 hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}).
 All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling.
 …
 \label{s:StandardLibrary}
 The \CFA standard-library wraps many existing explicitly-polymorphic C general-routines into implicitly-polymorphic versions.
+The goal of the \CFA standard-library is to wrap many of the existing C library-routines that are explicitly polymorphic into implicitly polymorphic versions.
 …
 \label{s:Math Library}
 The \CFA math-library wraps many existing explicitly-polymorphic C math-routines into implicitly-polymorphic versions.
+The goal of the \CFA math-library is to wrap many of the existing C math library-routines that are explicitly polymorphic into implicitly polymorphic versions.

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changes in doc/user/user.tex [0642216:3dafd83]

Legend:

doc/user/user.tex

Download in other formats: