Changeset a7b78c3 for doc/theses

Timestamp:

May 20, 2025, 10:26:56 AM (4 months ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

master

Children:

d92bc97

Parents:

4791307

Message:

remove unnecessary PAB markers

File:

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

doc/theses/fangren_yu_MMath/resolution.tex

@@ -507 +507 @@
 Since these functions are implicitly defined for almost every type in scope, there can be hundreds or even thousands of matches to these functions with an unspecified operand type.
 
-\PAB{Based on this observation, I implemented an optimization to the assertion resolution algorithm that only attempts to resolve object assertions after all other assertions are resolved successfully.
+Based on this observation, I implemented an optimization to the assertion resolution algorithm that only attempts to resolve object assertions after all other assertions are resolved successfully.
 As well, it further delays resolving object assertions with an unbound first-argument type, \ie the type of the argument being constructed or destructed, until no progress can be made otherwise. 
 This simple optimization on assertion-resolution order eliminates over 80 percent of unbound object-lifetime function lookups. 
 In most cases, the operand type can be inferred by resolving other assertions first, and then the object lifetime functions can be looked up efficiently, since these functions are indexed by the operand type in the identifier table of the compiler.
 Although the unbound parameter case appears infrequently in practice, it is potentially very costly due to thousands of wasted type unification runs each time it occurs.
-As a result, this optimization is able to produce an overall compilation speedup of around 10 percent.}
-
-\PAB{The issue of having unbound parameters also limits the capability of the assertion resolution algorithm.}
+As a result, this optimization is able to produce an overall compilation speedup of around 10 percent.
+
+The issue of having unbound parameters also limits the capability of the assertion resolution algorithm.
 Assertion matching is implemented to be more restrictive than expression resolution in general, in that the parameter types must match exactly, rather than just merely callable.
 If a function declaration includes the assertion @void f(T)@ and only a @f(long)@ is in scope, trying to resolve the assertion with @T == int@ does not work.
@@ -531 +531 @@
 }
 \end{cfa}
-\PAB{This case is rare, so forcing every type variable to appear at least once in parameter or return types does not limit the expressiveness of \CFA type system to a significant extent.
-\VRef{s:AssociatedTypes} presents a proposal for including type declarations in traits rather than having all type variables appear in the trait parameter list, which provides equivalent functionality to an unbound type parameter in assertion variables, serves as a guidance to the resolution algorithm that works in more general cases than the specific optimization for object assertions mentioned above, and also addresses some of the variable cost issue discussed in \VRef{s:ExpressionCostModel}.}
+This case is rare, so forcing every type variable to appear at least once in parameter or return types does not limit the expressiveness of \CFA type system to a significant extent.
+\VRef{s:AssociatedTypes} presents a proposal for including type declarations in traits rather than having all type variables appear in the trait parameter list, which provides equivalent functionality to an unbound type parameter in assertion variables, serves as a guidance to the resolution algorithm that works in more general cases than the specific optimization for object assertions mentioned above, and also addresses some of the variable cost issue discussed in \VRef{s:ExpressionCostModel}.