CBFalconer wrote:
Don't misunderstand, I wasn't arguing for using m4, just pointing out that it exists. Actually, on further idle thought (none of this is especially well thought out) maybe the integrated preprocessor is the way to implement the Delphi constructs. The philosophy of the triple system, GNU, 10206, 7185 seems to be firmly established. By banishing most Delphi and TP extensions to such a preprocessor it might be possible to keep the main thing cleaner.
Might be nice if it worked, but I suppose for most features it won't since they require more syntactic information. E.g., one difference between BP objects and Delphi classes is that the latter are implicitly references. They way to implement them on top of objects (if no other problems arise) would be via pointers, adding `^' automatically. But there's no way to find the places where to add them with typical "preprocessor" information. If you think of complex expressions, involving function parameters/results, record/object fields, the preprocessor would have to know about all their types etc.
I think that's easier to do within the parser. And I don't think it won't be a big problem (apart from the effort involved to implement it, of course), and, of course, we can reject it based on dialect options.
For other features, it might be possible with the preprocessor. E.g., it shouldn't be too hard to construct a prreprocessor to ignore `()'. But then again, it would ignore them everywhere, so also `MyVariable ()' would work which is probably a bad idea (even worse than `MyFunction ()').
Another point is that preprocessor features don't work across units/modules (in the current separate implementation that would be almost impossible to achieve, and it's also thought cleaner not to do so), while most Delphi features would have to ...
Frank