🚀 go-pugleaf

In article <636@imsvax.UUCP> ted@imsvax.UUCP (Ted Holden) writes:
>
>
>There's a paragraph in the September issue of Dobbs Journal which I can't
>get over:
>
>    "Perhaps the greatest shortcoming of Turbo Prolog as an implementation
>    of Prolog is the lack of what might be called "metalinguistic" functions
>    and operators.  Some of these supplied in Prolog are arg, functor, name,
>    op, clause, and call and the univ operator.  In general, these functions
>    allow the Prolog program to examine itself, to operate on code as data,
>    and to construct new clauses and goals undreampt of by the programmer."
>
>Now, I don't TRUST my own computer or any of IMS's computers enough to
>let them try to program themselves.... no telling what they might try
>to do.   Can anyone out there give me an example of a legitimate use
>for such a technique, preferably one which could not be achieved with
>more ordinary kinds of programming skills and languages?   Any opinions
>as to whether Kahn left these things out of Turbo Prolog because he
>thought they were dangerous or whether he's just being lazy?
>
>Ted Holden
>IMS

I once wrote a program that parsed english sentences. If the sentence
was a statement of fact like "John likes computers" it would
be parsed into 
	
	likes(john, computers).

A statement like "If john likes computers, then john uses computers" would
become:

	uses(john, computers) :- likes(john, computers).

The a question like "Does john use computers" would become:

	:- uses(john, computers)

The program would build these pices of code and then execute them. The base
code was very simple but a lot could be done once the information had been
fed into it.
-- 
					Random (Randy Buckland)
					Research Triangle Institute
					...!mcnc!rti-sel!rcb