Waldek Hebisch wrote:
Frank Heckenbach wrote:
Waldek Hebisch wrote:
OTOH I think that I can quickly make the search cleaner and faster by associating operators with types. Namely Apple interfaces generate many alias names for types and GPC spends quite a lot of time searching for all pairs of aliases. Also, for many types there are no operators defined, and current GPC still is doing the full search. A flag on types should be enough to prevent such search.
But this flag must be consistently preserved in variants, ordinal subtypes, etc. I'm don't know offhand how hard this is. Even if it's not so easy and we don't do it, I think we can gain some speed, as I described above -- make use of OPERATOR_DECL, also as a step towards the real solution later, and avoid ACONCAT and get_identifier. This should reduce the constant factor considerably (pointer comparisons instead of string operations) and make the complexity dependent on #typenames * #operators instead of #typenames ^ 2. Provided #operators (per symbol) << #typenames (per operator argument type), as I understand is the case here, this should be quite a bit faster.
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?
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 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).
Frank