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

Timestamp:

May 12, 2025, 8:59:26 PM (10 months ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

master, stuck-waitfor-destruct

Children:

2410424

Parents:

8fe7a85

Message:

add identification information

File:

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

doc/theses/fangren_yu_MMath/features.tex

@@ -122 +122 @@
 \end{cfa}
 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.
-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.
+
+\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.
 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.
@@ -286 +287 @@
 \end{figure}
 
-The primary issues for tuples in the \CFA type system are polymorphism and conversions.
+\PAB{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}
@@ -384 +385 @@
 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, making tuple-types first-class seems to add little benefit.
+However, after experience gained building the \CFA runtime system, \PAB{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}
@@ -571 +572 @@
 
 Currently in \CFA, variadic polymorphic functions are the only place tuple types are used.
-And because \CFA compiles polymorphic functions versus template expansion, many wrapper functions are generated to implement both user-defined generic-types and polymorphism with variadics.
+\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.
 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.
@@ -821 +822 @@
 
 In general, non-standard C features (@gcc@) do not need any special treatment, as they are directly passed through to the C compiler.
-However, 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, \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.
 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.