Changeset b195498 for doc/theses/mike_brooks_MMath/intro.tex

Timestamp:

Apr 24, 2025, 6:35:41 PM (8 months ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

master

Children:

6b33e89, f85de47

Parents:

f632bd50

Message:

proofreading intro and background chapters, capitalize section titles, update backtick calls to regular calls

File:

• doc/theses/mike_brooks_MMath/intro.tex (modified) (10 diffs)

doc/theses/mike_brooks_MMath/intro.tex

@@ -27 +27 @@
 
 
-\section{Linked list}
+\section{Linked List}
 
 A linked-list provides a homogeneous container often with $O(log N)$ or $O(N)$ access to elements using successor and predecessor operations that normally involve pointer chasing.
@@ -42 +42 @@
 hash search table consisting of a key (string) with associated data (@<search.h>@)
 \end{itemize}
-Because these libraries are simple, awkward to use, and unsafe, C programmers commonly build linked-list behaviours into their bespoke data structures.
+Because these libraries are simple, awkward to use, and unsafe, C programmers commonly build bespoke linked data-structures.
 
 
@@ -54 +54 @@
 In some cases, string management is separate from heap management, \ie strings roll their own heap.
 
-The C string type requires user storage-management of a language-provided character array.
+The C string type is just a character array and requires user storage-management to handle varying size.
 The character array uses the convention of marking its (variable) array length by placing the 0-valued control character at the end (null-terminated).
 The C standard library includes a number of high-level operations for working with this representation.
+Most of these operations are awkward and error prone.
 
 
@@ -84 +85 @@
 While multiple new languages purport to be systems languages replacing C, the reality is that rewriting massive C code-bases is impractical and a non-starter if the new runtime uses garage collection.
 Furthermore, new languages must still interact with the underlying C operating system through fragile, type-unsafe, interlanguage-communication.
-Switching to \CC is equally impractical as its complex and interdependent type-system (\eg objects, overloading, inheritance, templates) means idiomatic \CC code is difficult to use from C, and C programmers must expend significant effort learning \CC.
+Switching to \CC is equally impractical as its complex and interdependent type-system (\eg objects, overloading, inheritance, templates) means idiomatic \CC code is difficult to use from C, and C programmers must expend significant effort learning new \CC.
 Hence, rewriting and retraining costs for these languages can be prohibitive for companies with a large C software-base (Google, Apple, Microsoft, Amazon, AMD, Nvidia).
 
@@ -93 +94 @@
 However, most programming languages are only partially explained by their standard's manual(s).
 When it comes to explaining how C works, the definitive source is the @gcc@ compiler, which is mimicked by other C compilers, such as Clang~\cite{clang}.
-Often other C compilers must mimic @gcc@ because a large part of the C library (runtime) system (@glibc@ on Linux) contains @gcc@ features.
+Often other C compilers \emph{must} mimic @gcc@ because a large part of the C library (runtime) system (@glibc@ on Linux) contains @gcc@ features.
 Some key aspects of C need to be explained and understood by quoting from the language reference manual.
 However, to illustrate actual program semantics, this thesis constructs multiple small programs whose behaviour exercises a particular point and then confirms the behaviour by running the program using multiple @gcc@ compilers.
@@ -100 +101 @@
         \item if the compiler accepts or rejects certain syntax,
         \item prints output to buttress a behavioural claim,
-        \item or executes without triggering any embedded assertions testing pre/post-assertions or invariants.
+        \item or fails to trigger embedded assertions testing pre/post-assertions or invariants.
 \end{itemize}
 These programs are tested across @gcc@ versions 8--14 and clang versions 10--14 running on ARM, AMD, and Intel architectures.
@@ -120 +121 @@
 Introduce a small number of subtle changes to the typing rules for the C array, while still achieving significant backwards compatibility
 \item
-Create a new polymorphic mechanism into the \CFA @forall@ clause for specifying array dimension values, similar to a fixed-typed parameter in a \CC \lstinline[language=C++]{template}.
+Create a new polymorphic mechanism in the \CFA @forall@ clause to specify array dimension values, similar to a fixed-typed parameter in a \CC \lstinline[language=C++]{template}.
 \item
 Construct a new standard-library array-type, available through @#include <array.hfa>@.
@@ -130 +131 @@
 
 
-\subsection{Linked list}
+\subsection{Linked List}
 
 The linked list is a new runtime library, available through @#include <dlist.hfa>@.
@@ -141 +142 @@
 \subsection{String}
 
-The string is a new runtime library, available through @#include <string.hfa>@.
+The new string type and its runtime library are available through @#include <string.hfa>@.
 The library offers a type where basic usage is comparable to the \CC @string@ type, including analogous coexistence with raw-character pointers.
 Its implementation, however, follows different principles, enabling programs to work with strings by value, without incurring excessive copying.
 Mutability is retained.
 Substrings are supported, including the ability for overlapping ranges to share edits transparently.
-Ultimately, the implementation is a set of strings rolled into their own specialized heap.
+The implementation allows a set of strings to use an optimized, shared, custom heap or to use the regular heap for thread safety.
 
-The string library includes writing and reading strings via the preexisting \CFA I/O stream library.
-Enabling transparent reading (of unknown length into a managed allocation) included revision of the stream library's existing handling of character arrays.
-All reasonable stream manipulators are supported, \eg width, justification (left/right), printing characters as their numeric values, and complex input scanning to isolate strings.
+The string library includes reading and writing strings via the preexisting \CFA I/O stream library.
+Enabling transparent reading of unknown length strings using managed allocation required revision of the stream library's existing handling of character arrays.
+All reasonable stream manipulators are supported, \eg width, justification (left/right), printing characters as their numeric values, and complex input scanning to isolate strings in the input stream.
 
 
@@ -159 +160 @@
 Hence, the infamous \CC bug of iterator invalidation, where structural changes cause legitimate operations to fail, \eg iterator over a list and deleting each element.
 
-Further design provides a home for Liskov-style iterators in \CFA.
+Further design provides a home for Liskov-style iterators (stackless-coroutine) in \CFA.
 This design extends a preexisting proposal to adapt the \CFA (fixed) for-each loop to be more user-pluggable, and builds upon preexisting \CFA coroutines.
 Overall, it simplifies the work a programmer must do to leverage the suspended-state abstraction during iteration.