Visual LISP: Cool Tools in the VLIDE

The Visual LISP™ integrated development environment (VLIDE) language is very powerful. But any programming language is really only as good as the person using it. It's the GIGO principle coming into play—garbage in, garbage out. If you engage in some careless programming tactics, Visual LISP and AutoCAD® may just quit on you.

Restarting AutoCAD will reload the Visual LISP environment and you'll get back to normal quickly. But you're still going to have figure out what part of your code crashed the system. But why go there when Visual LISP provides you with a series of very cool tools that help you avoid this sort of problem altogether?

This article explores a few of the common problems programmers typically encounter when working in Visual LISP and how they can use the VLIDE to avoid them. We'll look at why the problem crops up, describe its consequences, and explore how Visual LISP helps you prevent that problem. By the end of the article you will have learned how to use several VLIDE features that improve your programming productivity.

Problem #1: Overwriting a Visual LISP Symbol

Suppose you have an application in which you utilize the length of some object. It is tempting, it may even seem the right choice, to use the symbol LENGTH in the code as a variable holding the value. Resist.

The symbol LENGTH is a subroutine in Visual LISP that is used to learn how many elements are in a list. If you program LENGTH to hold a numeric value, you change the link from the symbol to that subroutine and cannot recover the subroutine's location. In other words, you can overwrite LENGTH.

Later on, when you want to use LENGTH to call the original subroutine you won't be able to. Or perhaps you never need to use LENGTH as originally intended, but what happens when someone else's application is run along with yours and that application calls LENGTH as originally intended? Right, a system failure and a complex problem to solve.

It doesn't end with LENGTH. You can also overwrite these Visual LISP symbols (this list is not comprehensive): SIN, COS, T, SET, ABS, ANGLE, DISTANCE, EXIT, FIX, LAST, LOG, MAX, MIN, MEMBER, PROMPT, REM, TRANS, and TYPE. Two tools in Visual LISP help you avoid overwriting symbols. We'll look at only one tool here because the other one has additional benefits that we'll take up a little later on (see Problem #5).

When you are first entering a program into the Visual LISP editor, the code is color-coded. Comments contain a darker background, strings are in magenta, and the built-in symbols are in blue.

That said, pay particular attention to the color blue. You should never see a blue-colored symbol name next to SETQ or DEFUN in a completed program. If that does occur, you have overwritten the original subroutine for that symbol. But remember that the color may also change as you type in code. For example, if you used the symbol name FIXED, then the characters will turn blue when you enter FIX, but will immediately switch back to magenta when the E is added.

Changing the colors of objects in the Visual LISP editor is taken up in Problem #3.

Problem #2: Putting a Parenthesis in the Wrong Place

Now let's return to that frustrated definition of LISP (used in an earlier tutorial) as "Lost In Stupid Parentheses." The charge has weight because it is so easy to introduce a parenthesis character into the wrong place. As you know, in Visual LISP parentheses are used as logical delimiters in the code as well as being used in data lists. Unlike other programming languages such as BASIC or C++, which require semicolons or line breaks to define logical lines of code, Visual LISP allows programmers to define their own format for these lines. This feat is achieved through the use of parentheses. Of course if they're in the wrong place, your program will not run correctly no matter how nicely it is typed in.

As you enter programs into the text editor, the parentheses are matched whenever the closing parenthesis is used. The display shows the matching open parenthesis at this point. But this happens quickly, and you may not notice the inclusion of an extra parenthesis or that you are missing one. To hunt for misplaced parentheses, use the Control key with the open bracket and close bracket keys—that is, [ and ]. We'll look at these key combinations in more detail in Problem #4.

An even faster way to find where the logical flow of the program has run into trouble is to use the Format Code in Selection tool in Visual LISP, which you activate by first selecting the text to be formatted and then engaging the tool. There are three ways to engage the tool:

• From the VLIDE main menu, select Tools > Format Code in Selection.
• Use the Control-Shift-F key combination.
• Select the Format Selection icon (the shaded 3-4-5 triangle icon) from the VLIDE toolbar.

I've always said that Visual LISP is self-encrypting, by which I mean that you can write a routine without any indentations then look at it a few days later and be puzzled by what it does. Here is an example. How quickly can you spot the improperly placed parentheses in Listing 1? Listing 2 contains the same code as Listing 1 but was passed through the Format Code option. Listing 2 is much easier to read and points to the problem with the (CADR p2) expression. Listing 3 shows the code with the parentheses in the right places.

Listing 1:

(setq A (- (car P1) (car P2))
B (- (cadr P1) (cadr P2) S (sqrt
(+ (* A A)) (* B B))))

Listing 2:

(SETQ a (- (CAR p1) (CAR p2))
b (- (CADR p1) (CADR p2) s (SQRT
(+ (* a a)) (* b b))))

Listing 3:

(SETQ a (- (CAR p1) (CAR p2))
b (- (CADR p1) (CADR p2))
s (SQRT (+ (* a a) (* b b))))

You may also have noted that the case of the symbols changed between Listing 1 and Listing 2. You can fix that easily by applying a series of rules, grouped under Format options, that enforce code consistency.

Problem #3: Omitting a Double Quote for a String

