[mercury-users] vanilla in Mercury

[Fergus Henderson]

On 07-Sep-1999, Randall Helzerman <rahelzer at ichips.intel.com> wrote:
> I'm trying to port an application from prolog to Mercury.  It makes
> extensive use of a very simple metainterpreter (vanilla):
> 
> demo([]).
> demo([G|Gs]) :-
>         axiom(G,Gs1),
>         append(Gs1,Gs,Gs2),
>         demo(Gs2).
> 
> or simple modifications thereof (abduction, goal delaying,
> negation-as-failure--things like that).
> 
> Can such a simple meta-interpreter be coded in Mercury?  I looked at
> the interpreter.m code which was supplied in the samples directory, and
> was discouraged.  Compared with the simple version above, it seems rather
> complex, and as this particular applications uses many many slightly-warped
> versions of vanilla, it would be very clumsy to use the interpreter.m code
> as a base.

Well, a Mercury meta-interpreter analagous to that one above but using the
ground representation could look like this:

	:- pred demo(list(term), varset, varset).
	:- mode demo(in, in, out) is nondet.
	demo([]) --> [].
	demo([G|Gs]) -->
		{ axiom(G, VarSet, Head0, Body0) },
		rename_apart(VarSet, [Head0 | Body0], [Head | Body]),
		unify(Goal, Head),
		{ append(Body, Gs, Gs2) },
		demo(Gs2).

Yes, this is a little bit more complicated that the Prolog version,
because when you're using a ground representation the `rename_apart'
and `unify' operations need to be made explicit.  However, it is still
pretty simple.  As Ralph Becket said, you just need a library that
provides those operations.

The code in extras/trailed_update/samples/interpreter.m and
samples/interpreter.m is more complicated than the code above
for several reasons:

	- Unlike `demo', it supports a few more operations as builtins
	  ("=", "," and ";"), and it allows the body to contain nested 
	  conjunctions and disjunctions rather than just being a list
	  of atoms.

	- The database is passed as a parameter to `demo' and `axiom'
	  (called `solve' and `database_lookup_clause'),
	  rather than being fixed.  Of course in Prolog the database is
	  not fixed because it can be modified using the non-logical
	  assert and retract builtins.  But I prefer passing down
	  the database as a parameter.

In addition, those example modules include some additional code:

	- The code for the unify and rename_apart operations.

	- For extras/trailed_update/samples/interpreter.m,
	  code to convert its term representation to/from the
	  Mercury standard library `term' type so that it can make use
	  of the Mercury standard library functions for reading and writing
	  terms.
	
However, these only have to be written once.  You could put that code in a
library module.

Cheers,
	Fergus.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------