Changes in doc/rob_thesis/intro.tex [f92aa32:0eb18557]

File:

• doc/rob_thesis/intro.tex (modified) (21 diffs)

doc/rob_thesis/intro.tex

@@ -16 +16 @@
 Therefore, these design principles must be kept in mind throughout the design and development of new language features.
 In order to appeal to existing C programmers, great care must be taken to ensure that new features naturally feel like C.
+These goals ensure existing C code-bases can be converted to \CFA incrementally with minimal effort, and C programmers can productively generate \CFA code without training beyond the features being used.
+Unfortunately, \CC is actively diverging from C, so incremental additions require significant effort and training, coupled with multiple legacy design-choices that cannot be updated.
+
 The remainder of this section describes some of the important new features that currently exist in \CFA, to give the reader the necessary context in which the new features presented in this thesis must dovetail.
 
@@ -53 +56 @@
 \end{cfacode}
 Compound literals create an unnamed object, and result in an lvalue, so it is legal to assign a value into a compound literal or to take its address \cite[p.~86]{C11}.
-Syntactically, compound literals look like a cast operator followed by a brace-enclosed initializer, but semantically are different from a C cast, which only applies basic conversions and is never an lvalue.
+Syntactically, compound literals look like a cast operator followed by a brace-enclosed initializer, but semantically are different from a C cast, which only applies basic conversions and coercions and is never an lvalue.
 
 \subsection{Overloading}
@@ -59 +62 @@
 Overloading is the ability to specify multiple entities with the same name.
 The most common form of overloading is function overloading, wherein multiple functions can be defined with the same name, but with different signatures.
-Like in \CC, \CFA allows overloading based both on the number of parameters and on the types of parameters.
+C provides a small amount of built-in overloading, \eg + is overloaded for the basic types.
+Like in \CC, \CFA allows user-defined overloading based both on the number of parameters and on the types of parameters.
   \begin{cfacode}
   void f(void);  // (1)
@@ -92 +96 @@
 There are times when a function should logically return multiple values.
 Since a function in standard C can only return a single value, a programmer must either take in additional return values by address, or the function's designer must create a wrapper structure to package multiple return-values.
