Prolog Glue Language?

[Jon Fernquest]

Prolog Glue Language?....

Gordan McMillan wrote:
>General parsing books are rare (most focus on some obscure
>corner of a very large turf), and the "intro" ones usually hand
>hold you through building one according to the author's choice
>of tools without conveying any deeper understanding, or any
>idea how big the turf really is.
>The "best" book is available at

http://www.cs.vu.nl/~dick/PTAPG.html

>(thanks to Tim for this reference). This maps the turf very well, but you
>won't really learn "how".

This book is great! Thanks.

A great complement to the extended descriptions in this book
are the extremely concise descriptions in the paper:

Principles and Implementation of Deductive Parsing
Stuart M Shieber, Yves Schabes, and Fernando C.N. Pereira
http://www.eecs.harvard.edu/~shieber/papers.html

It offers very concise specifications of several
parsing algorithms including the following:

1. CYK (4 lines)
2. Pure Top-Down (Recursive Descent) (5 lines)
3. Pure Bottom-Up (Shift Reduce) (5 lines)
4. Earley's Algorithm (6 lines)
5. Augmented Phrase Structure Formalisms
6. Combinatory Categorical Grammars (9 lines)
7. Tree-Adjoining Grammars (9 lines)

The flip-side of the concise descriptions is some (perhaps hard to grasp)
prolog code for the deductive engine that drives the parsing.
Which raises the question....

What is the best glue strategy for a scripting language like Python
to use with Prolog, a language for which there is a lot of outstanding
code but which is difficult to integrate into systems written with
imperative languages?

There are whole domains of problems in AI and linguistics that would have
quick reusable solutions available for them if this was possible.

People writing Prolog seem to rely a lot on proven fragments/snippets of
code that are handed down from generation of programmer to programmer
maybe because a lot of code in prolog is counter-intuitive and
difficult for the imperative programming mind to grasp
and write...like even your standard sequential read statement.

Anyway for processing natural language (parsing, semantic and discourse
interpretation)
and almost every other topic in AI Prolog has been the most extensively
used language so there is a huge body of efficient solutions already out
there.
(efficient = runs quickly on a Warren Machine (WAM), the Prolog virtual
machine).

The problem is how do you use a glue language like Python with legacy
Prolog code in the way a glue language is meant to be used
in the sense of Ousterhout's paper "Scripting: Higher Level Programming
for the 21st Century" (available at his site).

If I have a prolog module I want to integrate into a larger system
the quick and dirty solution is just to use the c converter that usually
comes with most prolog systems and make the c-code into an extension
to be glued into larger systems.
But I see at least two problems with this:

1. There is no standard interface to c across all prolog systems.
2. The c code generated is going to make porting the module to all
platforms the scripting language runs on more difficult.

Isn't a better approach to have a Warren machine built right into the
scripting language as an extension so that Prolog code could be embedded
right into scripts? (Note: There are Warren machines written in C++ out
there
in the public domain.)

I've tried rewriting Prolog code in imperative languages,
but that's a losing battle.....
with it's unification and backtracking capabilities
Prolog is still the best tool out there for a wide range of problems.
The problem is, *it needs a glue language more than the languages that
already have
a glue language* like C, C++, Java...

What to do?

Jon Fernquest
bayinnaung at hotmail.com