Yeah, short circuiting is an intentional design to save unnecessary evalutation. AND works that way too, though in reverse of course (first return of false kills evaluation).
Man, that's one thing that is so great about Lisp. You could, if you were looking for ultimate efficiency, easily write your own macro to see what kind of arguments you are dealing with and then generate the appropriate code - look up variables before function calls. It'd all be handled at compile time based on the arguments you are calling it with, so you'd suffer no runtime performance.
Anyways, your code will work as is but wouldn't it be possible for the animation function itself to increment an animation counter when the animation starts and then decrement it when the animation stops? This way you wouldn't have to call look-up functions to see if an animation is running - you'd just check the "AnimInProgress" variable.
Too bad inlining isn't an option or I'd say just inline your lookup calls and you'd have the best of both worlds - good efficiency and code clarity.
Simple, unless later on Mark decides to optimise Blitz by saying, hmm the second part of the OR is only a variable test, thus is quicker to check than the function so I'll do that first. That would break my code and lots of others I expect...so it's very unlikely :-) phew.
Man, that's one thing that is so great about Lisp. You could, if you were looking for ultimate efficiency, easily write your own macro to see what kind of arguments you are dealing with and then generate the appropriate code - look up variables before function calls. It'd all be handled at compile time based on the arguments you are calling it with, so you'd suffer no runtime performance.
Anyways, your code will work as is but wouldn't it be possible for the animation function itself to increment an animation counter when the animation starts and then decrement it when the animation stops? This way you wouldn't have to call look-up functions to see if an animation is running - you'd just check the "AnimInProgress" variable.
Too bad inlining isn't an option or I'd say just inline your lookup calls and you'd have the best of both worlds - good efficiency and code clarity.