Program stack overflow defining infix operator

To the extent that these proposals seem to raise huge issues with 
incompatibility with previous programs, I think they should not be 
implemented.

The conflation of programming constructions and logical instructions is 
unfortunate, but the current usage is that of programming constructions.
Do you really want to change this?

That is,

if  (a<b) and (c<d) then do_this else do_that

is part of the language.  Maybe not done beautifully, but part of the 
language.

renaming and, or, not  etc.  strikes me as a really bad idea.  I would 
have to go back to published articles of the last 40 years and change 
the listings in the appendix.

If you want to have logical simplifications, you could use other names 
for those operations. You could even use
AND OR NOT  in caps, or use  && ||  ~   

Simplifying booleans, which would seem to be easy, is, oddly enough, a 
HUGE enterprise in the logic design business.  The meat of PhD 
dissertations.
(logic minimization). If you don't believe me, try Googling.

Or we could also do a poor job of it and declare victory.

I have no objection to someone doing a good job  (or even a poor job), 
but please don't break things.

RJF




Robert Dodier wrote:
> On 8/9/09, Barton Willis <willisb at unk.edu> wrote:
>
>   
>> (1) Should Maxima have distinct simplifying and non-simplifying logical
>> connectives? If so, what should we name the new functions.
>>     
>
> I'd like to rename the existing, non-simplifying "and" and "or" to
> "and_then" and "or_else", and introduce new simplifying operators
> "and", "or", and "not".
>
> I;m not opposed to inventing other, simplifying operators
> e.g. nand, implies, iff. But let's get the basics in place first.
>
>   
>> (2) Short or non-short circuited?
>>     
>
> "and" and "or" should be commutative with no special
> evaluation scheme (so all arguments are evaluated unless
> quoted). "and_then" and "or_else" should be noncommutative,
> with an evaluation scheme to make them short-circuit.
> "not" should be simplifying.
>
>   
>> (3) What simplifications should automatically be used? How about optional
>> (spendy) simplifications (option variables or special extra simplification
>> functions).
>>     
>
> Well, I'm inclined to have only some easy simplifications built in,
> for some value of "easy"; maybe easy = stuff analogous to
> arithmetic simplifications. For the rest, I'd rather have functions,
> instead of flags.
>
>   
>> (4) What about non-boolean arguments? (for example:  matrix([7]) and
>> [8,9]).
>>     
>
> Just leave them be. (It is unmathematical to complain about
> unrecognized expressions. Let the user worry whether it is
> meaningful or not.)
>
>   
>> (5) What about errors?
>>     
>
> It annoys me when simplification functions trigger errors.
> I hope we can avoid that.
>
>   
>> (6) What about prederror? Should we keep true / false / unknown logic?
>>     
>
> I'd like to cut out prederror and all prederror=true branches.
> I think that makes "is" the same as "maybe", incidentally.
>
> I think it's useful to have "unknown", I'd like to keep it.
> Although it's just a convenience; if "is" can return something
> other than true or false, then member(is(x), [true, false]) or
> booleanp(is(x)) or is(x) in {true, false} or featurep(is(x), boolean)
> (only the first of those is for real at the moment) could replace it.
>
> Thanks for your work on this topic. I suspect the simplifying
> Boolean stuff which you wrote in share already handles some
> of these items.
>
> best
>
> Robert Dodier
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>