From p.singleton@keele.ac.uk  Fri Dec 15 17:13:31 2000
Received: from scooby.lineone.net (doggy.lineone.net [194.75.152.224])
	by swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id RAA01942
	for <prolog@swi.psy.uva.nl>; Fri, 15 Dec 2000 17:13:31 +0100 (MET)
Received: from keele.ac.uk (host212-140-9-66.btinternet.com [212.140.9.66])
	by scooby.lineone.net (8.9.3/8.9.3) with ESMTP id QAA19269;
	Fri, 15 Dec 2000 16:13:10 GMT
Message-ID: <3A3A3942.3670BA03@keele.ac.uk>
Date: Fri, 15 Dec 2000 15:31:14 +0000
From: Paul Singleton <p.singleton@keele.ac.uk>
Organization: SmartArts Computing Consultancy
X-Mailer: Mozilla 4.74 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: prolog@swi.psy.uva.nl
CC: "Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
Subject: Re: [SWIPL] About Applying a predicate to all the elements of a list
References: <200012150114.OAA28121@atlas.otago.ac.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Richard A. O'Keefe" wrote:

> A rather better approach, which would not require you to allow all
> predicates in a file to be discontiguous, would be to have a
> end_of_file_expansion(+FileName, -ClauseList) hook that is called when
> compile, consult, &c reach the end of a file.  Then you can squirrel
> away all the clauses you want, and pick them up after all the other
> predicates in the file.

I'm convinced, and I suggest that a neat way to support this would be to
provide whatever built-ins are necessary and sufficient to allow us to
write alternative module-loaders (we may want to load Prolog modules
from something other than a source-text file, e.g. a database repository
or some Prolog-implemented preprocessor or generator) (in fact, it's
stronger than "we may" - I do :-)

As I understand it, some Prolog implementations optimise the compilation
of procedures by considering all a procedure's clauses at once (and I
guess some do "global" optimisations as well?)

Thus, by asserting the clauses individually we would lose out on the
optimisations.

I believe SWI-Prolog currently does no procedure-level optimisations, 
but reserves the right to do so in some future version?

So we seem to need a "compile_clause" built-in which takes Richard's
list of clauses as an argument (and maybe a target module).

More generally, I'm keen to get my hands on a Prolog implementation
(preferably a future version of SWI-Prolog :-) which has a micro (?)
kernel of truly primitive features, with non-primitive but traditional
built-ins (stream I/O? consult etc.?) implemented as libraries.  I
realise that SWIPL is already bootstrapped from a kernel plus some
source-files-which-aren't-really-modules, and I haven't delved into
this very deeply yet, so we may already be where I (currently think I)
want to be...

Paul Singleton


