Hi, On Thu, 6 Oct 2011, Kai Tietz wrote:
> > at which point this association doesn't make sense anymore, as > > Sorry, exactly this doesn't happen, due an ANDIF isn't simple, and > therefore it isn't transformed into and AND. Right ... > > ((W AND X) AND Y) AND Z > > > > is just as fine. So, the reassociation looks fishy at best, better get > > rid of it? (which of the testcases breaks without it?) > > None. I had this implemented first. But Richard was concerned about > making non-IF conditions too long. I understand that point that it > might not that good to always modify unconditionally to AND/OR chain. ... and I see that (that's why the transformation should be desirable for some definition of desirable, which probably includes "and RHS not too long chain"). As it stands right now your transformation seems to be a fairly ad-hoc try at avoiding this problem. That's why I wonder why to do the reassoc at all? Which testcases break _without_ the reassociation, i.e. with only rewriting ANDIF -> AND at the outermost level? Ciao, Michael.
