[mod.ai] What's wrong with Turbo Prolog

CS.VANSICKLE@R20.UTEXAS.EDU (09/19/86)

1. Is Borland's Turbo Prolog a superset of the Clocksin &
   Mellish (C & M) standard?

On the back cover of Turbo Prolog's manual is the description
"A complete Prolog incremental compiler supporting a large
superset of Clocksin & Mellish Edinburgh standard Prolog." 
This statement is not true.  On page 127 the manual says
"Turbo Prolog . . . contains virtually all the features
described in Programming in Prolog by Clocksin and Mellish." 
If you read "virtually" as "about 20% of" then this statement
is true.  Turbo Prolog does use Edinburgh syntax, that is,

	:- for "if" in rules, 
	capitalized names for variables, 
	lower case names for symbols, 
	square brackets for delimiting lists, and 
        | between the head and tail of a list.

Almost all the Clocksin & Mellish predicates have different
names, different arguments, or are missing entirely from Turbo
Prolog.  For example, "var" is "free," and "get0" is
"readchar."  Differences in predicate names and arguments are
tolerable, and can be handled by a simple conversion program
or by substitutions using an editor.  They could also be
handled by adding rules that define the C & M predicates in
terms of Turbo Prolog predicates, for example,

	var(X):-free(X).

These kinds of differences are acceptable in different
implementations of Prolog.  Even C & M say that their
definition should be considered a core set of features, that
each implementation may have different syntax.  However,
Borland has done much more than just rename a few predicates.

2. Is Borland's Turbo Prolog really Prolog?

NO. Turbo Prolog lacks features that are an essential part of
any Prolog implementation and requires declarations.  Borland
has redefined Prolog to suit themselves, and not for the
better.

A key feature of Lisp and Prolog is the ability to treat
programs and data identically.  In Prolog "clause," "call,"
and "=.." are the predicates that allow programs to be treated
as data, and these are missing entirely from Turbo Prolog. 
One use of this feature is in providing "how" and "why"
explanations in an expert system.  A second use is writing a
Prolog interpreter in Prolog.  This is not just a
theoretically elegant feature, it has practical value.  For a
specific domain a specialized interpreter can apply domain
knowledge to speed up execution, or an intelligent
backtracking algorithm could be implemented.  In C & M Prolog
a Prolog interpreter takes four clauses.  Borland gives an
example "interpreter" on page 150 of the Turbo Prolog manual -
nine clauses and twenty-two declarations.  However, their
"interpreter" can't deal with any clause, it can only deal
with "clauses" in a very special form.  A clause such as
likes(ellen,tennis) would have to be represented as

  clause(atom(likes,[symbol(ellen),symbol(tennis)]),[]) 

in Borland's "interpreter."  I don't expect "clause" to
retrieve compiled clauses, but I do expect Prolog to include
it.  By dropping it Borland has introduced a distinction
between programs and data that eliminates a key feature of
Prolog. 

Turbo Prolog absolutely requires data typing.  Optional typing
would be a good feature for Prolog - it can produce better
compiled code and help with documentation.  However, required
typing is not part of any other Prolog implementation that I
know of.  Typing makes life easier for the Turbo Prolog
compiler writer at the expense of the Turbo Prolog
programmers.  A little more effort by the few compiler writers
would have simplified the work of the thousands of potential
users.  There are good Prolog compilers in existence that do
not require typing, for example, the compiler for DEC-10
Prolog.  It may also be that Borland thought they were
improving Prolog by requiring typing, but again, why not make
it optional?

Besides introducing a distinction between programs and data,
Turbo Prolog weakens the ability to construct terms at run
time.  One of the great strengths of Prolog is its ability to
do symbolic computation, and Borland has seriously weakened
this ability.  Again this omission seems to be for the
convenience of the compiler writers.  There are no predicates
corresponding to the following C & M predicates, even under
other names: "arg," "functor," "name," "=..," "atom,"
"integer," and "atomic."  These predicates are used in
programs that parse, build, and rewrite structured terms, for
example, symbolic integration and differentiation programs, or
a program that converts logical expressions to conjunctive
normal form.  The predicate "op" is not included in Turbo
Prolog.  Full functional notation must be used.  You can write
predicates to pretty print terms, and the manual gives an
example of this, but it is work that shouldn't be necessary.
Dropping "op" removed one of Prolog's strongest features for
doing symbolic computation.   

Turbo Prolog introduces another distinction between clauses
defined at compile time and facts asserted at run time. 
Apparently only ground terms can be asserted, and rules cannot
be asserted.  This may be partly a result of having only a
compiler and no interpreter.  The predicates for any facts to
be asserted must be declared at compile time.  This is another
unecessary distinction for the convenience of the compiler
writers.

One other annoyance is the lack of DCG rules, and the general
difficulty of writing front ends that translate DCG rules and
other "syntactic sugar" notations to Prolog rules.   

3. Is Turbo Prolog suitable for real applications?

I think Turbo Prolog could run some real applications, but one
limitation is that a maximum of 500 clauses is allowed for
each predicate.  One real application  program computes the
intervals of a directed graph representing a program flow
graph.  Each node represents a program statement,  and each
arc represents a potential transfer of control from the head
node to the tail node.  There is a Prolog clause for each node
and a clause for each arc.   A program with 501 statements
would exceed Turbo Prolog's limit.  I assume Borland could
increase this limit, but as it stands, this is one real
application that Turbo Prolog would not run.

4. Is there anything good about Turbo Prolog?

YES. I like having predicates for windows, drawing, and sound.
It looks easy to write some nice user interfaces using Turbo
Prolog's built in predicates.  The manual is well done, with
lots of examples.  There is easy access to the facilities of
MS-DOS.  There is a good program development environment, with 
windows for editing code, running the program, and tracing. 
There are also features for allowing programming teams to
create applications - modules and separate name spaces.  At
$100 the price is right.  If this were Prolog, it would be a
great product.

-- Larry Van Sickle
   cs.vansickle@r20.utexas.edu    512-471-9589
-------