Unbalanced parentheses result in errors in program structure. But even worse, when the string delimiters are wrong, the entire program becomes a text message—and not a very decipherable one at that. VLIDE uses double quote characters (") to mark the beginning and ending of a string. If your application involves a lot of string manipulation, such as dimensioning utilities do, you can easily misplace or forget to place a double quote. This is particularly the case when you're creating dimensions where the double quote may denote inches. (The solution here: Use the back slash with the double quote when you want to include the double quote in the middle of a string.)

Looking at long strings of text for missing characters in a printout goes beyond tedious. But inside the VLIDE it is difficult not to see them! The reason is the color-coding of the source code in the text editor. By default, the color code for text constants, including the double quotes, is magenta. By looking at what is colored magenta and what is not, you can quickly isolate a misplaced quote or determine where you need to add one. In fact, it is difficult to enter the program without noticing that you have misplaced one since the code changes colors as you balance the double quotes. Skip the printout.

Color-coding is a nice feature and the default color scheme VLIDE uses is pleasant. But what if the colors just don't work for you? Not a problem, but don't assume you can adjust them in the Format options dialog box shown in Figure 1. You must access a completely different dialog box:

1. From the VLIDE main menu select Tools > Window Attributes, which displays a sub menu.
2. Select the Configure current menu option to open the Windows Attributes dialog box (see Figure 2).

In this dialog box, you can set the colors for each of the items recognized by the text editor—strings, numeric constants, built-in symbol names, and so forth. You can even change the colors of the text editor itself. If you don't want any color, clear the Lexical Colors check box.

Problem #4: Using Too Many Parentheses

This problem is obviously related to using too few parentheses. But once again it's all about balance. Use indentation to set off blocks of code for easier viewing and problem correction. Or search the code using the possible key combinations—of Ctrl plus the open and close bracket characters—listed in Table 1.

With these key combinations, you can easily move through a nested group of parentheses to find the missing or extra ones.

When I do this, I often start by placing the pointer at the first parenthesis in the function (or at the final parenthesis). Then I use the Ctrl plus bracket keys to move through the function list looking for one that does not balance correctly. That is a quick check and does not require much time.

The next step is to go to the suspected function (or start at the beginning or end again) and find the innermost expression.

After locating the innermost expression, I then use Ctrl plus the bracket keys to jump back and forth to each nesting level to see if the expression makes sense. The Highlighting option (use the Shift key) make reading nested functions much easier.

Problem #5: Making Parameter and Simple Syntax Errors

Every computer programming language has its own unique syntax and procedures for getting things to happen. Visual LISP is no exception. If you don't use the right data types or you supply the wrong number of parameters to a function you get an error result. Likewise, all computer languages have a compilation phase in which the source code is converted to object and, ultimately, machine code. At that time the parameters are checked and syntax errors reported. Normally this happens only as the source code is converted to the object code.

Once again Visual LISP is unique in that it checks a function's parameters and syntax at several places—for example, at the time of evaluation or runtime for the program or when it creates FAS files as part of a compiled project. You can also request a check of either just a selection of items or the entire contents of the text editor. The syntax check will alert you to basic problems with the code such as the incorrect use of built-in symbols.

Even so, the syntax checks in Visual LISP are not very robust in comparison to the ones you find in other programming languages. And once again, the difference amounts to a trade-off—one I think is worth making. You can have the flexible programming environment you find in VLIDE, or you can have a more structured language that performs robust syntax checks but is not nearly as flexible.

As I said earlier, the dynamic nature of the Visual LISP language enables you to define symbols to anything at any time. In addition both programs and data are stored in the same manner and can be intermixed only to be untangled at runtime. No other modern computer-programming language offers features that powerful.

Quite often, the very structure of a program changes significantly between design and the actual runtime. An example would be the value of a symbol. At the start of a function it may be an integer, then it may change to a string, and then to an entity name as the result of a series of SETQ expressions (this happens frequently when you program using a common temporary variable name such as TMP). As a result, a syntax checker in Visual LISP can only test the parameters sent to the built-in functions to see if they match in count to what is expected. It can also check for rules violations, for example, overwriting a built-in symbol subroutine or misuse of parentheses. These two checks ferret out many problems novices encounter. As such, the syntax checker is highly recommended for beginners in order to review code in a search for errors. Run the syntax checker when you complete the definition of a function or when importing code created outside the VLIDE. You may catch some of these errors before even trying to run the program.

When the checker has completed its tasks, any problems it has encountered are displayed in the Output window of the VLIDE (Press Ctrl + Shift + O to view this window when VLIDE is open). Double-click the error description and the text editor window opens with the cursor in the area where the problem was detected. I say area because sometimes the cursor is placed at the nearest parentheses set when imbalances are detected and that may not be where the problem is actually located.

Conclusion

The VLIDE does not solve all the problems a Visual LISP programmer encounters. But it does solve the majority of those that students and others first learning the language encounter. And because you can create a standard code style with VLIDE, you're going to avoid any number of problems from the very beginning. As a veteran AutoLISP® programmer who even went so far as to write his own text editor, I can say that the tools provided in the VLIDE save me time and effort. In my view the VLIDE is the best choice around. That's not to say that it has everything. I can always dream up a new-feature wish-list.

Until next time, keep on programmin'.