🚀 go-pugleaf

I'm trying to write some code that relies heavily on pulling pieces
out of operators that have some particular properties.  However, I run
into a problem (documented in G. Rayna's book), in the complexity of
the expression that REDUCE will consider.

Rather than bore you with the details of my calculation, I'll show you
the simplest example I can generate (actually Rayna's example):

REDUCE 3.4, 15-Jul-91 ...     

1: clear z; operator z;

3: zrules:={z(~x*q0)=x}$
4: let zrules;
5: % this is OK:
5: z(a*b*c*d*q0);
A*B*C*D

6: % but this is not:
6: z(a*b*c*d*e*q0);
Z(A*B*C*D*E*Q0)

[According to Rayna, these limitations are built in for efficiency. I
can understand this. (Unfortunately, it's not spelled out in the manual.)]

Now, this is a serious limitation to writing simplification rules for
complicated expressions.  If I cannot rely on REDUCE searching all
sub-expressions I have to take an alternative approach.

In fact, I have worked around these problems by  writing procedures
which step through the expression, using ARGLENGTH and PART. It's not
too difficult, but it makes the code much more obscure. 

Surely there is an easier way, perhaps even a switch to control the
"depth" of the matching?  

[I realize there is a pattern-matching package, PM,but that also has
limitations, and won't easily allow a "when" part (as far as I can
tell).]

-- 
Mike Reid
mfreid@hkuxa.hku.hk <-- Preferred Internet Address [or mfreid@hkucc.bitnet]
Department of Physics, University of Hong Kong, Pokfulam Rd, HONG KONG
Phone: (852) 859 7944 or 859 2360 Fax: (852) 559 9152 Telex: 71919 CEREB HX