Adriaan van Os wrote:
The variable-records discussion on this list has revealed the difficulties of checks on variable records. As a sidebar, I recall that Niklaus Wirth has replaced variant records later (in Oberon) with the much more powerful notion of type extensions. Type extensions can easily be checked, both compile-time and run-time.
True. In fact they're very similar to BP's object (which GPC supports) if you don't use any methods (and write `object' instead of `record', of course). Even the type test (`is') is the same in GPC. Only the syntax for the type guard is different [...]
May I suggest to allow in a future version of GPC to write "record" instead of "object" also ? That would be a clear and clean way to declare a record type-extension (in casu a BP-style object without methods), at the cost of very little work in the compiler (I guess).
Oh, we're talking about an easy syntax extension. I hope I won't start another Jihad. ;-)
Seriously, what would be the benefit of adding it? Compatibility for some existing code, or the guarantee that such records will not contain any methods, or anything else?
As for the implementation, it might be rather easy (and, of course, it would probably look like an object with a special flag attached internally). It would raise some questions such as, should inheritance between those records and objects be allowed (or only one way)? Should there be abstract "records"?
Oh wait, I think there's a problem: Objects contain an implicit "VMT" field to identify their actual type, needed for virtual method calls (no issue here), but also for the implementation of `is' and `as'. Since the base records in this scheme would be just regular records (syntactically), we'd have to add a VMT field to *every* record, which is practically a no-go for various reasons.
I currently don't see an easy way out. Unless someone has a suggestion, I think that kills it (i.e., there must be a syntactic difference between "inheritable" and normal records).
Frank