ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (10/26/90)
This may save someone else the half hour of frustrated head-scratching it caused me: if you have readterm(<domain>, <variable>) in your Turbo Prolog 2.0 program, and at run-time it complains about an unrecognised functor, the problem _may_ really be a blank line. Why won't Turbo Prolog allow layout characters in data terms? Perhaps this is how they get the "huge increase in speed" they boast of? (Actually, I _don't_ get any huge increase in speed compared with ALS...) -- Fear most of all to be in error. -- Kierkegaard, quoting Socrates.
fore057@canterbury (10/27/90)
In article <4097@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > This may save someone else the half hour of frustrated head-scratching > it caused me: if you have > readterm(<domain>, <variable>) > in your Turbo Prolog 2.0 program, and at run-time it complains > about an unrecognised functor, the problem _may_ really be a > blank line. > > Why won't Turbo Prolog allow layout characters in data terms? > Perhaps this is how they get the "huge increase in speed" they > boast of? (Actually, I _don't_ get any huge increase in speed > compared with ALS...) Whenever you read terms into memory, it pays to error trap the term-reading predicate. A section of code is quoted in the users guide (pp438-439) which will trap the readterm error, place the term file into an editor, and put the cursor at the point where the error occured. Regards, Euan "The eternal mystery of the world is its comprehensibility" - Einstein, 1936
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (10/29/90)
In article <1990Oct27.085854.9537@canterbury>, fore057@canterbury writes: > In article <4097@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > > This may save someone else the half hour of frustrated head-scratching > > it caused me: if you have > > readterm(<domain>, <variable>) > > in your Turbo Prolog 2.0 program, and at run-time it complains > > about an unrecognised functor, the problem _may_ really be a > > blank line. > Whenever you read terms into memory, it pays to error trap the term-reading > predicate. A section of code is quoted in the User's Guide (pp438-439) which > will trap the readterm error, place the term file into an editor, and put > the cursor at the point where the error occured. Well, yes, I _know_ that. In fact I used readtermerror/2 manually. The snag is I *couldn't* use the code in the User's Guide. For why? Because the code in the User's Guide is *not* about trapping errors in readterm/1, it is about trapping errors in consult/2. The actual example is trap(consult(File,mydba), Err, handleconsulterr(File,Err)) (Quintus equivalent: if_exception(ErrorTerm, mydba:consult(File), handle_consult_error(ErrorTerm)) ) Where handleconsulterr(File, Err) :- ... consulterror(_, LinePos, FilePos), ... The code to set the cursor properly depends completely on having BOTH FilePos (offset in the file where the line began) AND LinePos (offset in the line where the error began). But this information is available ONLY if you are using consult/[1,2]. If you are using readterm/1, all you get is readtermerror(Line, LinePos) where Line is a srting (a copy of the line being complained about) and LinePos is an integer, the offset within that Line of the error. Let me repeat that in very simple terms: IF you are loading terms from a file directory into memory without any of your own processing, you can use consult/1, and using consult/1 you can find out the location of an error. IF you have to do some processing of your own, you CAN'T use consult/1 (there is no term_expansion/2 hook), so you can use only readterm/1, and you CAN'T find the location of the error in the file. I was upgrading a program that read a "knowledge base" by consulting it. There were two things necessary: (1) to allow a file to refer to other files, (2) to replace file name literals that appeared in rules by absolute file names. [Would you believe that the manual nowhere makes it clear whether Turbo consult/1 is like DEC-10 consult/1 or reconsult/1?] Thus it was necessary to intervene. That meant in turn that I *COULDN'T* do what fore075@conterbury suggests; all the information available to me was readtermerror("", 0). I found the problem eventually by writing out each term after it was read. Sigh. It is *absurd* that terms written in a data file do not have the same syntax as terms written in clauses. (Layout is not permitted, full stops are not permitted, quotes are required around symbols as well as around strings, and so on.) This is pointless. -- The problem about real life is that moving one's knight to QB3 may always be replied to with a lob across the net. --Alasdair Macintyre.
fore057@canterbury.ac.nz (10/30/90)
In article <4117@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > > Well, yes, I _know_ that. In fact I used readtermerror/2 manually. > The snag is I *couldn't* use the code in the User's Guide. For why? > Because the code in the User's Guide is *not* about trapping errors in > readterm/1, it is about trapping errors in consult/2. The actual > example is > trap(consult(File,mydba), Err, handleconsulterr(File,Err)) > The code to set the cursor properly depends completely on having > BOTH FilePos (offset in the file where the line began) > AND LinePos (offset in the line where the error began). > But this information is available ONLY if you are using consult/[1,2]. > If you are using readterm/1, all you get is > readtermerror(Line, LinePos) > where Line is a srting (a copy of the line being complained about) > and LinePos is an integer, the offset within that Line of the error. If you were using readterm, then you must have declared the database structure, and I naturally assumed that you could equally well use a consult, therefore addressing the entire file, and locating the offending position. > It is *absurd* that terms written in a data file do not have the > same syntax as terms written in clauses. (Layout is not permitted, > full stops are not permitted, quotes are required around symbols as > well as around strings, and so on.) This is pointless. 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. Regards, Euan "And take upon 's the mystery of things. As if we were God's spies" - Shakespeare, King Lear
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (10/30/90)
In article <1990Oct30.093255.9575@canterbury.ac.nz>, fore057@canterbury.ac.nz 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. For example, I can do DOMAINS foo = integer PREDICATES get_int(foo) CLAUSE get_int(X) :- readterm(foo, X). Where is the database here? > 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 if you *can* use readterm/2 to read a file, then you must likely *can't* use consult/1 to read it without adding some new database declarations, and it quite likely mayn't be possible at all. Stop and think for a bit: (a) the manual does not describe clearly what consult/1 DOES! (b) assuming that you want to load from one single file (which I most definitely *didn't* want to do; I wanted to have files including other files, just as Turbo Prolog itself does) then consult/1 *still* may not be usable, because it doesn't give you any information about the relative order of facts from different relations > > It is *absurd* that terms written in a data file do not have the > > same syntax as terms written in clauses. (Layout is not permitted, > > full stops are not permitted, quotes are required around symbols as > > well as around strings, and so on.) This is pointless. > 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... 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.) -- The problem about real life is that moving one's knight to QB3 may always be replied to with a lob across the net. --Alasdair Macintyre.
fore057@canterbury.ac.nz (10/31/90)
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(<fact>,<nodename>,<answer required>) 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.
ada612@csc.anu.oz.au (11/01/90)
>After all, there is >no speed advantage from Turbo Prolog. Developing code is much easier under >say ALS Prolog, and the code runs fast... How does ALS prolog stack up against PDC/Turbo w.r.t. a) compactness of compiled code b) efficiency of storage of structures (where `reference' variables are being used all over the place) c) pleasant-to-use IO, including windows, etc. d) ability to store terms in EMS, on hard disks, etc. e) price These questions are apropos of shoehorning LFG systems for use by linguistics students into the confines of PCs without blowing personal or departmental budgets. Avery Andrews (ada612@csc.anu.oz.au)
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (11/01/90)
In article <1990Nov1.100235.3213@csc.anu.oz.au>, ada612@csc.anu.oz.au writes: > How does ALS prolog stack up against PDC/Turbo w.r.t. > a) compactness of compiled code I don't know. Since Turbot Prolog can't run Prolog code, it's rather difficult to make a meaningful comparison. > b) efficiency of storage of structures (where `reference' variables > are being used all over the place) The one thing where it is likely to do worse than Turbot is that it will take a full cell for a functor (name/arity pair) instead of a single byte. Otherwise, I'd expect as good or better. I would be surprised if it was a problem. I have noted that the Turbot programs I have seen tend to use poorly chosen data structures (such as strings), that's more likely to be a problem. > c) pleasant-to-use IO, including windows, etc. I honestly can't describe Turbot IO as pleasant-to-use. (Interlisp-D, now _that's_ pleasant to use.) Reading and writing characters and data structures is easy to do (and compatible with other systems). Windows are dead simple on a Mac; what they're like on a PC I don't know because I've got the low end student edition. > d) ability to store terms in EMS, on hard disks, etc. I've got the low end student edition, which doesn't include that. (On the other hand, my computational linguistics students haven't told me they needed it.) I do know that the "professional" version supports data storage on disc very nicely indeed; I've _heard_ of ALS programs with 10Mb of clauses. > e) price The low-end "student" version was something over A$100, I've forgotten the exact figure. Ask ALS for a price list (and a feature list). > These questions are apropos of shoehorning LFG systems for use by linguistics > students into the confines of PCs without blowing personal or departmental > budgets. One of _my_ reasons for picking ALS Prolog was so that my students could write code using DCGs and XGs and chart parsers and the like, and the code would run unchanged on their PCs (without hard disc), our PCs (with hard disc), Macintoshes ditto, the UNIX system where I actually develop this stuff (any of several Prolog systems). One thing I regard as important about using real Prolog is the ease with which you can write preprocessors (e.g. XG + feature structures -> kernel Prolog). I personally would be *very* interested in hearing what you and your linguistics students are doing with LFG. > Avery Andrews (ada612@csc.anu.oz.au) -- The problem about real life is that moving one's knight to QB3 may always be replied to with a lob across the net. --Alasdair Macintyre.