Subject: Re: foreign_library implementation question

From: Jan Wielemaker <[email-masked]>
Date: Fri, 4 Feb 2000 16:36:10 +0100

> >An alternative is to generate your calls with an additional argument
> >telling what you want the foreign function to do.  This seems the
> >most portable and logical solution to me.
> 
> I like this one. I thought of this before, but didn't want to bother
> the caller with an extra parameter. But as I come to think of it, this can 
> probably be obscured by having an extra "wrapper" predicate. 
> 
> >Alternative, the foreign interface has to be augmented.  This very
> >easy, but in principle their might be a day where optimisation makes
> >it hard to extract this information.
> >Of course you can do yourself whatever you like with the source, but
> >I will only add it to the interface if you can explain why passing
> >an extra argument doesn't solve your problem.
> 
> No, please! Do not alter the foreign interface code. It works OK, and I
> have to play a little with all the options first. Currently I am working on
> an alternative ODBC-interface, which allows for several open connections at
> a time. Besides this, it should allow a user to query a database table 
> exactly the same way as he/she would query a normal predicate. Thus, queries
> like: customer(1000,Name,_,_) on an existing database should be possible. 
> Currently, the ODBC-interface by Stefano De Giorgi doesn't allow this 
> currently (as far as I can see).

I was not thinking about adding an additional argument or anything like
that. Instead, I was just thinking of adding another PL_*() call
returning the predicate_t reference to the innermost prolog predicate
running.

I am considering a radical change to the foreign interface (but optional
using an argument at the registration) that passes a reference to the
running Prolog `engine'.  In the single-threaded version only one engine
exists now.  The multi-threaded one already has multiple engines, which
are distinguished using the POSIX thread-specific-data. One might
consider allowing for multiple engines in the single-threaded version
too, which allows you to do some rather odd things :-)

	Regards --- Jan