🚀 go-pugleaf

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.