🚀 go-pugleaf

In article <282@cavell.UUCP>, pat@alberta.UUCP (Patrick Fitzsimmons) writes:
> 
> Don't ask why I am using Turbo Prolog, I really don't want to but I
> must.  To expand on my problem a bit, I currently have in the DOMAINS
> section:
> 
[Why "must"?  Considering the value of your time, it would be cheaper
for you or your employer or whoever is responsible for the "must" to
buy a copy of ALS Prolog and let you get on with it.]

> entry = symbol ;
>         n(entry)
> list  = entry*
> 
> The n(entry) is meant to represent NOT entry.
> 
This is a bad data structure design in ANY Prolog.
I haven't a Turbo Prolog manual, but I suggest that you check yours
very carefully:  you can probably use ";" only in the form
	newdom = f1(t11,...,t1n) ; ... ; fm(tm1,...,tmn)
where each case introduces a functor.  None of the Turbo Prolog
books I've checked has any examples resembling yours.  (Mind you,
each Turbo Prolog book I look at is worse than the last.)

The rule for designing data structures in ANY Prolog is this:
(1) list all the different situations (cases) you want to represent.
    Here you have
	formula-which-is-asserted
	formula-which-is-denied
(2) For each case, identify the associated data.
    Here you have
	for a formula-which-is-asserted:
	    the formula
	for a formula-which-is-denied:
	    the formula
(3) Make up a functor name for each situation.  The associated data
    will be the arguments of the functor.
    Here you have
	p(F)		{Positive assertion of formula F}
	n(F)		{Negative assertion of formula F}
(4) If your Prolog system supports types, write down the types.
    In Dec-10 Prolog (using the polymorphic type checker):
	:- type demo(F) --> p(F) | n(F).
	:- pred negate(demo(F), demo(F)).
    In Turbo Prolog:
	domains
	    formula = /* something or other */
	    entry = p(formula) ; n(formula)
	predicates
	    negate(entry, entry)

You may be gritting your teeth and saying "that's a counsel of
perfection, *I* have to worry about *efficiency*."  I don't know
about Turbo Prolog, but in most real Prolog implementations

	negate(p(F), n(F)).	/* This is cleaner and */
	negate(n(F), p(F)).	/* is usually faster! */

will be *considerably* more efficient than the defaulty version.
{Note that a characteristic of good data structure design is that
you do *not* rely on negation!}

> I have a negate predicate defined as:
> 
> negate(n(G), G) :-
>       ne(n(_), G).
> negate(G, n(G)) :-
>       ne(n(_), G).
> ne(X, Y) :-
>       not(X = Y).
> 
Note that (=)/2 in Turbo Prolog is not the same as (=)/2 in other Prologs.
To start with, when applied to operands of numeric type, it is more like
(=:=)/2 or is/2.  No doubt there are enough people out there to correct
me if I am wrong, but it is my understanding that Turbo Prolog does not
permit partly instantiated data structures.  So I do not think that the
calls to ne/2 in your negate/2 are legal.  Something like

	negate(n(G), G) :- not_n(G).
	negate(G, n(G)) :- not_n(G).

	not_n(n(_)) :- !, fail.
	not_n(_).

might be more appropriate.  On the other hand, this is pretty shocking
too.  You would be *much* better off going with the disciplined version.

I have sent this reply to comp.lang.prolog for two reasons:
 -- I've had too much strife with the "reply" command getting confused
    with its addresses.
 -- I think the question of data structure design is important for
    everyone, whatever Prolog they are using.  The method you chose
    is an obvious natural method which leads to endless trouble: you
    find you need cuts all over the place.  The disciplined version
    leads to code which is both cleaner and faster, and when you are
    used to this approach it is easier too.