left-expression && right-expression As is familiar, this first evaluates the left-expression to a boolean. If left is false, the answer is false and the right-expression isn't evaluated. If left is true, then the answer is the result of evaluating the right-expression to a boolean. Either expression may define new variable names. These variable names behave only according to the left-to-right visibility rule stated above. If the left expression is true and defines variable names, these definitions are visible on the right. If the right expression is also true and defines further variable names, both are visible after the && expression. For example, in if (nm =~ `@base.e` && base size =~ sz ? (sz > 0)) { the left expression checks that the file name, "nm", ends with ".e", and if so defines the variable named "base" to hold the part before the dot. The right side checks that the size of base is greater than zero (to exclude the file named ".e"), and if so remembers this size in the new variable "sz". By being able to easily hold on to the answers to our questions (like the size of base), we can avoid asking these questions redundantly. As explained in Capability Programming Patterns, often the best way to avoid getting confused by inconsistent answers from an object you don't trust is to avoid asking it redundant questions. *** expansion to kernel
|
||||||||||||
Unless stated otherwise, all text on this page which is either unattributed or by Mark S. Miller is hereby placed in the public domain.
|