Re: tellsimpafter strangeness with operands that satisfy the same predicate

Hello, to follow up on the previous message about tellsimpafter --

It looks like the problem is in PART+ in src/matrun.lisp
(and likewise PART*). There is some code in PART+ which appears
to be intended to account for commutativity, so that a rule
for (say) integer + nonatom handles nonatom + integer as well.
However that code seems to mishandle cases in which operands 
satisfy the same predicate, as described in my previous email.

Defining a new operator, say "my+", and declaring it nary,
a tellsimpafter rule for a my+ b my+ c works as expected --
it doesn't get routed through PART+. If "+" is
processed the same way as user-defined operators, by 
patching PROC-$TELLSIMPAFTER (src/matcom.lisp) to execute
(setq plustimes nil)
instead of (setq plustimes (memq name '(mplus mtimes))),
then a tellsimpafter rule for "+" with operands that satisfy
the same predicate works as expected when operands are in
the same order as declared in the rule -- but commutativity
is lost; if operands are in a different order the rule 
is not applied. 

Incidentally tellsimpafter-generated rule-matching code
appears to ignore whether a function is declared commutative.
At least I couldn't convince tellsimpafter to respect 
commutativity.

It seems like the right thing to do is to get the tellsimpafter
rule-matching code to pay attention to whether an operator
is commutative, instead of special-casing + and *.

But maybe fixing the bug in PART+ (and PART*) is enough for now.
I don't have a bug fix yet.

For what it's worth,
Robert Dodier


	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/