Waldek Hebisch wrote:
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:
As I wrote, I don't need to be convinced how strange current rules are.
BTW, it looks that current rules are a quick hack:
Yes, they are! Haven't I mentioned this often enough yet (in this and other threads)?
I think there's something strange about this discussion, so let me recapitulate:
There's no question that we need better rules in the long run. But it's also clear, as previous discussions have shown, that there are some controversial issues that need to be resolved, and then it will be some work to implement better rules.
OTOH, Adriaan's problem is not one of strange rules (AFAIK), but a simple performance problem that can probably be solved, or at least alleviated, without long discussions (or could have ... ;-), and with less implementation work.
That's why I initially asked whther you are interested in the general solution of this issue (and have the time and willingness to resolve the issues in discussions, and then do the implementation, I should have added)? As you replied: "ATM I would prefer to think more before implementing general solution.", I took this for a no, so I assumed we were talking about the quick fix only.
Anyway, I see 3 options now:
1. Do a quick fix (you or me), without changing the rules. (And do the whole thing sometime later.)
2. Do a quick fix, with changing the rules. I explained in my previous mail why I dislike this. (Of course, you may disagree, but I don't think you've said that/why you think that changing the rules a little now, and more later, would be useful.)
3. Do the whole thing, resolve controversies etc. (you -- I don't have time for it anytime soon), of course with changing the rules.
Which one are we talking about?
Now talking about the whole thing (which I'd actually rather not do now, unless you really want to implement it soon):
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.
(And different types can have the same name, say in different modules.)
OTOH function arguments always have names and look nicer in error messages.
Indeed, for error messages we should make some effort to get reasonable names, but it may not have to be perfect. The identification will *then* surely be by types, not by names. That's always been clear to me, and I don't think I've ever said otherwise, neither in previous threads, so why are we discussing this again and again?
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.
Then we'd need to know the exact types we search for, so if (later) we want to implement closest-match rules etc., we'd need to normalize types in a way that guarantees that all possibly matching types will be found. Sure, it's possible, but probably not the least-effort solution. (Yes, I know, more effort can be justified by performance issues, but compared to the current way with c n^2 and a large c, maybe anything else will just be fast enough for any reasonable code ...)
I thought about OPERATOR_DECL because we have this as a placeholder anyway (which currently doesn't have much other purpose), and we often look up the operator name before anyway, so it would reduce the search space by the number of operator symbols (not important for a hash table, but for other implementations). And it could take care of scoping with little effort -- if we decide we want that.
Apropos remove imported operators: I suppose you refer to local imports. So we have scoping issues regardless of whether we restrict operator declarations to the global level, don't we?
Frank