Bastiaan Veelo wrote:

We have an extensive code base of Extended Pascal that is in active use commercially, and we will continue development in many years to come. We are using the Prospero compiler, which is still serving our needs. But, as Prospero is Windows-only, gpc has always appeared as the most promising escape route to portability, should we need it. Therefore I am hoping that gpc will find its way into the future.

I have a small contribution to the discussion. Regarding the suggestion of turning gpc into a translator to some other language, I would suggest considering the D programming language as the target language, instead of C++. I have been following the development of D for many years, and have always seen similarities between Extended Pascal and D. Off the top of my head there are nested functions, modules, function argument storage classes, better type safety than C++, dynamic arrays with size information, and fast compilation (especially compared to C++). There may be more similarities. D's template design is also much better than C++'s, as is its approach to const-correctness and its alternative to multiple-inheritance. D is designed to be a better language than C++, and I think it is. I think that of modern languages D is most compatible to the way Pascal programmers like to think (pardon the generalization) and although its syntax is C++-inspired, D might be a good candidate to "take over" from Pascal. If gpc would do a good job at generating readable D code, Pascal programmers could choose to continue writing Pascal or make the switch to D completely and be happy with it.

Some pointers: http://en.wikipedia.org/wiki/D_%28programming_language%29 http://www.digitalmars.com/d/

As for the main features as listed in the Wikipedia article: - some are mainly library issues or can be addressed as such, including associative and dynamic arrays (e.g. map and vector in STL) or array slicing (not sure if STL currently provides this, but it could), - some of the mentioned improvements actually exist in C++ such as inner classes and the previously mentioned STL types, - some things will be addressed in the planned C++0x standard (http://en.wikipedia.org/wiki/C%2B%2B0x), e.g. foreach-like loops, better metaprogamming including compile-time function execution, and anonymous functions, including nested ones and closures, - some things I don't necessarily see as advantages for our purposes, e.g. automatic gargabe collection (on a (Pascal) language level, I think we should leave the choice to the user), or limited multiple inheritance (though I hardly need the full version myself, but if we choose to implement just the limited form, we can do it equally well in C++ and D, since it's a strict subset of the full version; but if we, now or later, decide we want the full form in some object model, C++ has it), - for some things the description there is too vague, e.g. "reengineered template syntax" (the example doesn't tell me much -- however, if it's only about syntax, it doesn't matter much for a target language anyway) or the inline assembler (g++ has one, I have no idea if D's is better or worse -- mostly likely it won't be (CPU-)portable (quite hard for assembler code ;-), and apart from that, I see no major drawbacks in the g++ inline assembler (same as that in gcc and gpc), except maybe from syntax (irrelevant, see above); in particular it cooperates well with the optimizer which is not true of many other inline assemblers I've seen, in particular BP's, even for that tiny bit of optimization that BP has), - so only a few things are left that are clearly advantages in my view, e.g. true modules and first class arrays. (Though modules are not such a big issue for a compiler-converter either; converting to C++ style "compilation units" and headers is not much more difficult, and the more tricky part -- processing modules in the correct order WRT dependencies -- has to be done in the frontend anyway; this is what "gp" currently does which could partly be reused as well.) But most importantly of all (IMHO), D doesn't seem very widespread. Maybe this will change. However, since one root of our problems is really that Pascal isn't so widespread (anymore), I'm reluctant to base its renewal on another language whose long-time future is also in doubt AFAICS. Honestly, if I had to bet on the futue of D vs. C++0x, I'd take the latter, even if it's still in the standardization process, just because of the mass of existing C++ code and compilers. (And even if C++0x fails, the fallback to the existing C++ standard is soft, whereas a failure of D a few years from now when we have based our new compiler on it would be fatal.) Of course, for manually (or semi-automatically) converting your Pascal programs to another language if GPC has no future, D might be a good choice. Frank -- Frank Heckenbach, f.heckenbach@fh-soft.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8