Subject: Re: [Fwd: abolish/1 in 3.3.0]

From: Jan Wielemaker <[email-masked]>
Date: Fri, 21 Jan 2000 09:32:19 +0100

> Jan Wielemaker wrote:
> 
> > On Wed, 19 Jan 2000, Paul Singleton wrote:
> 
> > >(Really, I want to be able to consult/compile from a byte array in
> > >main memory, and also (when transforming procedure sources) from
> > >terms, but I'm resigned to using temporary files.)
> 
> > This could be done: turn the input into a stream (have to do that
> > in C), read the terms, call expand_term/2 on each and assert them
> > (see boot/init.pl).  If you want to go this way, I'm willing to
> > help defining a public interface for doing this.
> 
> Quintus had
> 
> 	with_output_to_chars( Goal, Chars)
> 
> 	with_input_from_chars( Goal, Chars)
> 
> which were useful for this sort of thing, although I can see
> that mapping e.g. ODBC buffers onto streams in foreign code
> would be more direct.

Yip.  The predicates above are normally replaced by atom_to_term/2
and friends.  Otherwise I would like:

	open(atom('foo(bar)'), read, Fd),
and
	open(atom(New), write, Fd).

which I think is more in line with the current approach.  In practice
I think the very few cases where streams on anything else than a file is
needed should use foreign code to do exactly what they want.

> NB is your Quick Load format useable for individual procedures?
> Would it make any sense to compile procedures individually and
> load the .qlf byte strings from the repository?

Good question.  I doubth.  There is quite some work involved getting
an engine up for mapping the local symbol table of the qlf file onto
the global one of the running system.  You will only start gaining
anything if there is a significant amount of code to get from your
DB.  I would estimate at least a K-byte (but that is a very rough
estimate).

One day I would like to be able to compile code to a file and simply
map that file into memory (read-only) to get the predicates available,
providing blindly fast loading of arbitrary big pieces of code.

> Anyway, I'm certainly interested in faking streams in foreign code;
> is there anything in particular in the sources I should look at
> for guidance?

Best place is pl/src/pl-stream.c, where the low level stuff as well
as some of the high-level functions are defined.  Look at Sopen*()
functions.  With some knowledge of C and how streams tend to be
implemented in this language it is very easy to understand.  Then do

#include <SWI-Stream.h>
#include <SWI-Prolog.h>

In that order: SWI-Prolog.h gives you some extras if SWI-Stream.h is
loaded.

	Regards --- Jan