Never need the double arctangent???
With apologies to Captain Renault, I'm shocked ! As the judge might say, ignorance of the trigonometric functions is no excuse!
However, I guess I'm not shocked that any seemingly innocuous refinement would break someone's code; if fact, that almost seems to be a given. And that the problem doesn't surface until months or even years later.
Usually I'm pretty careful about introducing keywords, typically adding a dot prefix to avoid this kind of conflict (which is why we have so many
dot variables and
dot functions). But that didn't seem like an option with
DATN(), which had apparently been part of AlphaBASIC going way back. (Maybe even to "the beginning"?)
So, what's the workaround? My first thought was that maybe we could treat
DATN as a non-keyword unless it was an array, i.e.
DATN(...). But if it's a sub-field of an array, I suspect that you have actual
DATn(...) references in your code. And the fact that you are using mixed case, while maybe technically providing a keyhole opening for a distinction, introducing case sensitivity for keywords would seem like a violation of an otherwise universal rule:
keywords are not case sensitive; variables are. Also, even if as a practical matter all your
DATn() references have only one dimension, using that as the distinction between a system function and an application array is just too ugly to consider (and would totally prevent the compiler from tagging an invalid number of subscripts).
If all of your
DATn references were in ++include modules, you could use the new
transclude feature to incorporate pattern substitution into the process, converting DATn to, say DATnx. But if you have hundreds of programs to update, that might not seem so attractive.
Another workaround would be to take this as an opportunity to learn the wonderful UNIX utility
sed, which you could combine with
find to make a single-line script that would convert all occurrences of
DATn in all of your files to something else. Given how powerful that is, you might spend many hours testing and refining your script to make sure it didn't have side effects, and then you'd have to recompile and perhaps redistribute all your programs. So, still a big operation.
Yet another workaround would be to revert to using the standalone compiler, in which case you could use a version prior to compiler edit 1014, and even create a COMPIL.DO that was command line and command file compatible with COMPIL.LIT. But, you'd be unable to access any language features added since then.
Other than that, I guess yet another switch could be added to the compiler, but it does seem kind of overkill for just one symbol. If going to all that trouble to add a compiler switch/feature, it seems like it should do something more generally useful. One idea that comes to mind would be to extend the
DEFALIAS statement to allow substitution of identifier names (whether keywords or variables), rather than just function names. You could then insert something like
DEFINE DATn = DATnx into your top-level common include (after first doing a global search for any occurrences of
DATnx. But I'd have to seek spiritual counsel as to whether that constituted a 7.1 enhancement rather than a 7.0 bug fix.
Any other ideas? Actually, I just thought of another: I suppose we could use a variation of a hack currently used with the identifier
DEBUG. I see now that the documentation fails to mention this, but if DEBUG appears as a mapped variable, then it is treated as such; otherwise it is treated as a keyword indicating the status of the SET DEBUG option. Even though it's a hack, it might just pass muster as a
refinement that can be slipped into 7.0.
Let me know what you think; in any case we should probably take some time to see if any better ideas surface before taking any rash action.
