- Timestamp:
- Apr 10, 2025, 2:17:22 PM (6 months ago)
- Branches:
- master
- Children:
- bb506e0
- Parents:
- 5ca1766
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/fangren_yu_MMath/conclusion.tex
r5ca1766 r28182444 1 1 \chapter{Conclusion} 2 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 library. 4 Many of the works done in this thesis are 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. 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 present new challenges, a lot of which are unforseen before development and testing started. 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. 5 7 6 This work aims to identify and fix the practical issues of multiple \CFA type system features and their interactions. In particular, the inclusion of reference types, tuple types and generic structs together with rich overloading in the language makes the complexity of expression resolution much higher in \CFA. Significant reworks in abstract syntax-tree representations and resolution algorithms are done to push the \CFA compilation time down to a practical level. The expression cost system is also revised multiple times to make overload selection more predictable and match programmer's intuition in majority of cases, although some fundamental problems still remain and fixing them will require some changes to the language from the ground up. 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. 7 13 8 As per \CFA project's motto of "describe not prescribe," \CFA type system is designed to have a lot of flexibility and gives programmers great deal of freedom in the usage of overloading and polymorphism. With such a complex type system, it is very difficult (sometimes even impossible) to try to have the compiler accept all kinds of valid \CFA programs. The \CFA programming language is still far from complete, and we will aim to expand \CFA compiler's type resolution capability while maintaining decent compile-time and run-time performance. Some theoretical insights of parametric polymorphism coming from functional programming also prove to be useful. 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.
Note:
See TracChangeset
for help on using the changeset viewer.