From jan@swi.psy.uva.nl  Fri Feb  4 16:35:57 2000
Received: from gollem.swi.psy.uva.nl (root@gollem [145.18.152.30])
	by swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id QAA22620;
	Fri, 4 Feb 2000 16:35:57 +0100 (MET)
Received: (from jan@localhost)
	by gollem.swi.psy.uva.nl (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id QAA06609;
	Fri, 4 Feb 2000 16:36:10 +0100
Date: Fri, 4 Feb 2000 16:36:10 +0100
Message-Id: <200002041536.QAA06609@gollem.swi.psy.uva.nl>
From: Jan Wielemaker <jan@swi.psy.uva.nl>
Subject: Re: foreign_library implementation question
To: "Sommer, EJ (ICT)" <e.j.sommer@kpn.com>,
        "'prolog@swi.psy.uva.nl'" <prolog@swi.psy.uva.nl>
In-Reply-To: ICT's message of Fri, 4 Feb 2000 14:56:01 +0100 
Phone: +31 - 20 - 525 6121

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

