New Compiler
From ASCEND
A better reimplementation of the compiler is a rather largish project, because ascend has rather odd semantics compared to most programming languages. But that said, it's always a fascinating sport and one which would substantially benefit many people if we could do a new generation of it. The C-based compiler is a brilliant piece of OO-C, but it is encumbered by several things that are suboptimal:
1) GPL. ASCEND is just dead in the water for attracting mutually beneficial relationships with industry-- the real users of numerical modeling. We need a clean implementation done under LGPL or less restrictive license.
2) syntactic sugar. Lot of good ideas that were very useful when the target audience knew only fortran previously are now just ugly; the open-source developer base is generally familiar with code that looks like Java, C++, or python and we need to clean up the ascend syntax to something more modern, or at least something from the early 90s.
3) Maintainability. (repeat that last word about 75 gazillion times). Flex/bison served us well enough, but they are weak in what they can express compared to antlr and similarly more modern parser description languages and as a result they are hard to extend. We have some ghastly complexities in our lex and yacc inputs that we dare not touch. Similarly, hand-coded parsers noone dares touch except their original creators-- the startup time for a new developer to extend such is still just too high. Antlr has an active community and open-source gui development tools that really work well-- we can't afford to ignore that in a very resource-limited community like ascend. ASCEND code is much more compact (it's a domain-specific language we would like to make embeddable/translatable to other languages, generally) and thus parser performance is simply irrelevant. Accuracy, maintainability, and quality of end-user diagnostic output are the top considerations.
4) C. Who knows C any more, and of those who do, who really knows how to reference count properly? I know the linux kernel is in C, but the kernel world is just an entirely different class of developer/user than ascend can count on enjoying in a steady fashion.
That's the suboptimalities of the current implementation. The challenges (whatever the implementation strategy) are that we must ensure that all existing ascend models are machine translatable to the new syntax and thus that all existing semantic features carry forward. Along the way there's always new things in include for fun-- stuff we only designed but never coded for ascend4. ode-syntax, interval math, single and multiprecision floating point.
And one of the most annoying and persistent questions one must ask before embarking on a new or improved compiler is: Why not Modelica (or other X "opensource") language? Why ascend (which is a little language)?
A more interesting goal is to have a compiler that can target multiple generators or at least a C/C++/Java generators with automated wrapper bindings for all other languages from a given ascend model instance.
