Peter N Lewis wrote:
At 5:32 PM +0100 1/3/03, Frank Heckenbach wrote:
Peter N Lewis wrote:
univ (doesn't conflict as long as it is overridden by any user defined variable/type/etc)
Overridden? I thought the syntax was `univ TypeName'. This would be a syntax extension (which I generally take with some scepticism) and couldn't be overridden. At best, `univ' could become a conditional keyword (as I suggested recently), so a user-defined identifier `Univ' would make the syntax extension unavailable.
Yes, that's what I mean - ie, a user could have code to use the identifier univ and this extension would not harm them, and a user could have code from the mac world which uses univ and it would work for them. To me, this fits well with your desire to support all the features of all the languages in so much as they don't conflict.
OK, syntactically it would fit.
making the "implementation begin" optional in interface only files.
You mean omitting the word `implementation'?
Correct. Essentially, interface only units are typically used for system interfaces (or can also be used for library interfaces where you ship binary builds of the library), and these have no implementation in the Pascal unit file, so that section is ommitted and the "end." comes at the end of the interface section.
I know. gpc.pas is (almost) such a case (except that it's no unit, but a module ;-).
No big deal, it's easy to work around, but again, it seems to fit well with the desire.
OK. It will be warned about in `--borland-pascal'.
I'm adding a new option (is `--mac-pascal' ok?). Now, of course, all existing non-standard features which are part of Mac Pascal (such as units) have to be marked as such in the compiler (mostly a matter of changing some constants like B_D_PASCAL in many places, a rather tedious job). I'll leave this to you (if possible, please do it shortly after the next release, because I've made many changes and probably will again after the next release, and such a "spreaded" change will likely cause conflicts if applied to diverging versions) ...
function CreateOurData( var data: univ OurDataPtr );
This sounds more like `restricted' in EP -- and quite unlike what Adriaan explained about `univ'. According to his explanation, one could pass any data type to CreateOurData whose size happens to match that of OurData.
No, any data whose size matches OurDataPtr.
Yes, that's what I meant. (I had read to quickly and thought it was `var data: univ OurData'.)
Yes, I believe the definition of univ simply limits the type checking to anything that matches the binary size.
Here's a possible compromise suggestion that would possibly be safer while still providing a high degree of compatibility. Support parameters with syntax "param: univ MyTypePtr", but only where MyTypePtr is a pointer. This would then be equivalent for the external user as "param: Pointer", but for the procedure, param would be typed as if it was MyTypePtr. This would handle the bulk of the uses of univ - the only other ones I can see in code I have access to is where parameter is SInt16 or SInt32, where you want to be able to ignore the differences between signed and unsigned numbers for purposes like reading/writing from a binary file or network transfer or such.
Well, signed and unsigned integers would be relatively harmless in many circumstances, but many other types also have the same size, such as pointers (on some platforms), short reals (on some), strings/char arrays of a certain length, some small records and sets, etc.
So perhaps supporting it for fixed with types like Pointers and Integers? But even just Pointer compatible types would be the bulk of them.
OK, I think I could rather live with that.
The implementation might be a little more effort then -- just `univ Pointer' which is mapped to (BP's) `Pointer' would be rather easy, but this way, the real pointer type has to be kept. So each pointer type needs to have a flag whether it's `univ'. When the routine is called, this flag must be checked to "relax" type checking, but not when the parameter is used within the routine, IIRC.
So the task would be (if I'm not missing something -- that's roughly the order I would do things):
- Write some test programs - Define the flag (gpc.h and utils/gpidump.pas) - Extend the syntax (this will involve defining `univ' as a conditional keyword, or if you're lucky, only a special identifier) - Check the dialect - Set the flag - Check the flag on parameter passing - Test, debug ...
I think that's feasible, and you might be able to do it if you get familiar with some of GPC's internals ...
Frank