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. Also, it is much nicer if compatibility is transitive.
(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. I find it rather confusing if using value stored in a variable wuld be forbidden by typing rules.
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. On the list we had description of the problems and fixes, but no text specifically for bug list.
Frank Heckenbach wrote:
I wouldn't object to someone else maintaining a bug database, but I'd ask for one thing: To keep it current, especially WRT fixed bugs (so just the other emphasis than what Waldek asked for). I think nothing is more harmful to a project's reputation than a list of stale bugs which have actually long been fixed.
More harmful is when the bugs are not fixed and users discover them only when trying software.
Sure. But actually I spend as much time working on GPC as I can afford, and I assume the same goes for you. So it would just be a question of fixing one bug vs. another one, and which one will affect users more seriously later is hard to predict. Of course, I agree that not fixing bugs is not good, but I doubt whether any administration effort will make a big difference.
To be clear: my comment about bugs discovered by users was triggered by my experience with some other packages (not GPC). I agree that bug list will not make a big difference. But IMHO a little improvement is still worth the effort.
I try not to lose bugs, often just by keeping relevant mails around, but I don't always get to writing a proper entry in the bug list -- which is not as trivial as it sounds, as many of the discussions are not clear bug-reports, but often a mixture of proper bugs, questions, unexpected though correct behaviour, and wishlist items, and sorting this out, and (for the latter cases) deciding what to do actually, is more work and sometimes requires further discussion. In fact, not seldom the discussion process takes much longer than the actual implementation after something was decided upon. And during the discussion, what should actually be put in the bug list? Only the minimally necessary (here, EP uncompliant type-checking in a particular case), or a vague description of the real issue ("better type-checking rules for various cases") ...
Very short description + pointer(s) to report/discussion