Path: utzoo!utgpu!watserv1!watmath!att!att!emory!samsung!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.prolog
Subject: Re: Turbo Prolog 2.0 tip
Message-ID: <4145@goanna.cs.rmit.oz.au>
Date: 30 Oct 90 04:45:03 GMT
References: <4097@goanna.cs.rmit.oz.au> <1990Oct27.085854.9537@canterbury> <1990Oct30.093255.9575@canterbury.ac.nz>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 75

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.