Peter N Lewis wrote:
I've been a long time Pascal programmer on the Mac, and I'm just starting to look at ways to get the Mac OS API interfaces working with gpc to allow porting of Mac Pascal programs to gpc/Mac OS X and writing of new programs. The latter requires only hacking the Mac API files sufficiently to work with gpc, the former requires easing the burden of moving code from the traditional THINK/CodeWarrior Pascal compilers to gpc.
Some tasks are best done by changing the source files, but other tasks would be much easier done with modifications to gpc to support some of the Mac constructs (eg univ untyped pointers, external names that match exactly the procedure names, some minor things like, and some major things like binary compatible "short" strings (this is a big one), closer object modal (this is a huge amount of work, either in gpc or in porting)). I understand that there are god ideological reasons for not wanting some of these things, it's just that a lot of existing Mac Pascal code has good practical reasons for wanting these changes (personally, I have an active project with 300 Pascal files and 100,000 lines, and it would nice to be able to switch from CodeWarrior's unsupported Pascal compiler to gpc, but it's going to be a hard slog!).
So before I go to far with this, my question is, if we were to manage to modify gpc (in safe and sensible ways), and if the modifications were hidden unless some sort of compiler switch was enabled (perhaps --traditional-mac-compatible or whatever, possibly on by default when compiled on Mac OS X), would those changes be added back in to the gpc code base? Or is the policy more along the lines of "no, that's not X Y or Z standard, so it has to be patched in afterwards"?
GPC does incorporate many features from non-standard dialects (mostly BP), so that's not a problem per se ...
The principle in GPC WRT dialects is that the default mode should accept all features of all dialects, and dialect options only turn off everything that doesn't belong to the given dialect. (In a few cases, there are warnings in the default mode about strange features, such as BP non-constant "typed constants" which are turned off by the dialect option.) So what you propose about the switch would be against this "policy".
Up to now, mixing the dialects has caused surpringly few problems, but there's no guarantee that this will remain so with new dialects added. Of course, any new dialect will increase the chances of conflicts ... and the complexity of the compiler. So we have to look at the features in detail.
Some tasks are best done by changing the source files, but other tasks would be much easier done with modifications to gpc to support some of the Mac constructs (eg univ untyped pointers,
I've commented on them (quite negatively ;-) recently. If I understood Adriaan's example right, they're mostly used with pointers and behave mostly like `Pointer' does in GPC/BP. (There are some subtle differences, such as Adriaan's example #3, but this is a really dangerous case, and it might be good if this doesn't work -- i.e., the programmer will be forced to check such cases and perhaps rewrite them more cleanly ...).
If that's all, the perhaps just "defining away" the `univ' will do the trick (`--cidefine=univ=' on the command line if you don't want to modify the sources). I don't like macros in general, but here perhaps they're more harmless than the alternatives ...
external names that match exactly the procedure names,
That's possible now with `asmname'. If you mean that, say, `procedure foobar; external;' and `procedure FooBar; external;' should behave differently -- well that's in direct contradiction to the Pascal standards (and other supported dialects such as BP), so I'd have severe issues with this one.
some minor things like, and some major things like binary compatible "short" strings (this is a big one),
We plan to do this for BP short strings. I don't know if these are the same (first byte: Length (limited to 255) accessible as a char `StringVar[0]', then the characters, capacity not stored). If so, yes, implementing them is wanted (but indeed quite involved).
closer object modal (this is a huge amount of work, either in gpc or in porting)).
Again, I don't know what the differences are. The OOE and Delphi models (rather close, but quite different from the existing BP model) are planned (and also much work) ...
Frank