Meta gpc question

Frank Heckenbach frank at g-n-u.de
Sat Mar 1 08:11:15 CET 2003


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

-- 
Frank Heckenbach, frank at g-n-u.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: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707




More information about the Gpc mailing list