Why not make the programming language customizable with extra plug-ins :
A second example is given in Veldhuizen's paper "Five Compilation Models for C++ Templates" (Veldhuizen). Veldhuizen moved type analysis from the compiler to a library, and then used partial evaluation to drive type analysis and template instantiation. By making simple changes to the partial evaluator, programmers can produce everything from pure dynamic typing (for scripting) through standard compilation to profile-directed template instantiation. Each model makes a different tradeoff between code size, code speed, and compilation time, while preserving the original semantics.
Many people have observed that programming languages grow by formalizing and generalizing the best practices of their day. Well-nested goto statements become structured programming's conditionals and loops; records that are only ever accessed through companion functions become objects; functions that are identical except for data types become generics, and so on.
Hmm. Reminds me of wiki-conventions which start social (but may end up supported technically)
But why just think in terms of plug-ins? Why not have sub-language definition as part of the language? If you can define methods within classes, why not allow classes to also define their own languages as interface?
: Lisp (and its many variants), Pop-11 and, hopefully before the next millenium comes, Perl 6 are some of the languages that allow you to define your own syntax. Perl 6 is looking especially funky since you have the language grammar available as first class objects to fiddle with. Its interesting to see that even in Java you have things like AspectJ basically extending the language. Domain specific languages good IMHO – AdrianHoward
For example, a tree-class should be able to define tree-query language (maybe to be called in square brackets.)
tree[match:match:match] = x
where "match:match:match" is a language defined by the tree class for accessing it?
Storing a program as XML? Aaargh! But I see their point.
Surely the real objection to the idea of storing source-code in some more structured underlying format is that it constrains what structure a programming language built on top of it, is going to have in the future.
For example, does the underlying structure allow for asynchronous events? Parallel threads? Declarative assertions? Aspects and cross-cutting? Generators? If not, we won't be able to build those on top of this substrate. Could it lock us in to current thinking on languages? (On the other hand, maybe this is TradeOff you always have to make when building higher level platforms ... easier manipulation at one-level against lock-in that prevents wilder changes. And hey! maybe I win BonusFreakyConnectionPoints for tying this to the dynamic waves of customizability and value discussed in ConservationOfModularity :-)
See also :
- A structured underlying representation of code? JackPot / IntentionalProgramming
- BEACH if it ever takes off, but I note that a lot of BEACH-like pages are ending up here on ThoughtStorms.
- DecompositionByLanguageIsProbablyAModularityMistake for more thoughts on mixing types of languages
- PaulGraham writes some essays on LanguageDesign
- ProgrammingLanguages in general
- XmlHammer for the ubiquitous use of XML
- OnPlatforms because languages are just a kind of platform