> (1) "NOT x # y" yields FALSE for undefined x and y
> (whether PREDERROR is TRUE or FALSE). This seems like a bug
> -- do you agree?
No. "=" and "#" are *syntactic* comparison. Other relations (<, <=,
etc.) are *semantic* comparison. So Not(x#y) should be False for
undefined x and y.
I know this is confusing. One quick "solution" would be to define infix
semantic comparison operators, e.g. "==" and "<>" or something. But
then people will start confusing them, just as in C, the confusion
between assignment (=) and equality test (==) is a very common source of
errors. At least Maxima uses ":" and not "=" for assignment! (Though
":=" would be more consistent with other languages....)
> (2) Some of the rules concerning conditions are there to
> avoid having to simplify or evaluate 1/0 or other
> expressions. What happens if Maxima has a policy that
> "There are no bad expressions, every expression evaluates
> to something" ?
Yes, making 1/0 => infinity (unsigned infinity) or und or 1/0 are
certainly possibilities that have been discussed over the years. To
make them work properly, though, *all* of Maxima would have to be
reviewed. Right now, most of Maxima treats infinity and und as ordinary
identifier symbols, so it will blithely calculate und-und => 0; if 1/0
were allowed as a simplified expression, similar things would go wrong
elsewhere.
It may be worth making this effort, but only as part of a larger project
to clean up and abstract other object types. It really does mean
reviewing almost every function in the system, since (a) there is
currently no category for "constant-like object that doesn't obey normal
arithmetic rules" and (b) many parts of the system check 'by hand'
rather than using $numberp, $constantp, etc. (hence the bugs where for
example subscripted variables are not allowed as variable names in some
contexts, or where floats but not bfloats are allowed, etc.).
> It seems that if we implemented this more relaxed policy,
> then unevaluated boolean expressions with AND, OR, and NOT
> become possible. What do you think?
Yes, this would probably work.
-s