I just realize one issue with user-defined operators that might not have been discussed here yet, shadowing. If an operator is defined in outer and inner scopes, say with different enough argument types, is the outer one still accessible in the inner scope (i.e., the inner one overloads the outer one) (a), or not accessible (i.e., shadows) (b)? If (a), what if argument types are similar enough? Will usual ambiguity resolution (or complaining) rules apply (c), or will the inner operator be stronger (d)? If (b), what about built-in operators? If something like + is overloaded with new argument types, the built-in + is still available (e). But if it's overloaded again in an inner scope, and the outer operator is shadowed, does the built-in operator remain unshadowed (f) or not (g). Of course, the same questions can be asked about function overloading as well. (c) that's basically what GPC currently does (where ambiguity resolution rules are name-based and first-match, which is bad, as was said before) (d) this might be more logical, as the relationship between inner and outer operators would be the same as between outer and built-in ones -- the latter come into play only if the former have no possible match at all (e) that's so in GPC currently, but I suppose also elsewhere, isn't it? I.e., defining one + operator doesn't shadow the built-in +. (f) if the outer operator shadows the built-in operator (by using similar argument types, say operator + (a, b: Integer) -- if this will be allowed at all), and the inner operator has completely different types, the built-in + for Integer would "reemerge" in the inner scope, very strange (g) one user-defined operator does not shadow a built-in, but two nested ones do -- also strange What do other dialects do about it? Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8