Meta gpc question
Peter N Lewis
peter at stairways.com.au
Sun Mar 2 15:27:06 CET 2003
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.
> > 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. No big
deal, it's easy to work around, but again, it seems to fit well with
> > 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, 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. So perhaps supporting it for fixed with types like Pointers
and Integers? But even just Pointer compatible types would be the
bulk of them.
>I'm confused. If `univ' really does lump together all these usages
>(untyped pointers; restricted; schemata; kind of OOP), I'm even more
>sceptical, I'm afraid ...
No, it is just a simply statement to the compiler "anything matching
the size of this type is ok", I'm just illustrating some of the ways
it is used. GPC may well have better ways for every possible use of
univ (although it seems to me that specifying a particular type of
pointer but allowing any type of pointer to be passed could be
cleaner than just using Pointer for at least some problems), but
regardless, it's a porting issue for Mac users. Probably not a
stopper, just one more thing between them and getting the benefits of
> > Yes, that sounds the same. I figured that would come sooner or later
>> and was wondering whether to have a look at implementing it in gpc,
>> but that seemed a little bit like jumping in at the deep end!
>Yeah, not exactly the easiest thing to start with (I'm still a bit
>afraid of taking it on myself) ...
Yep. But at least then I'd have some credibility. For now I'll just
have to see what I can manage with parsing the interfaces and then
look to see what I can do to help with GPC if I can get far enough to
make most things work.
More information about the Gpc