steve@thumper.UUCP (02/28/87)
I'm just starting with prolog, and for $99 Turbo-Prolog looks attractive. I'd like to know what people think of it. -thanks, -- -Steve Miller ihnp4!bellcore!thumper!steve "The Fantasy Factory" is a trademark of Image Space, a New Jersey corporation.
wagner@iaoobelix.UUCP (03/05/87)
> /***** 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 Disclaimer: "The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary."
alfke@cit-vax.Caltech.Edu (J. Peter Alfke) (03/08/87)
In article <7000002@iaoobelix.UUCP> wagner@iaoobelix.UUCP writes: >Roughly speaking, TurboProlog is Pascal with Prolog syntax. >(Sorry, I couldn't resist (:-)) I'd prefer a *real* Prolog. Look, whenever I mention to anyone that I'm using Turbo-Prolog, I get snickers and a reply just like yours. No one ever gives any real evidence as to WHY Turbo-Prolog is not "real" prolog. I'm using Turbo for my homework projects in a compiler class; I find it's environment far far more pleasant than using cprolog on an overloaded VAX. I'm writing a compiler, and so far my difficulties are about 80% with the Prolog language itself and 20% with differences between Turbo and standard Prolog. The major difference between Turbo and regular prolog: * No user-definable operators * No grammar-rules (but this is just a syntactic transformation) * Type-checking Most of the abuse Turbo gets is based on the last one. It puts me in mind of Fortran or C hackers looking at Pascal and saying "oh, gross, you have to *declare* variables and *keep track of types*". The type-checking doesn't seem to limit the power of the language, and there are good things to be said for spelling out your data-structures at the beginning of the program. So please ... can someone who has honestly sat down and USED Turbo-Prolog tell me precisely why it's not really Prolog at all. I've been using it for a while now and it looks just like Prolog to me ... -- I try my hand, I try my hand at sculpture --Peter Alfke I take a lump of clay, I make it into something alfke@csvax.caltech.edu It stands all by itself, a monument to culture I stand beside myself and still I'm next to nothing. ::Savage Republic::
newton@cit-vax.Caltech.Edu (Mike Newton) (03/08/87)
[This is a review of Turbo Prolog sent out in response to Peter Alfke's
recent comments on net.lang.prolog. The review was originally sent to the
AI-DIGEST many months ago, but I believe that net.lang.prolog would also
be a good place for it!]
[Also, in response to Peter's comments about the speed of the vax --
Cprolog runs on all of our suns, at (*real*) speeds (see notes below)
that are much better than Turbo's]
[ Caveats to remember when reading this review: I have *not* read all
of the manual, nor used it on many programs. Views expressed are
from the perspective of someone who has done the code generation and
evaluatable predicates for a high speed (~900 KLips on one processor
of a IBM 3090) prolog compiler. I have no affiliation with
Borland, and only a (*very*) indirect affiliation with IBM -- MON]
From a local software store we purchased Turbo Prolog over the weekend.
It came as a cellophane wrapped book with a couple of floppies. It cost
$69.95, list of $99.
The enviromnent was very nice. There was a window for the editor, goals
debugging information and messages. This seemed well done, and responded
reasonably well (I am not used to IBM-PC's.)
The unfortunate part was the Pascal-ization of the language. Everything
had to be typed (they called it domains). As far as I could tell, lists
had to be composed soley of other lists or elements all of one type. One
had to define the possible terms (giving the functor) that could be
arguments to a predicate. It seemed impossible to write generic predicates
for dealing with arbitrary types of terms.
Ex: to have a term that could be a 'symbol' (atom) or an integer
one had to do this:
domains
aori = a(atom) or i(integer)
It was not possible to just use an atom or an integer as a subterm...
Typing each subterm of a term is not my idea of Prolog.
After about an hour we got the 'standard' timing example of naive
reverse running (Some people have used other, non-environment-creating
samples. This is an unfair comparison). It did 496 unifications in
aproximately 11/100 of a second. This amounts to a speed of a little
under 5 Klips. Considering that they do not need to do 'real' unification
(since everything is pre-typed, and thus can be reduced to a simple test),
this speed is not particularly impressive.
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).
And, it is not possible to assert clauses with variables.
In summary, I would say that there advertising is at best a
misrepresentation. They are not selling a 'Prolog' system!
(If I owned a TM on the word 'Prolog', I would be tempted to sue them!)
newton@cit-vax.caltech.edu {ucbvax!cithep,amdahl}!cit-vax!newton
Caltech 256-80 818-356-6771 (afternoons,nights)
Pasadena CA 91125 Beach Bums Anonymous, Pasadena President
"Life's a beach, then you graduate"csrdi@its63b.ed.ac.uk (ECTU68 R Innis CS) (03/09/87)
Maybe I'm just spoiled rotten from living where Prolog was first implemented, but having used three generations of Prolog interpreters I honestly can't say that Turbo is what I think of as Prolog. When I think Prolog, I think 'Edinburgh Syntax' - which is, after all, the de facto standard. The notion of type checking, call it what you will, just doesn't seeem to me to be part of Prolog. 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)
cdsm@icdoc.UUCP (03/10/87)
> /***** 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.
newton@cit-vax.Caltech.Edu (Mike Newton) (03/11/87)
>>> 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 By "thanks to Fernando Pereira" I meant "thanks to him for pointing this out to me". I believe he was as upset as I was about the changes. - mike newton
adams@crcge1.UUCP (03/11/87)
In article <316@its63b.ed.ac.uk> csrdi@its63b.ed.ac.uk (Rick Innis, CS3) 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]"?)
wagner@iaoobelix.UUCP (03/11/87)
> /***** iaoobelix:comp.lang.pro / cit-vax!newton / 9:19 am Mar 8, 1987*/ > > The unfortunate part was the Pascal-ization of the language. Everything > had to be typed (they called it domains). As far as I could tell, lists > had to be composed soley of other lists or elements all of one type. One > had to define the possible terms (giving the functor) that could be > arguments to a predicate. It seemed impossible to write generic predicates > for dealing with arbitrary types of terms. It is even impossible to write certain applications (e.g. parsers for natural language) that have to use lists containing arbitrary objects (i.e. symbols, lists, terms, ...). > Typing each subterm of a term is not my idea of Prolog. I absolutely agree. > 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). > > And, it is not possible to assert clauses with variables. My opinion is that everybody working with real Prologs who tried to use TurboP????? encounters the same kind of problems as soon as one starts to write a typical Prolog program. Therefore, my flame about TurboP????? was just the conclusion, not the explanation. Most of the problems come from the fact that you have to declare variables. Of course, it is possible in programming languages like C or some versions of PASCAL to use loopholes or type casts to get around type checks and to change an int into a pointer to char or whatever. I agree, this can be very dangerous and the programmer has to be aware of them. On the other hand, languages like Lisp or Prolog *ARE NOT TYPELESS* and *DO HAVE TYPE-CHECKING*. The only difference is that in PASCAL or C or (for heaven's sake) FORTRAN the program (or each individual function call) has to know about the types of any data objects involved, whereas in Lisp or Prolog you have objects knowing of which type they are. This requires, of course, an entirely different (in fact, a much more sophisticated) memory management and garbage collection, what might have been the reason for Borland to write a TurboP????? rather than a ?????Prolog. You see, both PASCAL and Prolog do have type-checking but while PASCAL does checks at compile-time (and is able to do so because of the presence of declarations), Prolog (and other AI languages) use a dynamic type- checking at runtime, on one hand releaving the programmer of caring about some problems with type conflicts, and on the other hand enabling him/her to write generic functions/predicates. By the way, I am using CProlog1.5+ on Suns and it runs pretty fast. Juergen Wagner, (USENET) ...!unido!iaoobel!wagner ("Gandalf") Fraunhofer Institute IAO, Stuttgart Note: "God is REAL (unless declared INTEGER)." ...vanilla disclaimer...
csrdi@its63b.UUCP (03/11/87)
Apologies to Steve Miller and Fernando Pereira, if any offence is taken by my misreading of Steve's article. Also thanks to Chris Moss, for setting the record straight. --Rick
alfke@cit-vax.UUCP (03/13/87)
In article <7000004@iaoobelix.UUCP> wagner@iaoobelix.UUCP writes: >It is even impossible to write certain applications (e.g. parsers for >natural language) that have to use lists containing arbitrary objects >(i.e. symbols, lists, terms, ...). Domains listelement = s(symbol); i(integer); z(string*); /* et cetera */ mylist = listelement* Don't say it's impossible. It takes a little bit more effort, but whatever you want to put in your list, you add that type, with an identifying functor, to your 'listelement' declaration and you can put it in. I'm writing a compiler, so I have lists of tokens, of which tokens fall into many different kinds including numbers, characters and identifyers (symbol- table entries). I also have parse-trees with different data-types being stored in different kinds of nodes. >> Typing each subterm of a term is not my idea of Prolog. > >I absolutely agree. It may not be your idea of Prolog, but it works just fine and I would certainly call it Prolog. We're moving into realms of aesthetics here, and the constant refrain of "it can't be Prolog because MY Prolog doesn't have typing" is beginning to sound rather whiny. The type-checking has very little impact on what can be expressed in the language. >My opinion is that everybody working with real Prologs who tried to use >TurboP????? encounters the same kind of problems as soon as one starts to >write a typical Prolog program. Therefore, my flame about TurboP????? was >just the conclusion, not the explanation. Obviously, since on has to do many things a bit differently (and admittedly a bit less simply). But once you learn to express things, it's at heart the same language. I can take examples from class or from Clocksin and Mellish and run them in Turbo after minimal changes. >The only difference is that in PASCAL or C or (for heaven's sake) FORTRAN >the program (or each individual function call) has to know about the types >of any data objects involved, whereas in Lisp or Prolog you have objects >knowing of which type they are. This requires, of course, an entirely >different (in fact, a much more sophisticated) memory management and >garbage collection, what might have been the reason for Borland to write >a TurboP????? rather than a ?????Prolog. I don't see that. It does simplify unification, but as far as I can tell (and I have some idea of how a Prolog compiler works) it doesn't result in the drastic simplifications you imply. TURBO PROLOG IS NOT PASCAL. Can I make a dumb little analogy here? Thanks. If Pascal is oranges and Prolog is apples, the Turbo Prolog is, say, a Granny Smith apple instead of the Golden Delicious apple of 'standard' Prolog. Get my drift? >Prolog (and other AI languages) use a dynamic type- >checking at runtime, on one hand releaving the programmer of caring about some >problems with type conflicts, and on the other hand enabling him/her to >write generic functions/predicates. I realize how neat this is, having considerable experience with Smalltalk. That Turbo is missing a lot of this is a disadvantage, but it's one I'm willing to live with, and it doesn't make it somehow "not Prolog". I have backtracking, logical variables, unification and all those wonderful things, in a really excellent development environment. And it runs on a PC that I can keep in my room. Sorry to keep going on about this, but the valid comments I hear about the language are far outnumbered by groundless bitching of a very Not-Invented- Here variety. Keep an open mind, guys. -- --Peter Alfke (grooving on an inner plane) alfke@csvax.caltech.edu "facts are living turned inside-out"
paddy@cvaxa.UUCP (04/01/87)
> > Maybe I'm just spoiled rotten from living where Prolog was first > implemented, but having used three generations of Prolog interpreters I > ... I didnt realise Edinburgh was in Marseille since that is where prolog comes from ( 1972 ish ).