Waldek Hebisch wrote:
Frank Heckenbach wrote:
Waldek Hebisch wrote:
Another possibility (used in Modula-3) is two have two kind of types: one which uses structural equivalence, and another (called "branded" in Modula-3) which uses name (declaration) equivalence. More precisely, to check is types are compatible one recursively checks if structure matches, stopping on primitive or branded types
More precisely, if both involved types are primitive. If one is and the other isn't, we proceed with structural matching, right?
I do not remember the exact rules used by Modula-3. But reasonable rule is:
compatible (t1, t2) if t1 = t2 then return true; if branded(t1) or branded(t2) then return false; if composite(t1) and composite(t2) then return match_components(t1, t2) else return match_primitive(t1, t2);
Note that branded type is always incompatible with unbranded one. Otherwise it is too easy to break protection of branded types.
I hope this won't be too strict. (I can't think of a good example right now. I guess I'd have to test it on my code base when implemented ...)
Also, it is much nicer if compatibility is transitive.
True.
(primitive types have their own rules, different branded types are incompatible).
Actually, structural equivalence is IMHO the only sensible choice for array slices -- otherwise one gets too many spurious type errors.
Indeed, this could be a good solution for both problems. In BP mode (more precisely, in {$T+} mode -- thanks, Chief, for pointing out this fine point I wasn't aware of), all pointer types would be "unbranded". In default mode, explcit pointer types would be branded, but the result of @ would not (so, due to the rule above, it would be compatible with p1 and to p2, but p1 and p2 wouldn't be compatible with each other -- seems kind of sensible, perhaps that's also how Mac Pascal behaves?).
I am affraid that I prefer branded pointer to be incopatible with unbranded one. Then we need branded pointers in ISO modes and unbranded otherwise.
Yes -- that's why I thought otherwise, then we could have branded pointers in default mode.
I find it rather confusing if using value stored in a variable wuld be forbidden by typing rules.
In some sense this also happens elsewhere -- e.g., an integer value stored in a real variable can't be used (from the variable) as integer anymore.
Bug list is an important tool for fixing (or mitigating effects of) bugs. It already happened to me to debug twice the same bug. I am sure I forgot some reports. The others forget too (recent "GPC alpha" thread is a proof).
I see. (Though in this case, did someone actually write fixed-bug entries for the bug-list?)
Since ATM you keep the bug list only you can give definite answer.
BTW, the bug list is a texi file of the GPC manual (todo.texi). You're welcome to add diffs to this file when you send me a patch. (I can easily handle overlapping diffs when I made some changes myself meanwhile.) I also try to make entries from relevant ChangeLog entries, but I think you didn't make these either in this case. And since you knew better than me what the actual problem (symptom and/or causes) were, as I hadn't tested on Solaris at that time, I didn't try to write anything on my own.
Frank