🚀 go-pugleaf

In article <1229@lsuc.UUCP>, dave@lsuc.UUCP writes:
> Saumya Debray mentioned recently on the net (in <126@sbcs.UUCP>)
> that good Prolog programmers don't make much use of assert and retract.
> [text deleted]
>                   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.
> [text deleted]
> Once I've determined that T1 controls T2, should I "asserta" that
> as a fact, so it no longer needs to take much time?
> [text deleted]

Is this an example of lemmas?

I would like to believe that a formal mechanism for managing and
applying previously proved goals could significantly improve the speed
of large programs.  However, I do see many issues like:
	- knowing when the lemmas are no longer valid
	- making the time cost cheap enough to cause overall speedup
	- keeping the space cost "low enough"
	- knowing when *not* to store lemmas (I/O, external conditions)

---------------

Although it is easy to misuse assert and retract, I think Prolog is very
valuable as a database language.  Databases for practical applications
can easily have dozens of relations and change very often.

Something I find dearly missing from Prolog are uniform semantics for
side-effects.  It seems "ugly" that applications and even Prolog support code
use predicates like:

	set_xxx(Value)
	get_xxx(Value)

		or

	add_xxx(Key,Value)
	find_xxx(Key,Value)
	del_xxx(Key)


Just some food for thought.


Tim Morrissey