Frank Heckenbach wrote:
Waldek Hebisch wrote:
Maybe I was not clear enough: I want to associate definiton with main variant. Keeping the other rules as is we will have at most 4 searches for operators. Flag may reduce 4 to 0.
I'm not quite sure how you mean to do this, without changing existing rules (where the given variant is tried first, so currently one can have different operators for equivalent types of different names).
Say we have variants a and b of Integer, and operators + on pairs of a and of b. Currently they're stored as BPlus_A_A and BPlus_B_B and looked up by name. Associating both operators with the main variant (Integer) would give the same name and thus a conflict. Or am I overlooking something?
I wrote that I _want_ to change the rules. Two variants of Integer _are_ the same type, so current overloading really breaks normal rules.
A nice example how strange current rules are:
program foo4; type t1 = record i1: integer end; operator f (x, y : t1) = c : integer; begin writeln('outer f'); c := 1; end; operator f (x, y: char) = c : integer; begin writeln('second f'); c := 1; end; procedure p; type t1 = char; var c1, c2 : t1; begin writeln(c1 f c2); end; begin end .
the above gives me:
foo4.p: In procedure `p': foo4.p:17: error: incompatible type for argument 1 of `f (t1, t1)' foo4.p:3: error: routine declaration
so the search returns integer version, even though arguments are of char type and char version is defined.
BTW, I'm not trying to defend current rules, I'd just like to avoid changing them for a quick fix, when we know they'll have to be changed again. In the worst case, affected code would have to be rewritten twice within "short" time.
I think that fundamental rule is: overloading should depend only on types of the arguments, not on their names.
BTW, it looks that current rules are a quick hack: we need a piece of information which uniqely identifies a type and is propagated via interfaces. Name of main variant is first approximation, but some types it is not defined. OTOH function arguments always have names and look nicer in error messages.
I was thinking of storing a list of operators defined for a given symbol in a OPERATOR_DECL because (a) we'll probably need this anyway for the real solution and (b) this part should be uncontroversial (the question will be how we use this list later). The main implementation issues about this way are GPI handling (but shouldn't be too hard), and possibly scoping (that's why I started the other thread).
Well, we need a map: operator x type x type -> function. We may have a global list of all tuples, we can attach list to operator, we can attach list to types, we can use a hash table ... Whatever representation we choose we need to add/remove imported operators as needed.