samiam95124
commented
1 year ago Expanding on previous remark:
So the typing system can produce some pretty ridiculously long identifiers. We already store an "abbreviated name", which is the symbol without the type trailer. So I propose adding a "instance number", which is simply the number, from 1 to N, at which duplicates were encountered in the symbols deck. Obviously that only applies to routines at the moment, but who knows.
The debugger can reference such overloads like "MySymbol@1". Its not ambiguous because all of the overloads with type spagetti start with a "p" or "f" (procedure or function), like "MySymbol@p_...". The numbering will be repeatable as long as the order of overloads in the source don't change, so the system is about as good as if we had used instance numbers instead of type spagetti.
The debugger can make this usable by adding the instance number to symbol dumps, and keeping the different overloads together in listings.
Is it confusing? Well, no more than it would have been with other methods. The debugger can list and use abbreviated names (typeless), and can detect whether or not overloads exist by checking if it is so flagged. This means, for example, MySymbol, MySymbol@1 and MySymbol@p_... all refer to the same routine. Ie., if the program has no overloads at all, its transparent, the complication is only there for overloads. I don't think it is any different in C++ programs.
The debug mode was fixed to ignore type digests at the end of routines. However, it still can't handle overloads properly. It needs to detect if an overload group exists. I suggest detecting on block definition by doing a search on previously registered blocks and setting a flag on overload group members.
When a block is specified (like 'b rot') we check for overloads, and give an error if the specific overload is not given. Also we should have a system to list the overloads, and perhaps a number select system to simplify selecting them, without writing out the full digest.