PROLOG-REQUEST@SUSHI.STANFORD.EDU.UUCP (03/13/87)
PROLOG Digest Friday, 13 Mar 1987 Volume 5 : Issue 15
Today's Topics:
Implementation - Logical Variable & Turbo & Lint & Confusion
----------------------------------------------------------------------
Date: Thu, 12 Mar 87 11:08:45 PST
From: Fernando Pereira <pereira@sri-candide.ARPA>
Subject: Logical variable in Turbo Prolog
Mike Newton's original message/review, and the observations for which
I got thanks :-), were for an early version of Turbo Prolog. I've not
experimented with Turbo since then, but from looking at a manual it
appears that it is possible to declare parameters or structure members
as ``reference'', allowing that example to run as Steve Hardy pointed out.
However, this does not mean one has the full power of the logical variable,
because the ``reference'' objects must be predeclared. Will the following
work in Turbo?
?- eq(f(X), FX), eq(FY, f(Y)), eq(FX, FY), eq(FX, f(a)).
with eq defined by
eq(X, X).
-- F
------------------------------
Date: 10 Mar 87 13:29:31 GMT
From: Chris Moss <mcvax!ukc!icdoc!cdsm@seismo.css.gov>
Subject: How do you like Turbo-Prolog?
> /***** iaoobelix:comp.lang.pro / thumper!steve / 5:30 pm Feb 28, 1987*/
> > I'm just starting with prolog, and for $99 Turbo-Prolog looks
> > attractive. I'd like to know what people think of it.
> > -Steve Miller ihnp4!bellcore!thumper!steve
This is SILLY. It would be better to say Prolog with Pascal type
structure. Clearly its biggest failing is that it doesn't have a
polymorphic type checker (a la Mycroft/O'Keefe paper for instance).
But its type system is better than theirs in some respects (one can
declare subdomains which do get some checking).
Personally I doubt that I'd use Turbo much, but I'm real interested to
see how much people like the addition of typechecking. If you think you
can't write REAL programs in Turbo, look at their program disk. There's
a neat natural language system there that is efficient and extensible.
-- In case you want to know, they get round the lack of metacall easily
by effectively defining "call" for all the queries (in the internal
query language) they want to do.
> Also, and most seriously (thanks to Fernando Pereira) there are two more
> *MAJOR* problems: the logical variable doesn't really
> exist: it is a runtime error to do variable-to-variable unifications
> as in
> p(X,X).
>
> ?- p(X,Y), p(X,a).
>
This is plain WRONG! I have just typed and executed the following
program:
domains
rsymbol = reference symbol
predicates
eqn(rsymbol, rsymbol)
clauses
eqn(X,X).
and executed the following queries with the results (more or less
verbatim from the screen):
Goal : eqn(X,foo)
X=foo
1 solution
Goal : eqn(X,X)
X=_
1 solution
Goal : eqn(X,Y)
X=_, Y=_
Goal : eqn(X,Y), eqn(Y,foo)
X=foo, Y=foo
1 solution
I think this shows the pluses and minuses of TurboProlog.
a. eqn only works on symbols (atoms) not other things (as it stands).
It's impossible to write a full "eq".
b. You must inform it (by "reference") if you want full unification -
i.e. unbound variables in the result.
c. Leaving out the reference in the domain gives a run-time error for
the second and after goals.
d. It's got MASSES of error messages - far more, and I dare say, far
better than most other Prolog systems.
e. The domain and predicate declarations are good documentation but
pretty onerous. In particular it's wrong to declare but not finish a
definition - Not good for top-down program development.
> The article forwarded by Mike Newton seem to ascribe some of these
> modifications to Fernando Pereira. If he was reponsible for these, I
> must admit to some surprise since he was involved in the early
> implementations of DEC-10 Prolog, and really should have known better....
> Rick Innis (csrdi@its63b.uucp || rick@uk.ac.edinburgh)
Before this gets too much circulation, Fernando was CRITICIZING not
IMPLEMENTING Turbo (and whether he was cited correctly I don't know.
Were you, Fernando?) It was actually implemented by some guy in Denmark
whose name I forget right now.
To sum up, I'm NOT advocating Turbo, but if you want to criticize
get your facts right!
-- Chris Moss
------------------------------
Date: Thu, 12 Mar 87 05:46:25 pst
From: Randy Reed <tektronix!reed!iscuva.ISCS.COM!randyg@cad.Berkeley.EDU>
Subject: Lint
Alint(Arity lint) is a program that does "Lint" style checking for
Arity prolog. That means it checks for suspicious code, Variables only
referenced once(A sure sign you mispelled something, typo's being the
main source of errors in Prolog), predicates not referenced elsewhere,
type mismatches, and other errors. The reason Lint is not usually part
of the compiler is that a good lint will be somewhat overenthusiastic
in finding errors (you never get a completely clean program). Borland
included it in their compiler, and forces you to press a key to ignore
a found error. Kludging around a bug in turbo, such as the set
predicate findall in 1.0, can be a nightmare.
-- Randy Gordon
------------------------------
Date: 11 Mar 87 11:26:16 GMT
From: Drew Adam <mscvax!inria!crcge1!adams@seismo.css.gov>
Subject: How do you like Turbo-Prolog?
Rick Innis writes:
>Maybe I'm just spoiled rotten from living where Prolog was first
>implemented, but having used three generations of Prolog interpreters I
...
> Rick Innis (csrdi@its63b.uucp || rick@uk.ac.edinburgh)
I'm confused... you live in Marseille but your e-mail address is Edinburgh?
(Or does "from living" mean "from having lived [in Marseille]"?)
------------------------------
End of PROLOG Digest
********************randyg@iscuva.UUCP (03/16/87)
*GLACK* My name is Randy GORDON, NOT RANDY REED! (header of last prolog digest entry) Over the past couple of years, ISC's Eye to AI group has developed the same program(Business Case Analyzer) in C, Lisp, Scheme, Ops5(Actually FLOPS, a much superior PC clone), and both Turbo Prolog and Arity Prolog. (We were investigating what language to use and things got a little carried away). Version 10.4 occupies roughly 2.75 Megabytes of disk and 400K of source code(the rest is database information). Its written in Arity prolog. Turbo had nicer features(the includable editor is sorely missed) but it just couldn't handle the load. Thats the major problem with Turbo ... Limitations. Limitations in number of predicates, in amount of data, in lots of areas. Sure you can kludge around the missing parts of Edinburgh prolog, and in lots of applications you don't even need to kludge. Arity is about half as fast, but you don't need to kludge. You dont have to play with overlays in Arity, you can include the interpreter into your compiled code royalty free, and have up to a GIGABYTE of source code and let the automatic virtual memory worry about overlaying. Most of the SCORE libraries work without change(and are available on the Arity bulletin Board)and there is user written code for such things as a forward chaining OPS5, and a windowing system, as well as a San Marco Explorer type tutorial(Active Prolog Tutor). Best of all, you can move up to a mainframe prolog with little effort. The tech support is much better than Borlands(At least at the time I dealt with Turbo, but they might have improved since then). There is even an EMYCIN like expert system and a full DB2 compatable SQL database available. I would have to disagree about how easy it is to learn Turbo prolog. Turbo was the prolog I first learned prolog programming with, and most of my books quickly died on the lack of dynamic programming predicates. A beginner just has too little experience to kludge up substitutes, and as far as I know (and I have examined most every prolog book out) there is no advanced prolog book (ala Marcus, Shapiro, Kluzniak, etc.) suitable for learning with Turbo. In short, Turbo is good only if you have a relatively small program or a really experienced and talented prolog programmer. If you just want the specialized toolkit that comes with it, you would be better off in Turbo Pascal. Randy Gordon "Tao ku tse fun pee" Disclaimer: I am not affiliated with Arity and these opinions are my personal ones and not necessarily those of my company.