On Wed, 2010-07-28 at 22:52 +0200, Frank Heckenbach wrote: [...]
My one concern would be about producing yet another Pascal object model that is not compatible with any of the existing ones. But I guess that, if the old BP model is still supported so that existing code would compile, that would be fine.
That's kind of what I half expected and half feared. If I'm the only one to want a new (or at least extended) object model (in particular WRT enforced constructors and automatic destructors) or other features (such as templates), there's no point implementing them.
An extended object model is fine, and Templates sound like a very good idea. My main concern was about existing code. If existing code would still compile, then that concern goes away. Enforced constructors are not a problem (that is already required in the Delphi Class model - your program will crash if you don't call a constructor to instantiate your object). I don't know how automatic destructors work, but I don't have a problem with the idea (in Delphi you would have to call object.free - a method, that calls the appropriate destructor). IMHO, any thing that makes the programmer's work less error-prone is good. But it makes sense (if at all possible without a disproportionate amount of effort) to develop/extend the object model in a way that is compatible (as far as possible) with an existing model (perhaps as a superset of one or more).
I don't know what you have in mind WRT the object model, and I don't know whether "automatic" con-/destructors refers to implicit or explicit con-/destructors. And, would there be a common ancestor (type or template) for all objects? And what would be the difference with the BP model?
Example: { BP model } type foo = object end; {foo has no con-/destructor, which are totally unnecessary; and it has no inherent behaviour or attribute }
{ extended model } type foo = extended_object end; {does foo have any con-/destructor, and/or any inherent behaviours or attitudes? what if I want to add my own con-/destructors?}
This is just a matter of curiosity for me, and the actual answer is neither here nor there. I think many programmers tend to look at new compiler features with great interest (as long as they don't break existing code) and I am sure that this will happen with a revamped GPC. It may even be that other Pascal compilers would copy the new features (e.g., Templates).
The bottom line: although a self-compiling GPC would be wonderful if possible without undue effort, it doesn't really matter what language the revamped GPC is written in (although I personally could only hope to contribute Pascal code). C++ is as good as any other language, and I see no philosophical reason against it.
I know very little about C++ standards, so what follows may simply be the result of my ignorance. The question is - how confident are you that the compiler's translation from Pascal to C++ would always compile? What C++ standard would it generate code for? Is there a lowest common denominator "standard" that would compile on any C++ compiler? How would GPC verify that there is a compliant C++ compiler? Would the GPC compiler itself compile with every standards-compliant C++ compiler? (for example, would I be able to build it on Windows with MSVC, and g++, and Borland/Turbo C++? - which would be wonderful).
Conclusion: for my part, as long as one can still run: "gpc foo.pas [blah blah]" and end up with a compiled program "foo[.exe]", then all is well.
If you can provide a list (and specifications) of Pascal tasks that need doing (and required coding principles and conventions) to get the revamped compiler going, then I am sure that there will be many volunteers (present company included).