Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!comp.vuw.ac.nz!canterbury.ac.nz!fore057 From: fore057@canterbury.ac.nz Newsgroups: comp.lang.prolog Subject: Re: Turbo Prolog 2.0 tip Message-ID: <1990Oct31.112423.9588@canterbury.ac.nz> Date: 30 Oct 90 22:24:23 GMT References: <4097@goanna.cs.rmit.oz.au> <1990Oct27.085854.9537@canterbury> <1990Oct30.093255.9575@canterbury.ac.nz> <4145@goanna.cs.rmit.oz.au> Organization: University of Canterbury Lines: 88 In article <4145@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >> If you were using readterm, then you must have declared the database structure, > > This is simply false. When you use readterm/2, you supply a DOMAIN, e.g. > readterm(recipe, ThisRecipe) > but there isn't any reason whatsoever to suppose that a "recipe" value can > *ever* appear in the data base. Predicates declared in a data base section > are one thing, domains declared in a domains section are another thing. Yes, my mistake. I glanced at the example in the reference, which shows a database term being read with readterm. >> and I naturally assumed that you could equally well use a consult, > > What is natural about it? Turbo Prolog goes to rather extreme lengths > to DISTINGUISH between facts (things that are declared in a DATABASE > section) and terms (things whose type is declared in a DOMAINS section). > You can *only* use consult/1 to load facts (which are not in general > well-typed TERMS) and you can *only* use readterm/2 to read well-typed > terms (which are not in general acceptable as facts in the data base). > A much more natural assumption is: > > if you *can* use consult/1 to load a file, > then you most likely *can't* use readterm/2 to read it > without adding a whole lot of new domains You can use a dbase name as the domain, as shown in the reference example. Dbase names are a type of domain in Turbo Prolog. Database terms can also be written directly into compiled code. >> I can appreciate your frustration if consulting prolog program code is what >> you're used to. As a developer of industrial applications, I find the other >> features offered by PDC Prolog more than compensate for this lack, although I >> accept that I haven't had the opportunity to try all the varieties of Prolog >> on offer. > > Which other features? If you want a logic-based language with strict > typing and good efficiency and a nice screen-oriented interface, you > would do well to use Trilogy. Surely the point of using something called > "Prolog" is to get something that _acts_ like Prolog? After all, there is > no speed advantage from Turbo Prolog. Developing code is much easier under > say ALS Prolog, and the code runs fast... The point in my using TP is that it does what I want it to do. If it were called something else, that wouldn't bother me. If I get opportunities to try Trilogy or ALS Prolog, I'll take them, thanks for the info. You certainly don't like TP, from the sounds of it. Would you be happier if it was called some thing other than Prolog? > But "consulting Prolog program code" is irrelevant to the point I was > making here. The point is that we have data items which can appear in > source code and data items which can appear in a file. There is no > good reason for making them different. (Think about using a program to > write another program. Think about debugging and test data sets.) I agree. I didn't realise that readterm could access a wider range of domain types than consult. It would seem that there are two difficulties: 1) Symbols have to be saved as strings in order to be accessed. I have no difficulties with this. All the knowledge-bases are saved by users of compiled code in my programs anyway. 2) Clauses with tails cannot be accessed through either consult or readterm. This would be a nice feature. I got around this to some extent when I wrote an simple expert system shell by stating rules as facts in the form: condition(,,) where the nodename could either refer to a user-defined menu, or to another fact with the answer either yes or no. It meant I had to program my own backward chaining engine, rather than rely on backtracking directly. This was useful, as I was able to incorporate levels of certainty, and to have the shell tailor questioning detail to user's abilities to some extent. It also allowed a weighting of the relative importance of facts when deciding on any particular outcome, and a final answer generated by a comparison of probabilities rather than a simple monotonic determination. Regards, Euan " '...the patriotic Archbishop of Canterbury, found it advisable..' 'Found *what*?' said the Duck. 'Found *it*,' the Mouse replied rather crossly: 'of course you know what "it" means.' 'I know what "it" means well enough, when *I* find a thing,' said the Duck: 'it's generally a frog or a worm. The question is, what did the archbishop find?' - From Alice in Wonderland, or the National party in NZ's Parliament - take your pick.