Changeset 57c7e6c4 for doc/theses/fangren_yu_MMath/future.tex

Timestamp:

May 3, 2025, 12:46:23 AM (8 months ago)

Author:

Fangren Yu <f37yu@…>

Branches:

master

Children:

c9c1a7e6

Parents:

ef05cf0

Message:

proofreading fix as suggested by Ondrej

File:

• doc/theses/fangren_yu_MMath/future.tex (modified) (2 diffs)

doc/theses/fangren_yu_MMath/future.tex

@@ -92 +92 @@
 \section{Associated Types}
 
-The analysis presented in \VRef{s:AssertionSatisfaction} shows if all type parameters have to be bound before assertion resolution, the complexity of resolving assertions become much lower as every assertion parameter can be resolved independently.
+The analysis presented in \VRef{s:AssertionSatisfaction} shows if all type parameters have to be bound before assertion resolution, the complexity of resolving assertions becomes much lower as every assertion parameter can be resolved independently.
 That is, by utilizing information from higher up the expression tree for return value overloading, most of the type bindings can be resolved.
 However, there are scenarios where some intermediate types need to be involved in certain operations, which are neither input nor output types.
@@ -152 +152 @@
 Note that the type @list *@ satisfies both @pointer_like( list *, int )@ and @pointer_like( list *,@ @list )@ (the latter by the built-in pointer dereference operator) and the expression @*it@ can be either a @struct list@ or an @int@.
 Requiring associated types to be unique makes the @pointer_like@ trait not applicable to @list *@, which is undesirable.
-I have not attempted to implement associated types in \CFA compiler, but based on the above discussions, one option is to make associated type resolution and return type overloading coexist:
+I have not attempted to implement associated types in the \CFA compiler, but based on the above discussions, one option is to make associated type resolution and return type overloading coexist:
 when the associated type appears in returns, it is deduced from the context and then verify the trait with ordinary assertion resolution;
 when it does not appear in the returns, the type is required to be uniquely determined by the expression that defines the associated type.