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.