"Contrariwise,"
continued Tweedledee,
" if it was so, it might be;
and if it were so, it would be;
but as it isn't, it ain't.
That's logic."
- Lewis Carroll

To elucidate a manner in which ColdFusion programmers can write better performing, cleaner, and more sensible applications, this article will illuminate the noncoincidental relationship between the discipline of logic in philosophy and the writing of ColdFusion applications. Understanding this relationship will help you approach application flow management in a lean and efficient manner.

I've purposefully kept this article abstract, since it works at the conceptual level. The ultimate point is to apply the principles set down.

This is not an apology for a new framework; it's not my intention to propose competition for cfobjects or Fusebox. I use the term objects as a term of art, that is, I don't refer to a COM object or a Java object. I'm proposing a logical way to think about coding and to optimize your code in whatever given framework you currently enjoy.

I start with three major assertions:
1. A programmer's understanding of logical constructs and equations is the chief means of writing code that's consistent, easily understood, and quickly pro-cessed by ColdFusion.
2. Writing ColdFusion is a necessary generation of sets.
3. A ColdFusion application can be written and understood as a form of logical proof.

Each of the three assertions is inextricably related in this context; I'll therefore refer to them in various ways. Let me note first that I don't refer to logical proof as merely an instance of syllogism (which takes the form of premise, secondary premise, conclusion); I mean to invoke the sense that a logical proof requires something to be proved, though the auxiliary point isn't lost.

ColdFusion is a language and an application server conceived by a gentleman with a degree in philosophy. Just as it's no coincidence that ColdFusion contains commands shared with other programming languages (switch/case, try/ catch), ColdFusion also shares much with philosophy - specifically set theory and logic. By extension, a ColdFusion application conceived as a mathematical or logical proof will follow the rules of those disciplines.

ColdFusion applications often operate within a series of if/else constructs. In general, ColdFusion programmers understand by conditional logic that it's what happens when they need to represent the following circumstance:

If A is true, execute B code; in all other cases, execute C code.

The tools available to construct conditional logic clauses within CFML are:

1. Variables: Test for existence or truth-value).
2. Decision functions: Route the actions.
3. Operators: Define possible states.

At the design stage the usefulness of conditional logic as the supposition of possible user interaction can't be stressed enough. You can create a structure known as a use-case scenario, in which all possible user interactions with the program, and all programmatic responses, are mapped. As the "world" of the program is circumscribed, by itself, this is in fact a finite construct.

To instantiate the above construct (3), we might write the following:

<cfif Request.Ses.LoggedIn is 1>
<cfinclude template="welcome .cfm">
<cfelse>
<cflocation url="login.cfm">
</cfif>

It's a simple case in which the second event (the execution of either B or C code) is predicated on the truth-value of A within the given context. You'd quickly conclude that "within a given context" represents a set; that is, the set in which Request.Ses.LoggedIn is capable of truth-value. In ColdFusion you generate such a set by declaring a variable that this code (A) can test against. ColdFusion programmers often seem to leave things at that and move on.

If we allow for a more complete version of the meaning of the "given context," we can imagine an entire application. Think of the stack trace you use in debugging your applications. A stack in programming is a data structure in which items are removed in reverse of the order in which they were added. The trace is a genealogy of instances.

There's a logical stack trace for any given point in your application. A logical stack trace is a snapshot of the current structure, the complete definition of the logical structure contextualizing any given line of code. What's precisely locatable in this logical stack trace is the entire set of conditions that are true, false, initialized, or not yet initialized.

There is great value in knowing, even before you write, the logical stack trace of your application. Knowing it will help you plan your applications more quickly.

Perhaps the most important point to stress is that it'll prevent your writing unnecessary constructs and setting variables whose existence or value is redundant to test for. Build your application in the manner of a logical proof and you'll reduce writing time and write optimized code.

How then do you write an application in this manner?

To help us, let's refer to George Boole, the self-taught mathematician on whose work much current programming is based, and to the set theorist Bertrand Russell.

Paraphrasing Boole, we'll employ the symbol 1 to refer to everything within our ColdFusion application - every conceivable class of objects that may or may not exist. It is premised that the same individual object may be found in more than one class, as it may possess more than one quality in common with other objects. The usefulness of this is that it allows us to express our application in mathematical - and hence logical - terms. (We'll explore this later.)

However, we can see loopholes within Boole's conceptualizing. Bertrand Russell has a famous story that illustrates the problem; it's a story about a barber:

There was once a barber.
Some say he lived in Seville.
Wherever he lived, all of the men in this town
either shaved themselves or were shaved
by the barber. And the barber only shaved the men
who did not shave themselves.

