On 1/9/07, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
> > Could we make boolsimp the standard in the next release?
>
> There are four reasons I am strongly opposed to this:
>
> 1) Because "if" can be a no-op rather than an error in some cases.
> This may affect existing Maxima code, but it is also a trap for people
> writing new code.
I'm convinced that attempting to prevent stupidity has the unwelcome
side effect of preventing cleverness as well.
Incidentally at present the stuff in boolsimp still respects prederror
when it is true. So you can recover the current behavior (namely to
complain about undecided predicates) by prederror : true.
> On the other hand, I have no problem
> with changing the boolean operators this way.
OK, I'll work on separating the stuff for Boolean expressions
from the conditional expressions.
> 2) Because its compiled behavior is completely incompatible with its
> interpreted behavior.
I don't think this is an issue at present. In recent versions of
boolsimp.lisp the translation property of MCOND is simply clobbered,
so conditionals in translated functions turn into (MEVAL '((MCOND) ...))
which evaluates the same way as interpreted stuff. It seems feasible
to exploit Boolean declarations to construct (COND ...) instead of
((MCOND) ...) but I haven't done that.
> 3) Because it does not shield simplification-time errors on
> unevaluated branches. I know that Robert considers this a problem with
> simplification, not with unevaluated conditionals, and I pretty much
> agree, but it needs to be fixed. E.g. if x then 1/0 should simplify
> to if x then raise(...appropriate exception...).
Yes, I'd rather avoid 1/0 and 0^0 errors in simplification but
if x then throw(FOO(1/0)) (where FOO prevents simplification)
would be OK too.
> 4) As a mathematical operation (as opposed to a programming
> operation), a conditional should be insensitive to the order of the
> clauses, like Dijkstra's guarded commands. This makes the formal
> properties much simpler and more conducive to further symbolic
> manipulation (which is why Dijkstra introduced this notation in the
> first place).
I dunno. Do we need to give up something generally useful,
which is now working, in hopes of having something that won't
interest most people, and which doesn't yet exist?
> I would propose that instead of changing "if", we introduce a new
> guarded command structure, e.g. cond(a => b, c => d, ...), which would
> be the "simplifying" version. We would still have to resolve the
> simplification-time error problem, but the other issues go away.
A different notation for a concept similar to if--then--else is going
to lead to confusion and dismay.
All the best
Robert