Path: utzoo!attcan!uunet!mcvax!unido!ecrcvax!bruno
From: bruno@ecrcvax.UUCP (Bruno Poterie)
Newsgroups: comp.lang.prolog
Subject: Re: Seattle tutorial Prolog
Summary: rule/2 <> exec/2
Message-ID: <619@ecrcvax.UUCP>
Date: 5 Sep 88 13:48:05 GMT
References: <1416@kulcs.kulcs.uucp>
Reply-To: bruno@ecrcvax.UUCP (Bruno Poterie)
Organization: ECRC, Munich 81, West Germany
Lines: 77

In article <1416@kulcs.kulcs.uucp> bimbart@kulcs.UUCP (Bart Demoen) writes:
>Tutorial No:8 of LP'88 Seattle (R. O'Keefe) makes 'interesting' reading, but
[...]
>instead of representing the nrev program as:
>
>rule(append([],_l,_l),[]) .
>rule(append([_x|_l1],_l2,[_x|_l3]),[append(_l1,_l2,_l3)]) .
>
>rule(nrev([],[]),[]) .
>rule(nrev([_x|_r],_o),[nrev(_r,_o1) , append(_o1,[_x],_o)]) .
>
>do it as:
>
>rule(append(_x,_y,_z),_b) :- append(_x,_y,_z,_b) .
>rule(nrev(_x,_y),_b) :- nrev(_x,_y,_b) .
>
>append([],_l,_l,[]) .
>append([_x|_l1],_l2,[_x|_l3],[append(_l1,_l2,_l3)]) .
>
>nrev([],[],[]) .
>nrev([_x|_r],_o,[nrev(_r,_o1) , append(_o1,[_x],_o)]) .

This may be alright if you seek only efficieny, but:

	o  you cannot use rule/2 for clause retrieval anymore

	o  you increase the size of your database by a non-neglectable factor

	o  you fill up your dictionnary with functors 
		(append/0,append/3,append/4)

	o  you cannot apply this method for the code of the interpret itself,
	   which imply that you have to enter *by hand* the rules for it,
	   destroying partly the interest of the method which was to show
	   that a meta-interpret is a normal prolog program working on
	   normal prolog code in an automatic way, including on itself.


So let us keep the name  rule/2  for a 'data' representation of the clauses,
and use instead another name for this 'executable' representation ... 
say,  exec/2   ??? [it doesn't matter, after all ;-)]

There are anyway 2 problems linked with this list representation:
(which, by the way, is actually *used* as the internal representation,
the basis for the interpretor, and the output of clause/2, by at least
one Prolog for PC & up: XILOG (from Bull), which happens to be one of
the fastest in its category!).

The first one is the representation of if-then-else [ A -> B ; C ]:
should the sub-sequences (A,B & C) be themselves sub-lists, with ->/2 & ;/2
built-in inside the meta-interpret, and this, reccursively; or kept as terms?
In this case, the code for ;/2 should first transform its argument into a
list of goals, before returning control to the meta-interpret (see point 2).

The second problem is the metacall: 
When called, the metacall (call/1) have first to analyse its parameter, 
transform it into a list of goals, and then pass it to the meta-interpret.
This may be costly, and imply as well that any variable in a goal position 
inside a term being analysed and transformed has to be replaced by a:
	call(Variable), 
even if the term is to instantiate to a very simple subgoal, in order to
ensure the transformation at run-time. Moreover, it implies that call/1 has
to be tightly connected with the meta-interpret (because you can always
use it explicitely), unless we use it as a sort of escape to the real
Prolog engine :-?

After all, time is not the *main* constraint for a meta-interpret,
cut and bips are more of a problem!

================================================================================
  Bruno Poterie		# ... une vie, c'est bien peu, compare' a un chat ...
  ECRC GmbH		# tel: (49)89/92699-161 	Tx: 5 216 910
  Arabellastrasse 17	# usenet: bruno%ecrcvax.UUCP@Germany.CSNET
  D-8000 MUNICH 81	# or: bruno%ecrcvax.UUCP@pyramid.pyramid.COM (from USA)
  West Germany		# uucp: ...!mcvax!unido!ecrcvax!bruno
  EUROPE		# or: ...!pyramid!ecrcvax!bruno (from USA)
================================================================================