Updated April 2010
The /LF (List File) switch, added in COMPIL.LIT 1.0(119), creates a consolidated list file showing all of the source, with all of the ++include files merged in. Each line of the source is marked with the internal location counter, which is how BASIC errors report their location when a program is compiled without line numbers. This can be quite handy in tracking runtime errors, eliminating the need for inserting line numbers and other kinds of traces. Note that:
• The list file will be named <prog>.LSX (LiSt with indeX)
• /LF may be abbreviated to /L (for the LIT interface only; for the native compiler implementations, use –lf)
Comments
Now that the /LF switch provides a means of cross-referencing "location counters" with source statements, the location counter of the last error has been added to various error messages, including the TRACE=BASERR log message and XCALL ERRMSG (DERR).
Also, a new err(8) function has been implemented to retrieve the location counter corresponding to the last error. Note that by convention, location counter values are displayed in hex, but the Basic PRINT statement has no way to know this, so if you are going to PRINT the value of err(8) you should use MIAMEX,MX_OCVT, or the Fn'Dec2Hex$() function in the SOSLIB to output it as hex.
When the /LF switch is used (to create an LSX list file), unreferenced variables are listed at the end, as a convenience for those interested in clearing dead weight out of program. Note, however, that these are not errors, and in many cases, it isn't even desirable to remove them. For example, it is common to group misc variables under a heading, e.g.
MAP1 WORK'VARS
MAP2 X,F
etc.
Typically in the above case, there would probably be no explicit reference to WORK'VARS, but you couldn't just delete it without elevating the MAP2 variables beneath it to MAP1. So the new feature is only to be used a guide (or ignored) as you see fit.
2010 April A-Shell 5.1.1177, compiler edit 452
Compiler enhancement (edit 452) : To assist those want to use /M to identify any unmapped variables as errors (highly recommended to avoid bugs caused by mistyped variable names which are then auto-mapped if you don't use /M), actual map statements for the auto-mapped variables will now be appended to the bottom of the LSX file (generated with /LF). These auto-generated map statements may then be reviewed and copied back into the original program, so that it may be compiled with /M.
Obviously, if you perform this operation blindly, it doesn't buy you much since all of your misspelled and implicitly mapped variables will now simply become explicitly mapped. But the theory is that it will make it easier for you to review the auto-mapped variables for potential errors, perhaps by sorting them to locate variations of the same variable, or by looking them up in the original program to see whether the usage is valid. And from that point on, the ability to use /M will certainly save you time tracking down bugs in new development caused by typos in new variable names. If you tend to use the same common (and unmapped) variable names in many programs, you may want to move the generated map statements into a common ++INCLUDE module.
Note: in the case of implicitly mapped array variables, the array size in the LSX file will be left empty, leading to a compiler error if you try to compile without editing the MAP statement to specify the array size. This was a deliberate decision to force you to review such variables, since depending on the compiler's implicit rules for unmapped arrays seems like a particularly cordial invitation to chaos.
2010 April A-Shell 5.1.1177, compiler edit 452
Output now includes auto-mapped variables.