Understanding AutoLISP as a LISP

It took me a while to realize that almost all the examples of AutoLISP I saw and most of what I had written did not match the LISP style, conventions and mindset. It really wasn't until I heard about the book "Structure and Interpretation of Computer Programs" by Harold Abelson and Gerald Jay Sussman that I realized there was an entire world of LISP ideas out there.

Traditional LISP examples typically follow a functional style. You don't tell the computer what to do. Instead you list the problem and let LISP evaluate to a solution. For example:

> (+ 2 3)

5

Here you enter(+ 2 3) on the command line and AutoLISP evaluates the form giving the result of 5. The first symbol after the parenthesis is the function name. The rest of the items after the function name are the arguments passed to the function. The ">" in this example is the prompt. You don't type it on the command line.

Functions can be nested as well:

>  (+ 2 (+ 4 5))

11

Here(+ 4 5) is resolved first giving 9, then (+ 2 9) is resolved next giving 11. This is the idea and philosophy behind LISP. Simple. Programmers typically state their problem and let LISP resolve it to a solution. This is also called functional programming.

I would say most AutoLISP code is written in a procedural programming style. For example:

> (defun solveMe ( / )

>    (print (+ 2 3))

> )

SOLVEME

Here we are defining a function called solveMe using the command defun. After we define the function, AutoLISP returns the name of the newly created function SOLVEME. The function is run by entering (solveMe) on the command line.

Notice the closing parenthesis is in line vertically with the opening parenthesis. This is not traditional LISP style but it is the common AutoLISP style. It is what you would find in Pascal, C++, C#, Java or any curly brace language. The idea is that the parentheses form a block of code. You can easily see where the blocks begin and end by lining up the parentheses.

The other thing to notice is that you are telling the computer to do something. This is a procedural style. Do this. Do the next thing. This is typical of macros where you are trying to reduce a series of steps into a simpler step.

In traditional LISP style you would just indent the next line and collect all the closing parentheses until the last line.

> (defun solveMe2 ( / )

>    (print (+ 2 3)))

SOLVEME2

> (solveMe2)

55

Actually this is not pure functional form.  The goal is to have everything flow through the parentheses. print writes to the command line outside the evaluation result and so is considered a side effect. Pure functional programming does not like side effects. If you are wondering, the first 5 was printed to the console, the second 5 was returned by the function.

> (defun solveMe3 ( / )

>    (+ 2 3))

SOLVEME3

> (solveMe3)

5

To make this function useful, the 2 and 3 can be passed to function when it runs:

> (defun solveme4 ( a b / )

>    (+ a b))

SOLVEME4

> (solveMe4 2 3)

5

You can now reuse this function with any two values! 

> (solveMe4 4 5)

9

> (solveMe4 2 (solveMe4 4 5))

11

This is the basics of using AutoLISP in a functional way. Enjoy!

AutoLISP vs Revit Family Editor

I just finished a large project in Revit. My task was to create a Revit model to match the existing lobby and 2nd floor of a historic building. Lots of granite archways and stairs meant lots of custom families.

That got me to thinking how close the Revit family editor was to AutoCAD AutoLISP. Where the Revit family editor is visual programming, AutoLISP is text. The more I use the Revit family editor the more I realize that I can do the same things in AutoLISP for AutoCAD. The important thing is to create a framework that allows simple creation and manipulation of objects through AutoLISP.

I know. AutoLISP is the "old" macro language for AutoCAD. I am told I should look at the AutoCAD .NET API that lets me do cool things. I still prefer AutoLISP though. It seems there is more there than meets the eye.

Using AutoLISP as a LISP. That is what this blog is about. I hope you will join me in this exploration; mining the past LISP knowledge to see if it can inform the present and even improve the future. Welcome aboard!