🚀 go-pugleaf

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