Newsgroups: comp.lang.prolog
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!newsfeed.internetmci.com!in2.uu.net!allegra!alice!pereira-x.research.att.com!user
From: pereira@research.att.com (Fernando Pereira)
Subject: Re: expand_term (was: Re: Is Visual Prolog "real" Prolog?)
X-Nntp-Posting-Host: pereira-x.research.att.com
Message-ID: <pereira-1605962241370001@pereira-x.research.att.com>
Sender: usenet@research.att.com (netnews <9149-80593> 0112740)
Organization: AT&T Research
References: <317752DA.C2C@pdc.dk> <4mn60o$nne@mulga.cs.mu.OZ.AU> <4mpatd$aqg@sol.sun.csd.unb.ca> <4mvloh$q6j@mulga.cs.mu.OZ.AU> <4nbqdo$72q@sol.sun.csd.unb.ca>
Date: Thu, 16 May 1996 21:41:37 GMT
Lines: 22

In article <4nbqdo$72q@sol.sun.csd.unb.ca>, tarau@clement.info.umoncton.ca
(Paul Tarau) wrote:
> [...]
> I think this cleaner style of meta-programming is not intrinsically
> alien to Mercury as _typed_ logic languages like LambdaProlog-MALI are
> using such constructs quite heavily.
Good that you brought up lambda Prolog. Universal quantification in
negative contexts (essentially universal variables) is a better
representation of variables in metaprogramming than either the ground
representations of Mercury and Goedel or the standard Prolog hack. It
avoids the hassles of managing explicitly sets of constants and
substitutions in ground representations, and it avoids the bugs caused by
the standard Prolog hack. It is more expressive than either, and it is
compatible with lambda conversion is just the right way.

However, metaprogramming in lambda Prolog still requires explicit encoding
of object-level formulas as metalevel terms, because of the type system.
In the original implementation of lambda Prolog, this could be avoided by
using runtime type polymorphism, but at considerable danger of
nontermination because of underconstrained types in higher-order
unification. More recent implementations use stricter type systems, so
encoding is inevitable.
