Peter N Lewis wrote:
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.
Ok, so if I understand that correctly, if there are features in CodeWarrior Pascal that can be implemented without conflicting with other dialects, that would be the sort of thing you'd want to see added.
Well, unless there are other problems with them (such as the case-sensitivity issue below).
These might include:
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.
making the "implementation begin" optional in interface only files.
You mean omitting the word `implementation'?
Should be ok, AFAICS (does anyone else see a problem?).
What do you suggest for features that do conflict, but that are used widely in existing code?
We must discuss them in detail, I can't give a general solution.
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 ...).
One of the useful places I think is for writing functions that take opaque record pointers without having to muck with casting everywhere. Eg, the interface might be:
type UserDataPtr = Pointer;
type OurData = record blah blah blah end; OurDataPtr = ^OurData
function CreateOurData( var data: univ OurDataPtr );
Then the users of the unit can use UserDataPtr and never have to worry about accidently accessing the internal records and the local unit can use the data without having to cast every input parameter.
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.
Where it is typically used in the Mac world is for Handles (which is just a pointer to a pointer, type Handle = ^Ptr, but it's a useful type in that you can resize a Handle without breaking any references to it). So you might have:
type OurDataHandle = ^OurDataPtr;
and be able to pass it to a standard function like:
function ResizeHandle( data: univ Handle; newsize: Size ): OSError;
ResizeHandle could just have data: Pointer, but that gives less information and requires casting in ResizeHandle to access as a generic system handle. Using data: Pointer is no more or less safer than using data: univ Handle.
This in turn looks a bit like EP schemata, yet another completely different thing.
It is possible some of the benefits can be got using restricted records, but I don't think that works for cases where you want to write generic routines where Handle is treated something like a super class (excuse the misuse of terminology) of all Handle types.
And now we have OOP!? ;-)
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 ...
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.
Yeah, I agree with the qualms on this. It would make the interfaces a heck of a lot cleaner than adding asmname for every single function. This is the sort of thing where I would use a compiler directive {$asmname-asgiven} {$asmname-lowercase} {$asmname-underscorelowercase}. It's not generally a good idea, but under certain circumstances it would simplify life, which to me sounds like a good type for a compiler directive.
Well, if it's only (or mostly) needed in the system interfaces, converting them would be a one-time change (mostly automatic, with a script like the one I posted) whereas a compiler change would stick around, have to be maintained etc.
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).
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) ...
Frank