Re: [eclipse-clp-users] ECLiPSe - C/C++ interaction

From: Kish Shen <kisshen_at_cisco.com>
Date: Wed, 11 Feb 2009 15:55:02 +0000
Hi Giuseppi,

By "directly write my predicates in Prolog", do you mean creating the 
goals in ECLiPSe syntax (in C/C++ strings), and send them to be solved 
as queries in ECLiPSe? Or do you really mean somehow write your ECLiPSe 
program in C/C++?

If you do mean write your program, then this does not make much sense -- 
you should write your program as normal ECLiPSe file(s), and then ask 
ECLiPSe to compile that file(s) (from C/C++ if you have to do so).

If you want to send goals to be solved from C/C++, using string presents 
the problem of how to retrieve the results. Persumably you want your 
results to be returned as a string. The easiest way is for the predicate 
you are calling to write the results back via an ECLiPSe queue stream. 
For example, if you call the query `do/1' from C/C++, you have do/1 
defined as followed (defined in a file that you ask ECLiPSe to compile 
first):

:- open(queue(""), write, outq). % you need to open the queue stream

do(Input) :-
    <do query>
    /* do what you want to do, puting the result in a variable Output */
    writeln(outq, Output).

The C interface provides ec_post_string(const char *), which allows a 
goal to be posted as a string. You can access the ECLiPSe queue stream 
from C using ec_queue_read(), and get the stream number from the queue 
name (outq in this case) using ec_stream_nr() (

For more information, see appendix C, Summary of C interface Functions, 
of the Embedding and Interface manual:

http://www.eclipse-clp.org/doc/embedding/embroot073.html

Some caution: the arguments for your goal, and the output you return, 
should be simple atomic terms, otherwise it is easy to get things wrong.

The above will only work if ECLiPSe is embedded into your C/C++ 
application. If you want to run ECLiPSe as an independent process, then 
you do need to use sockets to communicate with it. Socket I/O is 
supported in ECLiPSe - see the User Manual:

http://www.eclipse-clp.org/doc/userman/umsroot131.html

However, you will need to write quite a lot of support code to execute 
the data you send to ECLiPSe via a socket as a goal. If the type of data 
you want to send between ECLiPSe and your C/C++ application is limited, 
it is almost certainly easier to write a dedicated ECLiPSe program which 
communicate with your C/C++ application via sockets, in which you can 
send specific requests to your ECLiPSe program to ask for the results 
you need.


The model you outlined for interacting with ECLiPSe is basically the 
model used by the high-level generic interface, which can have the 
ECLiPSe embedded or as an independent process. Execution of ECLiPSe goal 
from the external language is supported via an `remote procesure call' 
type abstraction, as well as additional I/O queues to communicate with 
ECLiPSe. Unfortunately, only Java and Tcl are currently supported.
"
A C/C++ version of the interface can be written, and if you are 
interested in executing ECLiPSe as an independent process, then only the 
remote version of the interface needs to be written (and only the C/C++ 
side needs to be written, as the ECLiPSe side exists already). The 
amount of coding needed for this should be relatively moderate: the Tcl 
version of the remote interface is about 800 lines long.

A C/C++ version of the interface will be of general interest, as it will 
provide a higher level way to connect to ECLiPSe than the current C/C++ 
interface, and will additionally support the interfacing of a 
independent ECLiPSe process with a C application. We will welcome any 
such contribution! :-)

Both the Tcl and Java versions of the interface, plus the remote 
protocal that needs to be supported in C/C++ if you want to implement 
the remote interface, is described in the Embedding and Interfacing 
Manual. You may also want to read the paper "A High-Level Generic 
Interface to External Programming Languages for ECLiPSe", available in 
postscript form at

http://www.eclipse-clp.org/reports/eclipse_generic_interface.ps.gz

which discuss some of the high-level concepts and issues about the 
interface.

Cheers,

Kish

Giuseppe Di Guglielmo wrote:
> Dear all,
> I am developing a C/C++ module which has to interact with ECLiPSe. 
> 
> A first solution is to look at "Embedding and Interfacing Manual", but I'd
> like to open something like a pipe or a socket versus ECLiPSe to directly
> write my predicates in Prolog and submit them to ECLiPSe. Moreover I have to
> retrieve the results from ECLiPSe to C/C++. How can do it? Does exist any
> example?
> 
> C/C++ module ---> communication channel ---> ECLiPSe
>        ^               Prolog                    |
>        |-------- communication channel <---------|                    
> 
> Best regards,
> Giuseppe
> 
> 
> 
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> ECLiPSe-CLP-Users mailing list
> ECLiPSe-CLP-Users_at_lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/eclipse-clp-users


-- 
This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.
Cisco Systems Limited (Company Number: 02558939), is registered in
England and Wales with its registered office at 1 Callaghan Square,
Cardiff, South Glamorgan CF10 5BT.
Received on Wed Feb 11 2009 - 15:55:08 CET

This archive was generated by hypermail 2.2.0 : Thu Feb 02 2012 - 02:31:58 CET