From e.j.sommer@kpn.com  Fri Feb  4 16:23:07 2000
Received: from relay2.kpn-telecom.nl (relay2.kpn-telecom.nl [145.7.200.7])
	by swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id QAA21603
	for <prolog@swi.psy.uva.nl>; Fri, 4 Feb 2000 16:23:03 +0100 (MET)
Received: from sat-relay2.pc.telecom.ptt.nl (sat-relay2.telecom.ptt.nl [145.7.194.2])
	by relay2.kpn-telecom.nl (8.9.0/8.9.0) with ESMTP id QAA16897
	for <prolog@swi.psy.uva.nl>; Fri, 4 Feb 2000 16:23:16 +0100
Received: from tmail001s.telecom.ptt.nl (tmail001s.pc.telecom.ptt.nl [145.7.210.58])
	by sat-relay2.pc.telecom.ptt.nl (8.9.0/8.9.0) with ESMTP id QAA02873
	for <prolog@swi.psy.uva.nl>; Fri, 4 Feb 2000 16:23:14 +0100
Received: by tmail001s.pc.telecom.ptt.nl with Internet Mail Service (5.5.2448.0)
	id <12SLCRV0>; Fri, 4 Feb 2000 16:23:43 +0100
Message-ID: <DC93009AB791D211B1FF00805F85392146C182@rome.pc.telecom.ptt.nl>
From: "Sommer, EJ (ICT)" <e.j.sommer@kpn.com>
To: "'prolog@swi.psy.uva.nl'" <prolog@swi.psy.uva.nl>
Subject: Re: foreign_library implementation question
Date: Fri, 4 Feb 2000 14:56:01 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"

Jan, 
thanks for your direct response,

>>A burning question:
>>
>>From my foreign_library C file, I want to register/map several prolog
>>predicates to the same C function. Within this C function I want to
>>determine the (name of the) actual calling predicate. Can this be done?
>>
>>Background: I want to be able to generate predicates dynamically, and
handle
>>them using a generic handler.
>
>Odd plan :-)  Basically you can do it using a call-back to Prolog, get
>a reference to the current stack and walk up until you find the
>call-back.  The predicates are prolog_frame_attribute/3 and friends.
>
>This however is not really what you want, I guess.

Stack walking is most certainly not the thing I want to do (right now).

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

Thanks,
Eelco.









