filter selection with entsel

Ken, I don't diasgree on trying to emulate natural Acad behavior. As much as
anything, I wanted to show the new guy a different kind of flow control
that's sometimes appropriate. That one tip would have saved me untold
maddening hours of wrestling with convoluted nested if's, if only I had
learned it a few years earlier.

With the exceptions Jason noted, probably all the commands that ask for a
single object pick will continue prompting until you pick something. (Maybe
there should be a modemacro message for this: "You have missed the object 17
times so far, please try again.") But AFAIK they'll all exit silently on
hitting a return, so for consistency it's also important that a while
construct allows this way out in addition to cancellation. I'm not sure
whether all the while variants offered did this.

Similarly, I think that all the commands that prompt for a selection set
will exit quietly on a null response, so that expectation should be
supported too. In one case, at least, justifytext will exit quietly if
nothing in the selection set is of an appropriate entity type.

I judge these things on a case by case basis, partly on the nature of the
function, partly on the programming complexity required (and whether I feel
the function warrants it), partly on user feedback. I'm much more likely to
give the user multiple tries at picking an object if this comes after
prompting for other input -- I don't want to make them repeat all that if
they miss the pick. But if the selection is the first interaction required,
then hitting a return to repeat the command can sometimes be a valid way of
getting another chance at the pick.

 

Doug,

I was surprised by the time difference in (null and (not.

I assume it's from the fact that NOT evaluates the symbol (See below).

From Help...

<CLIP>

NULL
Verifies that an item is bound to nil

NOT
Verifies that an item evaluates to nil

Typically, the NULL function is used for lists, and NOT is used for other
data types along with some types of control functions.

$ (mapcar 'null (list 1 (= 3 "3") nil "Steve"))
(nil T T nil) <END CLIP>

Can anyone expound more on NULL being used for LISTS and NOT being used for
other DATA TYPES and CONTROL functions?

Thanks,

Don Butler

 

Don,
It surprised me too. I am not sure why.
You might run your own tests to be sure. I
would have assumed no difference.

Tim,
Don't sweat it. We all have cranky moods.

Regards,
Doug

 

Consider what timing tests?

What code are you using to time execution?

 

The proper test for nil would be (not).

While some may view not and null as different, in AutoLISP they're
functionally identical. The null function exists largely for historical
reasons, more specifically because some early LISP implementations
did not treat the empty list and NIL as equivalent, and NULL was
required to determine if a list was empty.

And, for the performance nit-pickers:

(setq not null)

 

Thanks Tom, I've tried both while and cond and leanrned something new I can use as well for other application.
I didn't expect so many reactions and help.
thanks agin

 

Thanks, Tony. That helps to explain the reference to null being
traditionally used for lists, though your speed suggestion impies that not
and null are effectively interchangeable in this implementation.

I did indeed find a reference in an early lisp paper to null being a test
for an empty list. Somewhere I read an article which showed how the entire
(early) language could be built from about half dozen basic operations.
Probably by McCarthy or Gabriel. I can't find the reference now, but I'd
assume from your comments that not rather than null would have been one of
the building blocks.

 

Thanks for the info.

Don