(Prolog + LISP + Erlang) with integration issues versus C++

[Thomas Lindgren]

-- Dev Functional <devfunctional@REDACTED> wrote:

> Hello
> 
> Given the insistence of the members of the team to
> use the
> best language for specific purpose, we have code
> that is
> written in
>  1. Prolog (enumerating device drivers, goal seek)
>  2. LISP   (classical AI stuff, inference)
>  3. Erlang (server, communication and
> distributedness)
> 
> The products we have used are
>  1. gprolog
>  2. clisp
>  3. Erlang/OTP
> 
> The independent modules have been developed
> successfully,
> however we are unable to surmount the language
> boundaries
> and connect Erlang to Prolog, Erlang to CLisp and
> CLisp to Prolog.
> 

Since the system components seem to be designed "at
arms length" from each other, the quickest way of
integrating the three is probably by using sockets or
pipes and your own simple protocol on top of that.

Use s-expressions or text as the transfer format as
far as possible. (Or perhaps XML makes a nice bullet
point, if you can afford it.) Corba or some other such
solution could also be done, if it's politically
useful and you know how to work with it, and all
involved systems have it. 

With the above approach, gradual integration of C++ is
also feasible, if so desired. Just hook in a C++
process in the same way. You retain the option of
migrating to C++, yet have a working system around,
and can switch over gradually. (If management are
feeling jittery.)

Simple C++ subsystems can usually be integrated via
FFI into Lisp or Prolog, or via drivers in Erlang.
(For example, Wings3D integrates SDL and OpenGL into
an Erlang modeller; see http://www.wings3d.com/)

You could also conceivably use FFIs or Erlang drivers
to connect the three, though I'd investigate that only
if there really _is_ a performance problem. It's
likely to be a lot of work for little gain otherwise.

Have a look at whether performance problems are
likely. Regarding integration per se, the main issue
is _probably_ to avoid swapping and keeping all three
processes in memory. If it's an internal product, take
the memory upgrade cost from the budget required to
redevelop the whole thing in C++ :-)

Oh yeah, a system for testing that the protocol(s) is
or are implemented faithfully is probably a good thing
to have around. That way, you can quickly test that
the components are sending and receiving the right
things by having the test system run through some
"unit tests". 

At the same time, having a central 'hub' to monitor
messaging between components can also be a good idea
for debugging or even for deployment. 

Write such a hub/tester in Erlang.

Best,
Thomas


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com