Context Navigation

-              rb0296dba
+              rd9aee90
 \vspace*{-20pt}
 This chapter presents my work on designing and building a modern string type in \CFA.
 The discussion starts with an overview of string API, then a number of interesting string problems, followed by how these issues are resolved in this work.
+The discussion starts with an overview of the string API, then a number of interesting string problems, followed by how these issues are resolved in this work.
 …
 The ability to convert from internal (machine) to external (human) format is useful in situations other than I/O.
 Hence, the basic types @char@, @char *@, @int@, @double@, @_Complex@, including any signness and size variations, implicitly convert to type @string@.
+Hence, the basic types @char@, @char *@, @int@, @double@, @_Complex@, including any signness and size variations, implicitly convert to type @string@ (as in Java).
 \begin{cquote}
 \setlength{\tabcolsep}{15pt}
 …
 In C, these operators compare the C string pointer not its value, which does not match programmer expectation.
 C strings use function @strcmp@ to lexicographically compare the string value.
+Java has the same issue with @==@ and @.equals@.
 …
 cs + 'a';  $\C{// move pointer cs['a']}\CRT$
 \end{cfa}
 There is a legitimate use case for arithmetic with @signed@/@unsigned@ characters (bytes), but these types are treated differently from @char@ in \CC and \CFA.
 However, backwards compatibility makes is impossible to restrict or remove addition on type @char@.
+There are legitimate use cases for arithmetic with @signed@/@unsigned@ characters (bytes), and these types are treated differently from @char@ in \CC and \CFA.
+However, backwards compatibility makes it impossible to restrict or remove addition on type @char@.
 Similarly, it is impossible to restrict or remove addition on type @char *@ because (unfortunately) it is subscripting: @cs + 'a'@ implies @cs['a']@ or @'a'[cs]@.
 Fortunately, the prior concatenation examples show complex mixed-mode interactions among @char@, @char *@, and @string@ (variables are the same as constants) work correctly.
+The prior \CFA concatenation examples show complex mixed-mode interactions among @char@, @char *@, and @string@ (variables are the same as constants) work correctly.
 The reason is that the \CFA type-system handles this kind of overloading well using the left-hand assignment-type and complex conversion costs.
 Hence, the type system correctly handles all uses of addition (explicit or implicit) for @char *@.
 …
 The ascription cast, @(return T)@, disambiguates by stating a (LHS) type to use during expression resolution (not a conversion).
 Fortunately, character addition without LHS information is rare in C/\CFA programs, so repurposing the operator @+@ for @string@ types is not a problem.
 Note, other programming languages that repurpose @+@ for concatenation, could have a similar ambiguity issue.
+Note, other programming languages that repurpose @+@ for concatenation, could have similar ambiguity issues.
 Interestingly, \CC cannot support this generality because it does not use the left-hand side of assignment in expression resolution.
 …
 \end{cquote}
 A character-class operation indicate if a string is composed completely of a particular class of characters, \eg, alphabetic, numeric, vowels, \etc.
+A character-class operation indicates if a string is composed completely of a particular class of characters, \eg, alphabetic, numeric, vowels, \etc.
 \begin{cquote}
 \setlength{\tabcolsep}{15pt}
 …
 \end{cquote}
 There are versions of @include@ and @exclude@, returning a position or string, taking a validation function, like one of the C character-class routines.\footnote{It is part of the hereditary of C that these function take and return an \lstinline{int} rather than a \lstinline{char}, which affects the function type.}
+There are also versions of @include@ and @exclude@, returning a position or string, taking a validation function, like one of the C character-class routines.\footnote{It is part of the hereditary of C that these function take and return an \lstinline{int} rather than a \lstinline{bool}, which affects the function type.}
 \begin{cquote}
 \setlength{\tabcolsep}{15pt}
 …
 \end{tabular}
 \end{cquote}
 These operations perform an apply of the validation function to each character, and it returns a boolean indicating a stopping condition.
+These operations perform an \emph{apply} of the validation function to each character, where the function returns a boolean indicating a stopping condition for the search.
 The position of the last character is returned if the string is compliant or the position of the first non-compliant character.
 …
 \end{cfa}
 \CFA also adopts a return code but the failure value is taken from the index-of function in APL~\cite{apl}, which returns the length of the target string $N$ (or $N+1$ for 1 origin).
+\CFA adopts a return code but the failure value is taken from the index-of function in APL~\cite{apl}, which returns the length of the target string $N$ (or $N+1$ for 1 origin).
 This semantics allows many search and substring functions to be written without conditions, \eg:
 \begin{cfa}
 …
 \VRef[Figure]{f:ExtractingWordsText} compares \CC and \CFA string code for extracting words from a line of text, repeatedly removing non-word text and then a word until the line is empty.
 The \CFA code is simpler solely because of the choice for indicating search failure.
 (It is possible to simplify the \CC version by concatenating a sentinel character at the end of the line so the call to @find_first_not_of@ does not fail.)
+(A simplification of the \CC version is to concatenate a sentinel character at the end of the line so the call to @find_first_not_of@ does not fail.)
 \begin{figure}
 …
 To ease conversion from C to \CFA, \CFA provides companion C @string@ functions.
 Hence, it is possible to convert a block of C string operations to \CFA strings just by changing the type @char *@ to @string@.
+\begin{cquote}
+\setlength{\tabcolsep}{15pt}
+\begin{tabular}{@{}ll@{}}
 \begin{cfa}
 char s[32];   // string s;
 …
 strcmp( s, "abc" );
 strncmp( s, "abc", 3 );
+\end{cfa}
+&
+\begin{cfa}
 strcpy( s, "abc" );
 strncpy( s, "abcdef", 3 );
 …
 strncat( s, "uvwxyz", 3 );
 \end{cfa}
+\end{tabular}
+\end{cquote}
 However, the conversion fails with I/O because @printf@ cannot print a @string@ using format code @%s@ because \CFA strings are not null terminated.
 Nevertheless, this capability does provide a useful starting point for conversion to safer \CFA strings.
 …
 @abcde fg@
 sin | quote( ch ) | quote( wdi( sizeof(c), c ) ) | quote( s, '[', ']' ) | nl;
 @$'a' "bcde" [fg]$@
+@'a' "bcde" [fg]@
 sin | incl( "a-zA-Z0-9 ?!&\n", s ) | nl;
 @x?&000xyz TOM !.@
 …
 \end{tabular}
 \end{cquote}
 Note, the ability to read in quoted strings to match with program strings.
+Note, the ability to read in quoted strings to match with program string constants.
 The @nl@ at the end of an input ignores the rest of the line.
 …
 As well, the operations 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}, defining properties: type abstraction, state, symmetry, and referent.
+More significant operational differences relate to storage management, often appearing through assignment (@target = source@), and are summarized in \VRef[Figure]{f:StrSemanticCompare}, which defines properties type abstraction, state, symmetry, and referent.
 The following discussion justifies the figure's yes/no entries per language.

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

Context Navigation

Changeset d9aee90 for doc/theses/mike_brooks_MMath

Legend:

doc/theses/mike_brooks_MMath/string.tex

Download in other formats: