🚀 go-pugleaf

Saumya Debray mentioned recently on the net (in <126@sbcs.UUCP>)
that good Prolog programmers don't make much use of assert and retract.
Although my exposure to Prolog has been limited, I've always felt that
somehow this must be true - assert and retract start mucking with the
very predicates that Prolog's trying to use. I can sort of imagine
the Dijkstras of the Prolog world intoning "Assert Considered Harmful"
and explaining why, like GOTO in conventional programming languages,
assert and retract really shouldn't be used much.

But now I wonder. I'm developing this Canadian income tax planning
system. I find that on even a simple set of facts it has to do
several thousand predicate calls (matches, logical inferences, whatever
you call them), and I'm nowhere near done implementing all the rules
I want to put in. When I look at the logic, I find it's doing the same
analysis over and over for certain legal conclusions that are really
"facts" for other rules to deal with. For example:
	related(Taxpayer1, Taxpayer2) :-
		tptype(Taxpayer2, corporation),
		controls(Taxpayer1, Taxpayer2).

Now, "controls" can be viewed as a fact when considering whether
T1 and T2 are related, but actually it's a predicate that takes a
whole lot of analysis (in its simplest incarnation, it looks for all
the outstanding common shares in T2, looks for the owners of those
shares to match T1, totals up the two numbers and checks to see if
T1's shares exceed 50% of the total).

Once I've determined that T1 controls T2, should I "asserta" that
as a fact, so it no longer needs to take much time? And having
done so, do I then "asserta" the fact that they are related? Many
of the rules which I'm implementing have an initial test of relatedness
or control, and obviously the analysis will be much more efficient if
the program can decide almost instantly whether to take a particular
analysis path or not.

There's a further complication, too. Most of the rules need to know
whether a given pair of taxpayers are related *at a particular point
in time*. So if I start using assert, I can imagine that I'll have to
run a set of asserts for each relevant time period during the several
transactions which the system would be analysing (since control will
change due to the transactions in corporate reorganizations, for example).

Comments?

Dave Sherman
The Law Society of Upper Canada
Toronto
416 947 3466
-- 
{ ihnp4!utzoo  pesnta  utcs  hcr  decvax!utcsri  } !lsuc!dave