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
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
and hitting the
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
could loop, i.e. you could create an arbitrary amount of rectangles;
hence the need to explicitly
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
- 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
extrude commands 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
. Back then,
the Common Lisp standard had not been finalized and our Lisp
implementation did not provide
yet. And thus,
CoCreate Modeling's Lisp evaluator extensions were born.
To be continued...
Zu essen gab es in jenem Restaurant kroatisch-serbisch-italienisch-schwäbisches Crossover,
und für Unterhaltung war auch gesorgt:
You may have guessed it: The whole set_pers_context business in the
first part of this mini-series
was actually a red herring. I promise I won't mislead you this time -
and I'll even reveal the reason why the series is titled "And...Action!"
No, we don't need contrived constructs like (print extrude)
to show that
is somehow... different from all the other kids. All we need is a simple experiment.
CoCreate Modeling's user input line: The Extrude
unfolds in all its glory, and patiently awaits your input.
Now try the same with
: All you get is an uncooperative
"Lisp error: The variable PRINT is unbound"
. How disappointing.
But then, the behavior for
is expected, considering the usual
for Common Lisp,
particularly for symbols. As a quick reminder:
- If the symbol refers to a variable, the value of the variable is returned.
- If the symbol refers to a function and occurs in the first position of a list,
the function is executed.
& friends belong to the symbol jet-set in CoCreate Modeling. For them,
the usual evaluation rules for functions don't apply (pun intended).
Using symbol properties
as markers, they carry a backstage pass and can party anywhere.
For members of the
posse, it doesn't really matter if you use them as an
atom, in the first position of a list, or anywhere else: In all cases, the function which
they refer to will be executed right away - by virtue of an extension to the evaluator
which is unique to CoCreate Modeling's implementation of Common Lisp.
You can create such upper-class symbols yourself - using a macro called
This macro is also unique to CoCreate Modeling. Functions
are called, you guessed it, action routines
But why, you ask, would I want such a feature, particularly if I know that it breaks with
established conventions for Lisp evaluation?
Well, precisely because
this feature breaks with the established rules.
To be continued...
Yesterday, Opera 10 was released, with a lot
of interesting features, and so I hit the "Check for Updates" button in my (admittedly really old)
v9.01 installation of Opera.
Seems like I should have upgraded immediately after the press release was out, and that by waiting another
day I missed a whole slew of additional releases:
PS: Yes, I know, this is old hat
, but the message still gave me a good chuckle
One of the more, uhm, challenging customer suggestions I ever had to deal with was a bug report
which requested that CoCreate Modeling should somehow - in Nostradamus fashion- sense that it
was about to crash at some point in the near future.
Yes, that's right; CoCreate Modeling was supposed to alert the user before
an actual crash
was about to happen - by applying rocket-science dynamic program analysis and prediction
techniques, sacrificing chicken and roasting them on Intel CPUs, or by having programmers dance
naked around bonfires of compiler manuals. Whatever it would take.
No doubt that such a feature would be highly valuable. Imagine working on a model for
several hours, and then you drive the application into a crash, and both the application
and your model data disappear forever. If you could predict the crash, you'd save everybody
a whole lot of time and money. Oh, and with such code, you'd always win the lottery, too.
Fortunately, CoCreate Modeling has always had pretty elaborate crash handling mechanisms. Whenever an unexpected exception occurs, a top-level crash handler catches it, pops up a message describing the
problem, causes the current operation to be undone, restores the 3D model to a (hopefully) consistent
state, and returns the user to the interactive top-level loop so that s/he can save the
model before restarting.
Over time, we taught our crash handler to deal with more and more critical situations. (Catching stack overflows and multithreading scenarios are particularly tricky.) Hence, users rarely lose data in
CoCreate Modeling even if some piece of code crashes. Which pretty much obviates the need
for the proposed clairvoyance module.
Let’s suppose you had written this test case for low-level
DDE communication in your product, and that this test talks to Internet Explorer via DDE.
Let’s assume you’d do this by sending a URL to IE via DDE, and that you’d then verify the result by asking IE which page it actually loaded.
Let’s say that you’d use the URL of your company’s website, http://www.cocreate.com
The day your QA people start yelling at you because the test fails miserably, you know
that your company has been acquired, and that all accesses to http://www.cocreate.com
have been automatically redirected to http://www.ptc.com
Previous month: Click here
Next month: Click here