You can immediately see the paradox when you attempt to answer the question: Did the barber shave himself? When we conceive of Boole's "1," or the set that contains all sets, we must conceive of a set of sets, that is, the set that contains all other sets, which must contain itself, ad infinitum. We must also conceive of {}, or the empty set, such as "The set of all living humans who do not have brains"- there are no members of this class. By extension we get the "set of all sets that do not contain themselves," which is an inconsistency.

I belabor the inconsistency within set theory (and consequently mathematics) to dispel irrelevant objections, and to prevent certain frustrations, and because it's an important conversation of the last hundred years. We're free to conceive of sets within sets within the set of our application. We select objects, such as Request.Ses.-LoggedIn, as the nodes of our structure, and then demark the structure as (1) the set over which this object has purview, and (2) the else-set, that is, all moments of the application wherein the object is not defined or not defined in equivalency.

Applications as Logical Proofs
An act of selection of an object from a class of objects is independent of the order in which successive objects are selected. I may select cats, and from cats I may select only gray cats. This is equivalent to my selection of all things that are gray and a subsequent selection of cats from within that class. Boole would write:

xy = yx

which we'd translate as "declare a class, every y of x. It is equivalent to the class of every x of y."

Perhaps you object, saying that while this is true for logic, where the matter is concluding a law of thought, it is not necessarily true within an application. So, we ask, What is the time continuum of a ColdFusion application? It takes place within a user-defined circumstance, which is in turn within a programmer-defined circumstance within a language-defined circumstance. Debugging output allows us the following conclusions:

• ColdFusion is aware of precisely its entire state at each moment, for every moment.
• ColdFusion outputs all queries run, all form variables passed.
• ColdFusion will accept or reject local and other variables based on availability.

It follows that an application that can be understood and written in this manner will optimize flow control and reduce redundancy. How are we to understand an application in this manner? By writing it as a logical proof.

To do this, we must consider the variables and expressions as contained within the structure of the logical stack trace. ColdFusion certainly does this. A number of corollaries immediately follow, and we can use these logical propositions to our advantage when designing flow control for our applications. We can therefore conclude the conversion of propositions:

1. Propositions are convertible. A proposition is said to be converted once its terms are transposed. Example: "No programmer is a tyrant" converts to "No tyrant is a programmer."

This is worth noting, given ColdFusion's "short circuit" evaluation method: when ColdFusion tests a concatenated statement such as:

<cfif Request.Ses.LoggedIn IS Yes AND UserLevel is 12>

if Request.Ses.LoggedIn turns out to be false. ColdFusion never evaluates the second expression; if one expression is false, then the entire statement is necessarily false. You can use this to your advantage in writing: order concatenated expressions according to the likelihood of their truth or falsity within the given moment.

2. A conversion per accidens is a conversion by limitation, and this is allowable. Example: "All programmers are people" converts by limitation to "Some people are programmers."

You can take advantage of this in your applications. Locate the (necessarily existing) corresponding set to any given object and use it to optimize your code. For example, in a possible world where User-Level may exist, it may have a value of 12 or another number. You could test for existence and value in the usual manner and invoke such construction repeatedly as needed. However, the foregoing allows us to abstract away from variables at this level.

        . 3. Negative conversions (or conversions by contraposition) accompany positive terms. Example: "Every programmer is a genius" converts by negation into "that which is not a genius is not a programmer."

Each object within a set can be conceived not only as itself, but it necessarily, concomitantly, defines a corresponding set of not-X. This is stated as a corollary of statement 2 above.

There are three conclusions:

1. We can define within application.cfm an abstract set of sets, employable globally, and test against existence or value for nested set nodes.
2. By using the laws of logic, we can reduce the total number of variables required to manage application flow.
3. It follows that reduced variable creation will result in reduced expression testing, whether it's testing for truth-value, existence, quantitative value, or qualitative value.

Table 1 displays a series of implied equations you can use to express your logical stack trace. To bring this to life you must:

• Consider all of the logical conclusions in your applications once you begin to incorporate flow control, and consider variables in the design phase.
• Choose a scope to pass them through, based on availability.
• Discover the limit of use-case scenarios so that "1" represents something meaningful inasmuch as there are no user interactions that go unaccounted for.
• Abstract your variable and expression testing within a set of sets required. (After you implement the practices above, this should be apparent to you without your having to do much extra work.)

In this way we can conceivably write an abstract of our entire application - including all possible use-case scenarios - as a mathematical expression. If you follow the rules of logical thought, your code will process faster. It will be easier to write and quicker to debug. Your formalism will allow you to reuse code from application to application more easily and to write code to meet new challenges from within a sensible system.

Acknowledgment
I'm indebted to Alison Leigh Brown for her assistance in this article. For further reference please refer to The Mathematical Analysis of Logic, and In-vestigation of the Laws of Thought, both by George Boole.

• Figure 1