From jan@swi.psy.uva.nl  Fri Dec 15 17:44:21 2000
Received: from gollem.swi.psy.uva.nl (gollem [145.18.152.30])
	by swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id RAA03723;
	Fri, 15 Dec 2000 17:44:20 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]])
	by gollem.swi.psy.uva.nl (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id RAA27592;
	Fri, 15 Dec 2000 17:44:06 +0100
From: Jan Wielemaker <jan@swi.psy.uva.nl>
Organization: SWI, University of Amsterdam
To: Paul Singleton <p.singleton@keele.ac.uk>, prolog@swi.psy.uva.nl
Subject: Re: [SWIPL] About Applying a predicate to all the elements of a list
Date: Fri, 15 Dec 2000 17:18:45 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: "Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
References: <200012150114.OAA28121@atlas.otago.ac.nz> <3A3A3942.3670BA03@keele.ac.uk>
In-Reply-To: <3A3A3942.3670BA03@keele.ac.uk>
MIME-Version: 1.0
Message-Id: <00121517440605.19989@gollem>
Content-Transfer-Encoding: 8bit

On Fri, 15 Dec 2000, Paul Singleton wrote:
>"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 :-)

I'm a bit puzzled.  You can expand end_of_file using traditional
term_expansion like this:

term_expansion(end_of_file, [hello_world, end_of_file]).

where you can use prolog_load_context/2 to see the end of what file
you are expanding.  Ignoring the problems of multiple libraries that
want to exploit term-expansion, this looks the same as what Richard
wants.

Paul reads the same as `collect all terms from the file and at the
end of the file handle them to an expander that will cruch away and
return the final thing to be compiled'.

Paul's approach looks nice, but has some problems.  I've seen people
loading *really big* programs and this indirection will cost a lot
more memory.  Second is that I would like to take care of source-lines.
This is already a nuisance with term-expansion, but using whole-file
conversion we really need to solve it properly.

Most simple thing to load from other sources is to load from a stream
using an identifier (so you know what to delete if you want to `reload'
the object).  That is trivial to write using what you find in
init.pl

>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?

Guess so ...

>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).

Thats easy too.  just use $assert_clause from init.pl (and handle the
list yourself).  The module is controlled using $source_module/2.

>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...

Might be nice, but how much does it gain?  The kernel can be in a
DLL/shared object, so it takes ~350 Kbytes from your machine.  You
could reduce the footprint in each process a bit by moving more from
`built-in' to the library, saving upto about 100 K.

Compared to most of the other stuff on your computer this is getting
pretty memory-friendly.

	Regards --- Jan

