Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!ll-xn!cit-vax!alfke From: alfke@cit-vax.UUCP Newsgroups: comp.lang.prolog Subject: Re: Re: How do you like Turbo-Prolog? - (nf) Message-ID: <2024@cit-vax.Caltech.Edu> Date: Thu, 12-Mar-87 17:22:09 EST Article-I.D.: cit-vax.2024 Posted: Thu Mar 12 17:22:09 1987 Date-Received: Fri, 13-Mar-87 21:47:50 EST References: <1974@cit-vax.UUCP> <7000004@iaoobelix.UUCP> Reply-To: alfke@cit-vax.UUCP (J. Peter Alfke) Organization: California Institute of Technology Lines: 77 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"