In part 2 of the series, I broke
the news that so-called action routines (such as extrude) violate
Common Lisp evaluation rules in CoCreate Modeling. Which should cause
any Lisp aficionado out there to frown; after all, the evaluator is 
central to any Lisp implementation,
and largely determines the nature of a Lisp system. There is a reason why the 
Lisp-1 vs. Lisp-2 debate 
has been raging for decades!
So why did CoCreate Modeling insurrect against the Common Lisp standard?
Did we have an issue with authorities, did we want to stage a publicity stunt, or
were we just a bunch of imbecile script kiddies who didn't know any better?
Nothing of that kind. Instead, I put the blame on having too many users of
a successful predecessor product 
 
Let me explain.
In the 80s, our 2D CAD application 
ME10 (now: CoCreate Drafting) 
had become extremely popular in the mechanical 
engineering market. ME10's built-in macro language was a big success factor.
Users and CAD administrators counted on it to configure their local installations,
and partners wrote macro-based extensions to add new functionality - a software
ecosystem evolved.
A typical macro-language command looked like this:
 
Users didn't have to type in the full command, actually. They could start by typing in 
LINE 
and hitting the 
ENTER key. The command would prompt for more input and provide hints in the 
UI on what to do next, such as selecting the kind of line to be drawn, or picking points 
in the 2D viewport (the drawing canvas). The example above also illustrates that commands 
such as 
LINE RECTANGLE could loop, i.e. you could create an arbitrary amount of rectangles;
hence the need to explicitly 
END the command.
Essentially, each of the commands in ME10 was a domain-specific mini-language, 
interpreted by a simple state machine.
The original architects of SolidDesigner (now known as CoCreate Modeling)
chose Lisp as the new extension and customization language, but they also wanted
to help users with migration to the new product. Note, however, how decidedly un-Lispy ME10's
macro language actually was:
-  In Lisp, there is no way to enter just the first few parts of a "command";
     users always have to provide all parameters of a function.
-  Lisp functions don't prompt.
-  Note the uncanny lack of parentheses in the macro example above.
But then, we all know how malleable a language Lisp is. All of the problems above
could be solved by a fairly simple extension with the following characteristics:
-  Define a special class of function symbols which represent commands
     (example: extrude).
-  Those special symbols are immediately evaluated anywhere
     they appear in the input, i.e. it doesn't matter whether they appear inside
     or outside of a form. This takes care of issue #3 above, as you no longer
     have to enclose extrudecommands in parentheses.
-  Evaluation for the special symbols means: Run the function code associated
     with the symbol. Just like in ME10, this function code (which we
     christened action routine) implements a
     state machine prompting for and processing user input. This addresses 
     issues #1 and #2.
These days, you would probably use something like
define-symbol-macro. Back then,
the Common Lisp standard had not been finalized and our Lisp
implementation did not provide 
define-symbol-macro yet. And thus, 
CoCreate Modeling's Lisp evaluator extensions were born.
To be continued...
to top