| 1 | \chapter{Conclusion}
|
|---|
| 2 |
|
|---|
| 3 | In the past few years of development, \CFA has gone from a proof-of-concept prototype to an actual experimental language, with a few medium-sized projects written completely in \CFA included in the language's libraries ($\approx$\,45,000 lines of code).\footnote{In Fall 2024, two amazing CS343 students completed all 6 concurrent assignments in \CFA. Many small language problems were uncovered and missing features discovered; these issues are being fixed for Fall 2025.}
|
|---|
| 4 | The work done in this thesis is motivated by real needs arising from the development and testing of these projects, which often pushes the limits of \CFA's type system and compiler capabilities.
|
|---|
| 5 | While most of the previous \CFA language feature and compiler developments were done either in isolation or with limited testing, getting them to work together and with real projects is presenting significant new challenges.
|
|---|
| 6 | These challenges could have been foreseen before development and testing began in earnest.
|
|---|
| 7 |
|
|---|
| 8 | This work aims to identify and fix a number of practical issues of multiple \CFA type-system features and their interactions.
|
|---|
| 9 | In particular, the inclusion of reference types, tuple types, and generic structures together with rich overloading in the language makes the complexity of expression resolution much higher than in other programming languages.
|
|---|
| 10 | I significantly reworked the abstract syntax-tree representation and resolution algorithm to push the \CFA compilation time down to a practical level.
|
|---|
| 11 | The expression-cost system was also revised multiple times to make overload selection more predictable and match programmer's intuition and expectation in the majority of cases.
|
|---|
| 12 | Still, fundamental problems remain and fixing them will require significant changes to the language type-system, possibly from the ground up.
|
|---|
| 13 |
|
|---|
| 14 | As per the \CFA project motto ``describe not prescribe,'' \CFA's type system is designed to have a lot of flexibility and give programmers freedom in the usage of overloading and polymorphism.
|
|---|
| 15 | With such a complex type system, it is very difficult (sometimes even impossible) to try to have the compiler accept all the intuitively valid \CFA programs.
|
|---|
| 16 | As has been demonstrated, the \CFA programming language is still far from complete, and the primary future goal is to expand \CFA's type-resolution capability while maintaining, expressibility, decent compile-time, and excellent run-time performance.
|
|---|
| 17 | Stealing some theoretical insights of parametric polymorphism from functional programming, may also prove to be useful.
|
|---|
