[Maxima] conditionals and bad plist
macrakis at alum.mit.edu
Tue Jan 9 13:02:55 CST 2007
> 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 find the unevaluated conditional a very valuable
piece of functionality; I'm just not convinced it should be conflated
with the programming construct. On the other hand, I have no problem
with changing the boolean operators this way.
2) Because its compiled behavior is completely incompatible with its
interpreted behavior. That is not acceptable for any core
functionality in Maxima (though of course there are existing bugs...).
Of course, it is just "a small matter of programming" to fix this....
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...).
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
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.
More information about the Maxima