Newsgroups: comp.lang.prolog
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!zs
From: zs@munta.cs.mu.OZ.AU (Zoltan Somogyi)
Subject: Re: symbolic global constants (not)
Message-ID: <9513119.11886@mulga.cs.mu.OZ.AU>
Sender: news@cs.mu.OZ.AU (CS-Usenet)
Organization: Computer Science, University of Melbourne, Australia
References: <3nq7vp$ihl@goanna.cs.rmit.edu.au> <D7y004.97H@ecrc.de> <3oapniINNejd@bhars12c.bnr.co.uk> <3ob4pk$su4@cheltenham.cs.arizona.edu>
Date: Thu, 11 May 1995 09:58:18 GMT
Lines: 26

John Fletcher  <J.S.Fletcher@bnr.co.uk> wrote:
>Surely partial evaluation of Prolog programs to expand those calls
>which are determined at compile-time is better than macro expansion?

debray@CS.Arizona.EDU (Saumya K. Debray) writes:
>Maybe so, if Prolog systems routinely came equipped with partial
>evaluators.  Unfortunately, I know of only a few partial evaluators
>for Prolog, and these are all research systems.

One of the optimizations performed by the Mercury compiler is the
automatic inlining of predicates that are "simple enough". The criterion
for what is simple enough has changed over time, and will almost certainly
change again, but a predicate defined by a single fact is definitely
simple enough. Inlining the call is all that is needed to completely remove
the overhead of the predicate call.

The only limitation relevant here is that the Mercury compiler works with
one module at a time, so if the predicate defining the constant is in
another module, it will not be inlined. We are however looking at the
techniques necessary for implementing cross-module optimizations without
losing separate compilation.

Saumya is of course right in that Mercury is a research system.

Zoltan Somogyi <zs@cs.mu.OZ.AU> http://www.cs.mu.oz.au/~zs/
Department of Computer Science, University of Melbourne, AUSTRALIA
