🚀 go-pugleaf

In article <653@fudd.dataco.UUCP> campbell@dataco.UUCP (Duncan Campbell) writes:

   Well, Ted, out here in the real world _REAL_ Prolog isn't much use
   to anyone.

indeed.  i would have gathered otherwise from the literature that
vendors send me about all the real applications that their customers
have written.  i would have gathered otherwise from the real
applications that i currently support.

   Indeed, if I were required to use a "pure" language, I simply
   would not bother with prolog at all: Scheme _IS_ a far superior
   language.

of course, scheme isn't a pure language.  at least not in the
customary sense of not allowing assignments.

   The fact remains that PDCProlog provides much of the functionality
   of "pure" Prolog and possesess the features like timers, static
   typing and execution speed (*10 faster than "pure" prolog) needed
   for real-time applications.

timers?  no problem to add to any of the prologs i use (quintus,
         sicstus).  in fact, i did it just last month.

static typing?  do you required required static typing that won't
         allow you to declare all the legal values in the language?
	 well, then you really do want to have turbo instead of the
	 real thing.  if, on the other hand, you want inferred typing,
	 or compile time type checking then you should check out peter
	 van roy's latest compiler or the mycroft and o'keefe type
	 checker. 

execution speed?  where do you get these numbers?  last i checked
	 (which was some time ago) als prolog ran on pc's and macs and
	 produced code which ran just about even with turbo prolog.
	 peter van roy's compiler produces code which runs even with
	 compiled and optimized c code.

	 i would have to admit that there is _some_ prolog that runs
	 at least 10* slower than turbo prolog.  in fact, i could
	 write you one.


ok... since turbo prolog is prolog, let's see somebody write the
following predicates:

1) a standard findall.

2) a variation on the standard dcg expansion which allows me to write in
a functional style and which translates all calls to :=/2 so that the
left hand side is unified with the functional result of the right hand
side.  this should integrate into the normal compilation process so
that you don't have to worry about preprocessing your files.

3) a weakening of the above where instead of adding to the standard
clause expansion, you just write a wrapper around predicate that
compiles files.  it should cause the files to be preprocessed, then
compiled and loaded.

4) a rewrite of the following predicate:

forall(G, P) :- \+ (G, \+ P).

that does not include an entire interpreter for prolog.

5) a simple program that takes as an argument a goal written in a
syntactic variation of prolog, and then executes it.


================================================================
as a preview of the problems you are likely to have with turbo prolog,

1) woops... you can't declare a type for a general term.  nor can you
   call a variable.

2) oh, golly, term expansion is built in and can't be changed.

3) darn, i have to write a new version of read which will read
standard terms and give me decorated terms.  then the translator
isn't too hard.  except that it can't dynamically check to determine
which predicates are defined.

4) darn, no passing goals as arguments

5) woops... can't declare the type for the argument, nor can i call
the result even if i did manage to translate it.  oh well, i can
always write a prolog interpreter to make this look like it works.