🚀 go-pugleaf

> /***** 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
> 
> Roughly speaking, TurboProlog is Pascal with Prolog syntax.
> (Sorry, I couldn't resist (:-)) I'd prefer a *real* Prolog.
> 
> Juergen Wagner,                (USENET)  ...seismo!unido!iaoobel!wagner
>                                     Fraunhofer Institute IAO, Stuttgart

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, Imperial College, London.