+For example, the first approach:
 \begin{cfacode}
 int f(int * ret) {        // returns a value through parameter ret
@@ -101 +106 @@
 int res1 = g(&res2);      // explicitly pass storage
 \end{cfacode}
-The former solution is awkward because it requires the caller to explicitly allocate memory for $n$ result variables, even if they are only temporary values used as a subexpression, or even not used at all.
-The latter approach:
+is awkward because it requires the caller to explicitly allocate memory for $n$ result variables, even if they are only temporary values used as a subexpression, or even not used at all.
+The second approach:
 \begin{cfacode}
 struct A {
@@ -113 +118 @@
 ... res3.x ... res3.y ... // use result values
 \end{cfacode}
-requires the caller to either learn the field names of the structure or learn the names of helper routines to access the individual return values.
-Both solutions are syntactically unnatural.
+is awkward because the caller has to either learn the field names of the structure or learn the names of helper routines to access the individual return values.
+Both approaches are syntactically unnatural.
 
 In \CFA, it is possible to directly declare a function returning multiple values.
@@ -165 +170 @@
   \begin{cfacode}
   struct A { int i; };
-  int ?+?(A x, A y);
+  int ?+?(A x, A y);    // '?'s represent operands
   bool ?<?(A x, A y);
   \end{cfacode}
 Notably, the only difference is syntax.
 Most of the operators supported by \CC for operator overloading are also supported in \CFA.
-Of notable exception are the logical operators (e.g. @||@), the sequence operator (i.e. @,@), and the member-access operators (e.g. @.@ and \lstinline{->}).
+Of notable exception are the logical operators (\eg @||@), the sequence operator (\ie @,@), and the member-access operators (\eg @.@ and \lstinline{->}).
 
 Finally, \CFA also permits overloading variable identifiers.
@@ -243 +248 @@
   template<typename T>
   T sum(T *arr, int n) {
-    T t;
+    T t;  // default construct => 0
     for (; n > 0; n--) t += arr[n-1];
     return t;
@@ -261 +266 @@
   \end{cfacode}
 The first thing to note here is that immediately following the declaration of @otype T@ is a list of \emph{type assertions} that specify restrictions on acceptable choices of @T@.
-In particular, the assertions above specify that there must be a an assignment from \zero to @T@ and an addition assignment operator from @T@ to @T@.
+In particular, the assertions above specify that there must be an assignment from \zero to @T@ and an addition assignment operator from @T@ to @T@.
 The existence of an assignment operator from @T@ to @T@ and the ability to create an object of type @T@ are assumed implicitly by declaring @T@ with the @otype@ type-class.
 In addition to @otype@, there are currently two other type-classes.
@@ -281 +286 @@
 A major difference between the approaches of \CC and \CFA to polymorphism is that the set of assumed properties for a type is \emph{explicit} in \CFA.
 One of the major limiting factors of \CC's approach is that templates cannot be separately compiled.
-In contrast, the explicit nature of assertions allows \CFA's polymorphic functions to be separately compiled.
+In contrast, the explicit nature of assertions allows \CFA's polymorphic functions to be separately compiled, as the function prototype states all necessary requirements separate from the implementation.
+For example, the prototype for the previous sum function is
+  \begin{cfacode}
+  forall(otype T | **R**{ T ?=?(T *, zero_t); T ?+=?(T *, T); }**R**)
+  T sum(T *arr, int n);
+  \end{cfacode}
+With this prototype, a caller in another translation unit knows all of the constraints on @T@, and thus knows all of the operations that need to be made available to @sum@.
 
 In \CFA, a set of assertions can be factored into a \emph{trait}.
@@ -296 +307 @@
 This capability allows specifying the same set of assertions in multiple locations, without the repetition and likelihood of mistakes that come with manually writing them out for each function declaration.
 
-An interesting application of return-type resolution and polymorphism is with type-safe @malloc@.
+An interesting application of return-type resolution and polymorphism is a type-safe version of @malloc@.
 \begin{cfacode}
 forall(dtype T | sized(T))
@@ -316 +327 @@
 
 In object-oriented programming languages, type invariants are typically established in a constructor and maintained throughout the object's lifetime.
-These assertions are typically achieved through a combination of access control modifiers and a restricted interface.
+These assertions are typically achieved through a combination of access-control modifiers and a restricted interface.
 Typically, data which requires the maintenance of an invariant is hidden from external sources using the \emph{private} modifier, which restricts reads and writes to a select set of trusted routines, including member functions.
 It is these trusted routines that perform all modifications to internal data in a way that is consistent with the invariant, by ensuring that the invariant holds true at the end of the routine call.
@@ -388 +399 @@
 In other languages, a hybrid situation exists where resources escape the allocation block, but ownership is precisely controlled by the language.
 This pattern requires a strict interface and protocol for a data structure, consisting of a pre-initialization and a post-termination call, and all intervening access is done via interface routines.
-This kind of encapsulation is popular in object-oriented programming languages, and like the stack, it takes care of a significant portion of resource management cases.
+This kind of encapsulation is popular in object-oriented programming languages, and like the stack, it takes care of a significant portion of resource-management cases.
 
 For example, \CC directly supports this pattern through class types and an idiom known as RAII \footnote{Resource Acquisition is Initialization} by means of constructors and destructors.
@@ -399 +410 @@
 In the context of \CFA, a non-trivial constructor is either a user defined constructor or an auto-generated constructor that calls a non-trivial constructor.
 
-For the remaining resource ownership cases, programmer must follow a brittle, explicit protocol for freeing resources or an implicit protocol implemented via the programming language.
+For the remaining resource ownership cases, a programmer must follow a brittle, explicit protocol for freeing resources or an implicit protocol enforced by the programming language.
 
 In garbage collected languages, such as Java, resources are largely managed by the garbage collector.
-Still, garbage collectors are typically focus only on memory management.
+Still, garbage collectors typically focus only on memory management.
 There are many kinds of resources that the garbage collector does not understand, such as sockets, open files, and database connections.
 In particular, Java supports \emph{finalizers}, which are similar to destructors.
-Sadly, finalizers are only guaranteed to be called before an object is reclaimed by the garbage collector \cite[p.~373]{Java8}, which may not happen if memory use is not contentious.
+Unfortunately, finalizers are only guaranteed to be called before an object is reclaimed by the garbage collector \cite[p.~373]{Java8}, which may not happen if memory use is not contentious.
 Due to operating-system resource-limits, this is unacceptable for many long running programs.
 Instead, the paradigm in Java requires programmers to manually keep track of all resources \emph{except} memory, leading many novices and experts alike to forget to close files, etc.
@@ -450 +461 @@
 \end{javacode}
 Variables declared as part of a try-with-resources statement must conform to the @AutoClosable@ interface, and the compiler implicitly calls @close@ on each of the variables at the end of the block.
-Depending on when the exception is raised, both @out@ and @log@ are null, @log@ is null, or both are non-null, therefore, the cleanup for these variables at the end is appropriately guarded and conditionally executed to prevent null-pointer exceptions.
+Depending on when the exception is raised, both @out@ and @log@ are null, @log@ is null, or both are non-null, therefore, the cleanup for these variables at the end is automatically guarded and conditionally executed to prevent null-pointer exceptions.
 
 While Rust \cite{Rust} does not enforce the use of a garbage collector, it does provide a manual memory management environment, with a strict ownership model that automatically frees allocated memory and prevents common memory management errors.
@@ -486 +497 @@
 There is no runtime cost imposed on these restrictions, since they are enforced at compile-time.
 
-Rust provides RAII through the @Drop@ trait, allowing arbitrary code to execute when the object goes out of scope, allowing Rust programs to automatically clean up auxiliary resources much like a \CC program.
+Rust provides RAII through the @Drop@ trait, allowing arbitrary code to execute when the object goes out of scope, providing automatic clean up of auxiliary resources, much like a \CC program.
 \begin{rustcode}
 struct S {
@@ -493 +504 @@
 
 impl Drop for S {  // RAII for S
-  fn drop(&mut self) {
+  fn drop(&mut self) {  // destructor
     println!("dropped {}", self.name);
   }
@@ -558 +569 @@
 tuple<int, int, int> triple(10, 20, 30);
 auto & [t1, t2, t3] = triple;
-t2 = 0; // changes triple
+t2 = 0; // changes middle element of triple
 
 struct S { int x; double y; };
@@ -564 +575 @@
 auto [x, y] = s; // unpack s
 \end{cppcode}
-Structured bindings allow unpacking any struct with all public non-static data members into fresh local variables.
+Structured bindings allow unpacking any structure with all public non-static data members into fresh local variables.
 The use of @&@ allows declaring new variables as references, which is something that cannot be done with @std::tie@, since \CC references do not support rebinding.
 This extension requires the use of @auto@ to infer the types of the new variables, so complicated expressions with a non-obvious type must be documented with some other mechanism.
 Furthermore, structured bindings are not a full replacement for @std::tie@, as it always declares new variables.
 
-Like \CC, D provides tuples through a library variadic template struct.
+Like \CC, D provides tuples through a library variadic-template structure.
 In D, it is possible to name the fields of a tuple type, which creates a distinct type.
 % http://dlang.org/phobos/std_typecons.html
@@ -600 +611 @@
 \end{smlcode}
 Here, the function @binco@ appears to take 2 arguments, but it actually takes a single argument which is implicitly decomposed via pattern matching.
-Tuples are a foundational tool in SML, allowing the creation of arbitrarily complex structured data types.
+Tuples are a foundational tool in SML, allowing the creation of arbitrarily-complex structured data-types.
 
 Scala, like \CC, provides tuple types through the standard library \cite{Scala}.
@@ -653 +664 @@
 Since the variadic arguments are untyped, it is up to the function to interpret any data that is passed in.
 Additionally, the interface to manipulate @va_list@ objects is essentially limited to advancing to the next argument, without any built-in facility to determine when the last argument is read.
-This requires the use of an \emph{argument descriptor} to pass information to the function about the structure of the argument list, including the number of arguments and their types.
+This limitation requires the use of an \emph{argument descriptor} to pass information to the function about the structure of the argument list, including the number of arguments and their types.
 The format string in @printf@ is one such example of an argument descriptor.
 \begin{cfacode}