Changeset 6162e0e for doc/aaron_comp_II
- Timestamp:
- Jul 28, 2016, 2:22:21 PM (8 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, ctor, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
- Children:
- d5905a2
- Parents:
- 95330f5
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/aaron_comp_II/comp_II.tex
r95330f5 r6162e0e 363 363 364 364 \section{Proposal} 365 365 Baker\cite{Baker82} discussed various expression resolution algorithms that could handle name overloading, but left experimental comparison of those algorithms to future work; Bilson\cite{Bilson03} described one extension of Baker's algorithm to handle implicit conversions, but did not fully explore the space of algorithmic approaches to handle both overloaded names and implicit conversions. 366 This project is intended to experimentally test a number of expression resolution algorithms which are powerful enough to handle the \CFA type system, including both name overloading and implicit conversions. 367 This comparison will close Baker's open research question, as well as potentially improving on Bilson's \CFA compiler. 368 369 Rather than testing all of these algorithms in-place in the \CFA compiler, a resolver prototype will be developed which acts on a simplified input language encapsulating the essential details of the \CFA type system\footnote{Note that this simplified input language is not required to be a usable programming language.}. 370 Multiple variants of this resolver prototype will be implemented, each encapsulating a different expression resolution variant, sharing as much code as feasible. 371 These variants will be instrumented to test runtime performance, and run on a variety of input files; the input files may be generated programmatically or from exisiting code in \CFA or similar languages. 372 These experimental results will allow the research team to determine the algorithm likely to be most performant in practical use, and replace {CFA-CC}'s existing expression resolver with that code. 373 The experimental results will also provide some empirical sense of the compile-time cost of various language features by comparing the results of the most performant resolver variant that supports the feature with the most performant resolver variant that doesn't, a useful capability to guide language design. 366 374 367 375 \appendix 368 \section{Completion Timeline} \label{app:completion}376 \section{Completion Timeline} 369 377 The following is a preliminary estimate of the time necessary to complete the major components of this research project: 370 378 \begin{center} 371 379 \begin{tabular}{ | r @{--} l | p{4in} | } 372 380 \hline May 2015 & April 2016 & Project familiarization and generic types design \& implementation. \\ 373 \hline May 2016 & April 2017 & Design \& implement prototype resolverand run performance experiments. \\381 \hline May 2016 & April 2017 & Design \& implement resolver prototype and run performance experiments. \\ 374 382 \hline May 2017 & August 2017 & Integrate new language features and best-performing resolver prototype into {CFA-CC}. \\ 375 383 \hline September 2017 & January 2018 & Thesis writing \& defense. \\
Note: See TracChangeset
for help on using the changeset viewer.