Frank Heckenbach wrote:
I will try to be useful and fix gp myself. Compile times are also spoiled by the quadratic operator search (http://www.gnu-pascal.de/crystal/gpc/en/mail10055.html) and that is something I cannot fix easily myself (at some points in the compilation I see the IDE's progress bar and line counter move line by line, often lines with calculations).
I see. BTW, Waldek are you interested in the general solution of this issue (including overloaded routines)? I'm not too much ATM (there are many more urgent issues). If you aren't either, perhaps I could at least try some quick fix to ease this problem somewhat. -- Still using name-based search, with all its disadvantages, but perhaps storing a list of actually defined operators in the OPERATOR_DECL (this will also be a preparation for the real solution), and then for each operator retrieve the type names and compare them -- I suppose if we get rid of the ACONCAT and get_identifier in the loop this way, this might make things much faster.
As I wrote operator search is inconsistent with the rest of GPC. Namely, operator definition is associated with the type declaration (or, equivalently type name). I think that in principle we should still do a search, but only for _supertypes_ of a given type. Here by a supertype I mean bigger type for ordinal types and ancestor in case of objects (maybe we should also consider undiscriminated schema as a supertype of a discriminated one). I would say that operator "matches" if types of is formal parameters are supertypes of actual parameters.
If multiple operator match given arguments then we need some extra rules. If there is most specific operator, then we should use it. Otherwise we have to decide what to do -- there is semantic problem here, but I expect the list of "closely matching" operators to be short, so almost any method to resolve final ambiguity is likely to be fast enough.
Search on tuples of supertypes still may be slow (especially if we generalize the search to overloaded functions with multiple arguments), so we may need better algorithm and smarter data structures.
ATM I would prefer to think more before implementing general solution. 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.