It comes with time. What I'm trying to get at is this:
If, natively has three parts. A test of true or nil (false) and one or two things to do in either case. We've covered that.
Cond, as you've stated performs multiple tasks based on a test that results in true. If there are multiple test statements in cond and all result in a true value, only one will be processed. Regardless of that, in the if statement there are only two options, BUT they can be nested, i.e.
(if (= a b)
(if (= a c)
(if (= a d)
(progn
(if true in all three cases do this)
(you could also put this in as something to do for true if you wrap it in a progn, as you see)
);end progn
(do this if a is not equal to d, but is equal to c and b)
);end if
(do this if a was not equal to c, but is equal to b)
);end if
);end if
Note: there is something to do in case of nil in both nested if's. There is also a progn. The progn will make if work similar to cond in that it will perform more functions. That is what I want you to see. The quote from the John McCarthy link I sent you to earlier, that I quoted in my post, mentioned cond's progn statement. This is telling me that cond is similar to if in that it too needed a progn function to act like it does, but John McCarthy embedded that within the cond statement. Last thing: in the above example what would be the return value of IF, if a is not equal to b?
I don't want to confuse or frustrate you. I'm sorry if I do. As far as understanding things conceptually... I, and most likely everybody else, has the same problem. It is only through testing code that you will begin to really understand what works and what doesn't work in programming. From your writing, you seem to be native to a language other than English. When you started learning English or any other language for that matter, was it possible to read and understand concepts of the language and then jump out and speak fluently? No! I highly doubt it. You had to test the language and make many mistakes, before getting to the level with which you could speak or write fluently. Programming is the same way. You can do all the reading you want, but until you try it out, test it out and realize the return values of each function, nobody will ever learn it.
What CAB just said about finding code and testing it, look under the Show Your Stuff forum, here. Copy the code, even if you don't understand it. Test it, and ask questions in this forum about it. CAB has recently, since this board has been up, really started to branch out with greater understanding of lisp. I learned some new stuff back in April that pushed me beyond where I was before that.