Topic: "and" versus "if"

[Peter2]

I found this code

Code: [Select]

(and (= f ".") (setq Dirs (cddr Dirs)))
(foreach n DirsNow there is no second condition, and so I wonder why it is not:

Code: [Select]

(if (= f ".") (setq Dirs (cddr Dirs)))
(foreach n DirsThe only difference I see is that
- 'and' returns T or nil
- 'if' returns nil or the new value of 'Dirs'
but 'foreach' does not care about it ...

So what is the advantage of 'and' in this fragment?

[dgorsman]

Not much, aside from being easier to extend if additional conditions are expected in the future.  Other than that, its more of a style choice.

[owenwengerd]

In my opinion, (if) is better in this case because it is less likely to be misunderstood. However, I would write it more succinctly:

Code: [Select]

(foreach n (if (= f ".") (cddr Dirs) Dirs)

[irneb]

Not much, aside from being easier to extend if additional conditions are expected in the future.  Other than that, its more of a style choice.

With you on that .... though ....

In my opinion, (if) is better in this case because it is less likely to be misunderstood. However, I would write it more succinctly:

Code: [Select]

(foreach n (if (= f ".") (cddr Dirs) Dirs)

If you take Owen's post into account, a cond would probably sort out both scenarios. Easier to extend, yet still readable without special knowledge of how Lisp operates.

The only difference I see is that
- 'and' returns T or nil
- 'if' returns nil or the new value of 'Dirs'

That's actually a peculiarity of AutoLisp. In all other Lisps (at last those I've used) there would be asolutely no difference in this case. The and would return the exact same thing as the if does.

but 'foreach' does not care about it ...

Exactly. Any boolean test in Lisp (all types of Lisps) is a situation of: "Is it something else than nil? If so consider it true, else consider it false."

[ronjonp]

I use AND sometimes just because it keep all the code on one line when formatted. 

[Peter2]

Thanks to all for the interesting comments. My 2 cents for flexibility: 'If' can be modified with 'else-code', 'and' not ...

Have a fine weekend!

[CAB]

I use AND sometimes just because it keep all the code on one line when formatted. 

Ditto 

[Kerry]

Where's John when you want a good argument regarding if, and, or, cond.

[irneb]

Where's John when you want a good argument regarding if, and, or, cond.

  ... you could always go bonkers and make the code so obtuse as to mislead even yourself. E.g. what about converting each input into integers and then using logand on them? 

[irneb]

Thanks to all for the interesting comments. My 2 cents for flexibility: 'If' can be modified with 'else-code', 'and' not ...

Yes, that's a good point too. Yet another reason cond is more flexible (it can have multiple elses without needing to nest ifs).

[irneb]

Code: [Select]

(and (= f ".") (setq Dirs (cddr Dirs)))
(foreach n Dirs

Personally in your code example I'd simply remove the current directory "." and parent directory ".." a different way. But that's just me, I don't like relying on them always being the 1st 2 ... not that I've ever found them otherwise, but I've seen too many issues happen when relying on the order of a list. I'd have done something like this instead:

Code: [Select]

(foreach n (vl-remove "." (vl-remove ".." Dirs))
  ...
)Edit: e.g. what if the list of dirs is sorted? Could you still rely on "." and ".." to be the 1st two in the list?

[Peter2]

Edit: e.g. what if the list of dirs is sorted? Could you still rely on "." and ".." to be the 1st two in the list?

a) yes, it's sorted.
b) ... rely on ..- I think yes, because Dirs is a list of subdirs (it's not my code ...)

[irneb]

a) yes, it's sorted.
b) ... rely on ..- I think yes, because Dirs is a list of subdirs (it's not my code ...)

Well, in most cases "." would be at the start if you sort the list. It's supposed to be at the start on a raw list (as obtained from vl-directory-files). But if one of the sub-dirs start with a "strange" character (e.g. $ or any of those allowed with an ASCII code smaller than that of ".") it would get placed before the "." and ".." when sorted.

[Peter2]

.... But if one of the sub-dirs start with ...

Yes, thank you. That's an important argument.