Getting Functional -- Literally; New Features from the Functional Paradigm
I've been reading a variety of material relating to programming languages to inhale the current thinking (so to speak) and it seems that two object-oriented languages C# (3.0) and Python are getting functional -- adding the lambda capability for anonymous functions. Most of the debate and discussion seems to center around usability, paradigm, and future speculation about how functional features will either destroy or become the darling of the language.
One area that is overlooked in such discussions is the compiler writer. Adding features adds a level of compiler checks and processing that adds an exception to the rule. Functional features mixed into object-oriented add a use-case rule to check for during the compilation process. Its either a case of the feature being a form of syntactic sugar (in which case it could be translated to another core language feature that is not an exception use-case rule), or as an actual feature requiring its own parsing, syntax element, semantic checks, and code synthesis. Syntactic sugar seems easier as its a case of converting what looks like a new feature into (at least internally in the abstract syntax elements) an existing feature behind the curtain of the compiler theater. But it adds complexity in order to map from the new feature into an existing one, even behind the scene -- and information about errors and problems has to be returned in the form of the feature, not the transformed one. As an actual feature not translated it would be a new syntax element, although errors and problems would be specific to the new feature. So either way there is a level of complexity added (although I'm being general).
But a new feature is a temptation to add, to make a programming language more like an application with a new feature, but the downside is that compiler writer's task of incorporating the new feature either way is more complex. To what degree? My guesstimate would be that for each feature added, it is a linear or arithmetic progression of features in the language, but the compiler and the compiler writer it is a geometric progression (for non syntax sugar features).
Feature: 1+2+3+4 = 7
Complexity: 1*2*3*4 = 24
The complexity can reach a point where all features become syntax sugar, forcing the core language to be minimal, so to follow the idea "less is more" why not keep a programming language like it in the first place. The functionality of the compiler increases where, to use a common expression "More is Less."
This leads to the question useful for evaluating a new programming language feature F1 in programming language P, is F1 some syntax for an equivalent feature FO so that F1 > FO in P. If the feature is syntax sugar, is it a feature that can be part of the language to save on expressing it equivalently? The answer should not be ambigious, or simply to save on typing -- there should be a clear rationale beyond syntactic sugar to sweeten the programming language P with a new feature F1 that is possible with F0. If the new feature F1 is not syntactic sugar that is a different kind of animal, but if it is the question is more clear about adding it in terms of the equivalent feature F0. As I look at features in Mynx, even functional ones, many I have discounted as syntax sugar that is only creeping featuritis and complexity -- but some syntactic sugar is useful -- for explicitness of syntax, whereas non-syntax sugar features are different. So in some ways Mynx has baroque syntax sugar of features, but for reasons than adding a feature.
For example, Java and C# have classes and interfaces, the equivalent in Mynx is all classes, and a virtual class. Mynx also has a program syntax unit, primarily to distinguish a class = library from a program = application, although a class with a main method in Java (or if added in Mynx) is equivalent. The Mynx program is a form of syntax sugar...but it explicitly distinguishes a library unit from an application unit in syntax of the programming language.
As I designed, implemented, and now am implementing the semantic checks (and looking ahead to code synthesis) much of a classic paper I read (ironically as a CS undergrad taking LISP) "Worse is Better" by Richard Gabriel is more meaningful and sensible than when I read it as a dry monograph for a class that might be a question on a quiz. A language is not just a programming language, it is a language designer's philosophy on how to express and think about solutions to problems in software.
One area that is overlooked in such discussions is the compiler writer. Adding features adds a level of compiler checks and processing that adds an exception to the rule. Functional features mixed into object-oriented add a use-case rule to check for during the compilation process. Its either a case of the feature being a form of syntactic sugar (in which case it could be translated to another core language feature that is not an exception use-case rule), or as an actual feature requiring its own parsing, syntax element, semantic checks, and code synthesis. Syntactic sugar seems easier as its a case of converting what looks like a new feature into (at least internally in the abstract syntax elements) an existing feature behind the curtain of the compiler theater. But it adds complexity in order to map from the new feature into an existing one, even behind the scene -- and information about errors and problems has to be returned in the form of the feature, not the transformed one. As an actual feature not translated it would be a new syntax element, although errors and problems would be specific to the new feature. So either way there is a level of complexity added (although I'm being general).
But a new feature is a temptation to add, to make a programming language more like an application with a new feature, but the downside is that compiler writer's task of incorporating the new feature either way is more complex. To what degree? My guesstimate would be that for each feature added, it is a linear or arithmetic progression of features in the language, but the compiler and the compiler writer it is a geometric progression (for non syntax sugar features).
Feature: 1+2+3+4 = 7
Complexity: 1*2*3*4 = 24
The complexity can reach a point where all features become syntax sugar, forcing the core language to be minimal, so to follow the idea "less is more" why not keep a programming language like it in the first place. The functionality of the compiler increases where, to use a common expression "More is Less."
This leads to the question useful for evaluating a new programming language feature F1 in programming language P, is F1 some syntax for an equivalent feature FO so that F1 > FO in P. If the feature is syntax sugar, is it a feature that can be part of the language to save on expressing it equivalently? The answer should not be ambigious, or simply to save on typing -- there should be a clear rationale beyond syntactic sugar to sweeten the programming language P with a new feature F1 that is possible with F0. If the new feature F1 is not syntactic sugar that is a different kind of animal, but if it is the question is more clear about adding it in terms of the equivalent feature F0. As I look at features in Mynx, even functional ones, many I have discounted as syntax sugar that is only creeping featuritis and complexity -- but some syntactic sugar is useful -- for explicitness of syntax, whereas non-syntax sugar features are different. So in some ways Mynx has baroque syntax sugar of features, but for reasons than adding a feature.
For example, Java and C# have classes and interfaces, the equivalent in Mynx is all classes, and a virtual class. Mynx also has a program syntax unit, primarily to distinguish a class = library from a program = application, although a class with a main method in Java (or if added in Mynx) is equivalent. The Mynx program is a form of syntax sugar...but it explicitly distinguishes a library unit from an application unit in syntax of the programming language.
As I designed, implemented, and now am implementing the semantic checks (and looking ahead to code synthesis) much of a classic paper I read (ironically as a CS undergrad taking LISP) "Worse is Better" by Richard Gabriel is more meaningful and sensible than when I read it as a dry monograph for a class that might be a question on a quiz. A language is not just a programming language, it is a language designer's philosophy on how to express and think about solutions to problems in software.
Labels: compiler checks, compiler writing, functional, language complexity, mynx, programming language features
posted by Will Gilreath at
3:45 AM
<< Home