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 
the desire.

>  > 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 
CW.

>  > 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.
    Peter.
-- 
<http://www.interarchy.com/>  <http://download.interarchy.com/>




More information about the Gpc mailing list