Changeset 06ffa95 for doc/theses/mike_brooks_MMath/string.tex

Timestamp:

Mar 14, 2025, 7:15:01 PM (7 months ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

master

Children:

8617ee90

Parents:

7611631

Message:

change shareEdit to share and proofreading of string chapter

File:

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

doc/theses/mike_brooks_MMath/string.tex ¶

@@ -9 +9 @@
 
 To prepare for the following discussion, comparisons among C, \CC, Java and \CFA strings are presented, beginning in \VRef[Figure]{f:StrApiCompare}.
-It provides a classic ``cheat sheet'' presentation, summarizing the names of the most common closely-equivalent operations.
+It provides a classic ``cheat sheet'' presentation, summarizing the names of the most-common closely-equivalent operations.
 The over-arching commonality is that operations work on groups of characters for assigning, copying, scanning, and updating.
 
@@ -39 +39 @@
 hence, most of its group operations are error prone and expensive.
 Most high-level string libraries use a separate length field and specialized storage management to implement group operations.
-Interestingly, \CC strings retain null termination just in case it is needed to interface with C library functions.
+Interestingly, \CC strings retain null termination in case it is needed to interface with C library functions.
 \begin{cfa}
 int open( @const char * pathname@, int flags );
@@ -52 +52 @@
 While \VRef[Figure]{f:StrApiCompare} emphasizes cross-language similarities, it elides many specific operational differences.
 For example, the @replace@ function selects a substring in the target and substitutes it with the source string, which can be smaller or larger than the substring.
-\CC performs the modification on the mutable receiver object.
+\CC performs the modification on the mutable receiver object
 \begin{cfa}
 string s1 = "abcde";
@@ -60 +60 @@
 \end{cfa}
 while Java allocates and returns a new string with the result, leaving the receiver unmodified.
+\label{p:JavaReplace}
 \begin{java}
 String s = "abcde";
 String r = s.replace( "cde", "xy" );  $\C[2.25in]{// replace by text, immutable}$
+System.out.println( s + ' ' + r );
+$\texttt{abcde abxy}$
+\end{java}
+% Generally, Java's @String@ type is immutable.
+Java provides a @StringBuffer@ near-analog that is mutable.
+\begin{java}
 StringBuffer sb = new StringBuffer( "abcde" );
-sb.replace( 2, 5, "xy" );  $\C{// replace by position, mutable}\CRT$
-System.out.println( s + ' ' + r + ' ' + sb );
-$\texttt{abcde abxy abxy}$
+sb.replace( 2, 5, "xy" );  $\C[2.25in]{// replace by position, mutable}\CRT$
+System.out.println( sb );
+$\texttt{abxy}$
 \end{java}
-Generally, Java's @String@ type is immutable.
-Java provides a @StringBuffer@ near-analog that is mutable, but the differences are significant; for example, @StringBuffer@'s @substring@ functions still return copies rather than mutable selections.
-Finally, the operations between these type are asymmetric, \eg @string@ has @replace@ by text but not replace by position and vice versa for @StringBuffer@.
+However, there are significant differences;
+\eg, @StringBuffer@'s @substring@ function returns a @String@ copy that is immutable.
+Finally, the operations between these type are asymmetric, \eg @String@ has @replace@ by text but not replace by position and vice versa for @StringBuffer@.
 
 More significant operational differences relate to storage management, often appearing through assignment (@target = source@), and are summarized in \VRef[Figure]{f:StrSemanticCompare}.
@@ -140 +147 @@
 $\texttt{\small abcde abcde abcde bcde cde}$
 \end{cfa}
-Note, all of these strings rely on the single null termination character at the end of @s@.
+Note, all of these aliased strings rely on the single null termination character at the end of @s@.
 The issue of symmetry does not apply to C strings because the value and pointer strings are essentially different types, and so this feature is scored as not applicable for C.
-With the type not managing the text buffer, there is no ownership question, \ie operations on @s1@ or @s2@ never leads to their memory becoming reusable.
+With the type not managing the text storage, there is no ownership question, \ie operations on @s1@ or @s2@ never leads to their memory becoming reusable.
 While @s3@ is a valid C-string that contains a proper substring of @s1@, the @s3@ technique does not constitute having a fragment referent because null termination implies the substring cannot be chosen arbitrarily; the technique works only for suffixes.
 
@@ -157 +164 @@
 \end{cfa}
 The lax symmetry reflects how the validity of @s1@ depends on the content and lifetime of @s@.
-It is common practice in \CC to use the @s1@-style pass by reference, with the understanding that the callee only use the referenced string for the duration of the call, \ie no side-effect using the parameter.
-So, when the called function is a constructor, it is typical to use an @s2@-style copy initialization to string-object-typed member.
+It is common practice in \CC to use the @s1@-style pass by reference, with the understanding that the callee only uses the referenced string for the duration of the call, \ie no side-effect using the parameter.
+So, when the called function is a constructor, it is typical to use an @s2@-style copy-initialization to string-object-typed member.
 Exceptions to this pattern are possible, but require the programmer to assure safety where the type system does not.
-The @s3@ initialization is constrained to copy the substring because @c_str@ always provides a null-terminated character, which is different from source string.
+The @s3@ initialization is constrained to copy the substring because @c_str@ always provides a null-terminated character, which may be different from the source string.
 @s3@ assignment could be fast by reference counting the text area and using copy-on-write, but would require an implementation upgrade.
 
 In Java, @String@ also offers a high-level abstraction:
-\begin{cfa}
+\begin{java}
 String s = "abcde";
 String s1 = s;  $\C[2.25in]{// snapshot state, strict symmetry, variable-constrained referent}$
@@ -173 +180 @@
 $\texttt{\small abcde abcde bc c}$
 $\texttt{\small true false false}$
-\end{cfa}
+\end{java}
 Note, @substring@ takes a start and end position, rather than a start position and length.
 Here, facts about Java's implicit pointers and pointer equality can over complicate the picture, and so are ignored.
@@ -180 +187 @@
 With @s2@, the case for fast-copy is more subtle.
 Certainly, its value is not pointer-equal to @s@, implying at least a further allocation.
-TODO: finish the fast-copy case.
-Java's immutable strings mean aliasing is impossible with the @String@ type.
-Java's @StringBuffer@ provides aliasing, though without supporting symmetric treatment of a fragment referent; as a result, @StringBuffer@ scores as \CC.
-The easy symmetry that the Java string enjoys is aided by Java's garbage collection; Java's @s2@ is doing effectively the operation of \CC's @s2@, though without the consequence to of complicating memory management.
-
-Finally, In \CFA, @string@ also offers a high-level abstraction:
+\PAB{TODO: finish the fast-copy case.}
+Java does not meet the aliasing requirement because immutability make it impossible to modify.
+Java's @StringBuffer@ provides aliasing (see @replace@ example on \VPageref{p:JavaReplace}), though without supporting symmetric treatment of a fragment referent, \eg @substring@ of a @StringBuffer@ is a @String@;
+as a result, @StringBuffer@ scores as \CC.
+The easy symmetry that the Java string enjoys is aided by Java's garbage collection; Java's @s2@ is doing effectively the operation of \CC's @s3@, though without the consequence of complicating memory management.
+\PAB{What complex storage management is going on here?}
+
+Finally, in \CFA, @string@ also offers a high-level abstraction:
 \begin{cfa}
 string s = "abcde";
 string & s1 = s; $\C[2.25in]{// alias state, strict symmetry, variable-constrained referent}$
 string s2 = s; $\C{// snapshot state, strict symmetry, variable-constrained referent}$
-string s3 = s`shareEdits; $\C{// alias state, strict symmetry, variable-constrained referent}\CRT$
+string s3 = s`share; $\C{// alias state, strict symmetry, variable-constrained referent}\CRT$
 string s4 = s( 1, 2 );
 string s5 = s4( 1, 1 );
@@ -198 +207 @@
 % all helpful criteria of \VRef[Figure]{f:StrSemanticCompare} are satisfied.
 The \CFA string manages storage, handles all assignments, including those of fragment referents with fast initialization, provides the choice between snapshot and alias semantics, and does so symmetrically with one type (which assures text validity according to the lifecycles of the string variables).
-With aliasing, the intuition is that each string is an editor on an open shared document.
-With fragment aliasing, the intuition is that these editor views have been scrolled or zoomed to overlapping, but potentially different, ranges.
+The intended metaphor for \CFA stings is similar to a GUI text-editor or web browser.
+Select a consecutive block of text using the mouse generates an aliased substring in the file/dialog-box.
+Typing into the selected area is like assigning to an aliased substring, where the highlighted text is replaced with more or less text;
+depending on the text entered, the file/dialog-box content grows or shrinks.
+\PAB{Need to discuss the example, as for the other languages.}
 
 The remainder of this chapter explains how the \CFA string achieves this usage style.
 
 
-
 \section{Storage Management}
 
 This section discusses issues related to storage management of strings.
-Specifically, it is common for strings to logically overlap completely or partially.
+Specifically, it is common for strings to logically overlap partially or completely.
 \begin{cfa}
 string s1 = "abcdef";
@@ -218 +229 @@
 s3[1] = 'w'; $\C{// what happens to s1 and s2?}$
 \end{cfa}
-This question is the notion of mutable or immutable strings.
-For example, Java has immutable strings that are copied when any overlapping string changes.
-Note, the notion of underlying string mutability is not specified by @const@, \eg:
+which is restricted by a string's mutable or immutable property.
+For example, Java's immutable strings require copy-on-write when any overlapping string changes.
+Note, the notion of underlying string mutability is not specified by @const@; \eg in \CC:
 \begin{cfa}
 const string s1 = "abc";
 \end{cfa}
-Here, @const@ applies to the @s1@ pointer to @"abc"@, and @"abc"@ is an immutable constant that is \emph{copied} into the string's storage.
-Hence, @s1@ is not pointing at an immutable constant, meaning its underlying string is always mutable, unless some other designation is specified, such as Java's global rule.
+the @const@ applies to the @s1@ pointer to @"abc"@, and @"abc"@ is an immutable constant that is \emph{copied} into the string's storage.
+Hence, @s1@ is not pointing at an immutable constant, meaning its underlying string can be mutable, unless some other designation is specified, such as Java's global immutable rule.
 
 
 \subsection{Logical overlap}
 
-\CFA provides a dynamic mechanism to indicate mutable or immutable as an assignment attribute: @`shareEdits@.
-
-Consider two strings @s1@ and @s1a@ that are in an aliasing relationship, and a third, @s2@, made by a simple copy from @s1@.
-Aliasing (@`shareEdits@) means that changes flow in both directions; with a simple copy, they do not.
+\CFA provides a dynamic mechanism to indicate mutable or immutable using the attribute @`share@.
+This aliasing relationship is a sticky-property established at initialization.
+For example, here strings @s1@ and @s1a@ are in an aliasing relationship, while @s2@ is in a copy relationship.
 \input{sharing1.tex}
-
-Aliasing (@`shareEdits@) means that changes flow in both directions; with a simple copy, they do not.
+Here, the aliasing (@`share@) causes partial changes (subscripting) to flow in both directions.
 \input{sharing2.tex}
-
-Assignment of a value is just a modification.
-The aliasing relationship is established at construction and is unaffected by assignment of a value.
+Similarly for complete changes.
 \input{sharing3.tex}
 
-Assignment from a string is just assignment of a value.
-Whether of not the RHS participates in aliasing is irrelevant.  Any aliasing of the LHS is unaffected.
+Because string assignment copies the value, RHS aliasing is irrelevant.
+Hence, aliasing of the LHS is unaffected.
 \input{sharing4.tex}
 
-Consider new strings @s1_mid@ being an alias for a run in the middle of @s1@, along with @s2@, made by a simple copy from the middle of @s1@.
+Now, consider string @s1_mid@ being an alias in the middle of @s1@, along with @s2@, made by a simple copy from the middle of @s1@.
 \input{sharing5.tex}
-
-Again, @`shareEdits@ passes changes in both directions; copy does not.
-Note the difference in index values, with the \emph{b} position being 1 in the longer string and 0 in the shorter strings.
-In the case of s1 aliasing with @s1_mid@, the very same character is being accessed by different positions.
+Again, @`share@ passes changes in both directions; copy does not.
+As a result, the index values for the position of @b@ are 1 in the longer string @"abcd"@ and 0 in the shorter aliased string @"bc"@.
+This alternate positioning also applies to subscripting.
 \input{sharing6.tex}
 
-Once again, assignment of a value is a modification that flows through the aliasing relationship, without affecting its structure.
+Finally, assignment flows through the aliasing relationship without affecting its structure.
 \input{sharing7.tex}
-
-In the \emph{ff} step, which is a positive example of flow across an aliasing relationship, the result is straightforward to accept because the flow direction is from contained (small) to containing (large).
-The following rules for edits through aliasing substrings will guide how to flow in the opposite direction.
-
-Growth and shrinkage are natural extensions.
-An empty substring is a real thing, at a well-defined location, whose meaning is extrapolated from the examples so far.
-The intended metaphor is to operating a GUI text editor.
-Having an aliasing substring is like using the mouse to select a few words.
-Assigning onto an aliasing substring is like typing from having a few words selected: depending how much you type, the file being edited can get shorter or longer.
+In the @"ff"@ assignment, the result is straightforward to accept because the flow direction is from contained (small) to containing (large).
+The following rules explain aliasing substrings that flow in the opposite direction, large to small.
+
+Growth and shrinkage are natural extensions, as for the text-editor example mentioned earlier, where an empty substring is as real real as an empty string.
 \input{sharing8.tex}
 
-Multiple portions can be aliased.
-When there are several aliasing substrings at once, the text editor analogy becomes an online multi-user editor.
-I should be able to edit a paragraph in one place (changing the document's length), without my edits affecting which letters are within a mouse-selection that you had made previously, somewhere else.
+Multiple portions of a string can be aliased.
+% When there are several aliasing substrings at once, the text editor analogy becomes an online multi-user editor.
+%I should be able to edit a paragraph in one place (changing the document's length), without my edits affecting which letters are within a mouse-selection that you had made previously, somewhere else.
 \input{sharing9.tex}
-
-When an edit happens on an aliasing substring that overlaps another, an effect is unavoidable.
-Here, the passive party sees its selection shortened, to exclude the characters that were not part of the original selection.
+When @s1_bgn@'s size increases by 3, @s1_mid@'s starting location moves from 1 to 4 and @s1_end@'s from 3 to 6,
+
+When changes happens on an aliasing substring that overlap.
 \input{sharing10.tex}
-
-TODO: finish typesetting the demo
+Strings @s1_crs@ and @s1_mid@ overlap at character 4, @j@ because the substrings are 3,2 and 4,2.
+When @s1_crs@'s size increases by 1, @s1_mid@'s starting location moves from 4 to 5, but the overlaping character remains, changing to @'+'@.
+
+\PAB{TODO: finish typesetting the demo}
 
 %\input{sharing-demo.tex}