="rcs@xmission.com" <rcs@xmission.com> Simplify IF expressions.
Very interesting ideas! Of course, as you well-know, If(A,B,C) <-> A&B + (~A)&C. So, if you can simplify and/or expressions you can simplify IF expressions (mod, as you put it, the eye of the beholder). An amusing idea might be the converse: rewriting logic expressions entirely in If (writing 0 for false and 1 for true). So, extending your list: A&B <-> If(A,B,0) <-> If(A,B,A) ~A <-> If(A,0,1) hence A+B <-> If(If(A,0,1),If(B,0,1),0,1) (is there something "simpler"?) And of course you can also make a more compact syntax for "case" branches similar to Lisp's COND by expanding converting the else-ifs into nested Ifs. Another interesting thing is repeated substitution 0 <-> If(A,0,0) <-> If(A,If(A,0,0),If(A,0,0)) <-> ... Thus allowing 0 to be defined as a sort of fixpoint of the If function.
Other notations include A?B:C, Choose(A,B,C), Boole(A,C,B),
In a domain-reduction based constraint reasoner I built a few years back, I adopted ?(A,B,C) as a synonym for If(A,B,C). <aside> That system represented domains as intervals. The Boolean interval was 0..1, so [0 0] was false, [1 1] was true and [0 1] was maybe. The Boolean operations were then just a subset of the interval arithmetic (although, oddly, "implies", often written in logic as A => B, turns out to be A <= B arithmetically). (Obviously this can also be fuzzy, if you swing that way.) This may seem academic, but the unification was hugely useful in commercial decision support applications, where the business modelers could just code up their rules and policies as a bunch of composed functions that described the required state, rather than "programming commands" in some icky opaque imperative way. </aside>
A similar challenge can be made for Loop expressions... using a larger or boldface version of the operator... Would it be useful to change to a generic Loop expression? Most of the simple manipulations...are applicable to Loops too.
Yes, I think this would be an excellent idea to pursue! Back in the early 70's, influenced by exposure to APL, Macsyma etc, I experimented with notations that tried to meld math and programming, in which I wrote Loop as a capital lambda. Unfortunately I've seen that also used for the more specialized operator that is to inclusive-or what capital sigma is to +. Earlier still, it always seemed somehow wrong that my geometry textbook was full of case arguments in proofs, but the analogous pattern for "formulas" were missing from algebra. And later, something of a kludge to select a member of a set of expressions by summing them all together and then multiplying all but one by zero. (By the way, that zero has to be a "damn strong" zero, since it often needs to annihilate expressions that would otherwise be x/0 etc. See also Henry Baker's comments in this thread on speculative execution). Yes, why not have a notation for writing algorithms that was more friendly to algebraic-style manipulations? Or maybe some strange hybrid of APL and Lisp? So-called "concatenative" programming languages such as Forth, Postscript and Joy also come to mind (especially Joy).