It seems like it has the advantage of avoiding the progn in the if-condition-progn method.
No - you dont really avoid using progn - in some cases you might be not sure what some of the evaluations return, see MP's (reply #1) - so more stable wrapping would be:
(and
(CONDITIONAL STATEMENT)
(progn
(DO THIS)
(DO THIS ALSO)
)
)
If one of the "do this" expressions returns nil, the next expressions won't evaluate.
Yes, thats the "trick" behind it - to test multiple expression(s), before evaluating the next - to prevent any invalid argument errors.
Say you wanted the user to select at first two circles:
(setq circle1
(car (entsel "\nSelect first circle: "))) ; if something is selected, continue.. (member '
(0 .
"CIRCLE") (entget circle1
)) ; if its a circle, then continue... (setq circle2
(car (entsel "\nSelect second circle: "))) ; if something is selected, continue... (member '
(0 .
"CIRCLE") (entget circle2
)) ; if its a circle, then continue... ; Now do something like match the radiuses/move one of the circles
; depending on the amount of evaluations, that no longer require testing (progn) might be required
; if we care about the overall boole return use (progn <expressions> T), to report that its been successful
)
It even seems like it can serve as a form of error trapping.
Serves a purpose of "argument checking" or "error preventing" would sound more correct IMO.
"error trapping" is a whole different category of lisp.
This may or may not be good depending on the application.
You just must know what you are doing, so that sounds dumb for me - sorry.
Any comments/pitfalls/alternates to this method?
I do it often, as a quick test to start-off some idea for a program/subfunction or just to help someone on the forum.
Sometimes I translate that code using the (cond ( (not <expr>) (prompt <msg>) ) ..) technique, because it looks more final to me.
But personally for me, thats the best, simple and readable approach for argument checking.
Sorry for the lengthy answer, I just find your threads interesting.