Changeset 4791307 for doc/theses/fangren_yu_MMath/features.tex

Timestamp:

May 20, 2025, 7:09:17 AM (10 months ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

master, stuck-waitfor-destruct

Children:

a7b78c3

Parents:

00ad2a0

Message:

remove unnecessary PAB markers, and proofread added text on code improvements

File:

• doc/theses/fangren_yu_MMath/features.tex (modified) (5 diffs)

doc/theses/fangren_yu_MMath/features.tex

@@ -123 +123 @@
 the call to @foo@ must pass @x@ by value, implying auto-dereference, while the call to @bar@ must pass @x@ by reference, implying no auto-dereference.
 
-\PAB{My analysis shows} without any restrictions, this ambiguity limits the behaviour of reference types in \CFA polymorphic functions, where a type @T@ can bind to a reference or non-reference type.
+My analysis shows without any restrictions, this ambiguity limits the behaviour of reference types in \CFA polymorphic functions, where a type @T@ can bind to a reference or non-reference type.
 This ambiguity prevents the type system treating reference types the same way as other types, even if type variables could be bound to reference types.
 The reason is that \CFA uses a common \emph{object trait}\label{p:objecttrait} (constructor, destructor and assignment operators) to handle passing dynamic concrete type arguments into polymorphic functions, and the reference types are handled differently in these contexts so they do not satisfy this common interface.
@@ -287 +287 @@
 \end{figure}
 
-\PAB{I identified} the primary issues for tuples in the \CFA type system are polymorphism and conversions.
+I identified the primary issues for tuples in the \CFA type system are polymorphism and conversions.
 Specifically, does it make sense to have a generic (polymorphic) tuple type, as is possible for a structure?
 \begin{cfa}
@@ -386 +386 @@
 Scala, like \CC, provides tuple types through a library using this structural expansion, \eg Scala provides tuple sizes 1 through 22 via hand-coded generic data-structures.
 
-However, after experience gained building the \CFA runtime system, \PAB{I convinced them} making tuple-types first-class seems to add little benefit.
+However, after experience gained building the \CFA runtime system, I convinced them making tuple-types first-class seems to add little benefit.
 The main reason is that tuples usages are largely unstructured,
 \begin{cfa}
@@ -574 +574 @@
 
 Currently in \CFA, variadic polymorphic functions are the only place tuple types are used.
-\PAB{My analysis showed} many wrapper functions are generated to implement both user-defined generic-types and polymorphism with variadics, because \CFA compiles polymorphic functions versus template expansion.
+My analysis showed many wrapper functions are generated to implement both user-defined generic-types and polymorphism with variadics, because \CFA compiles polymorphic functions versus template expansion.
 Fortunately, the only permitted operations on polymorphic function parameters are given by the list of assertion (trait) functions.
 Nevertheless, this small set of functions eventually needs to be called with flattened tuple arguments.
@@ -824 +824 @@
 
 In general, non-standard C features (@gcc@) do not need any special treatment, as they are directly passed through to the C compiler.
-However, \PAB{I found} the Plan-9 semantics allow implicit conversions from the outer type to the inner type, which means the \CFA type resolver must take this information into account.
+However, I found the Plan-9 semantics allow implicit conversions from the outer type to the inner type, which means the \CFA type resolver must take this information into account.
 Therefore, the \CFA resolver must implement the Plan-9 features and insert necessary type conversions into the translated code output.
 In the current version of \CFA, this is the only kind of implicit type conversion other than the standard C arithmetic conversions.