🚀 go-pugleaf

In article <1926@ubc-cs.UUCP>, voda@ubc-cs (Paul Voda) writes:
> This is a response to the claim by E. Lagache that he prefers a practical
> and dirty Prolog before a logically pure and "impractical" one.
> 
I think that it is a serious mistake for the BSI committee or anyone else
to try to "purify" Prolog, and although I tend to sit on the same sort of
fence as Lagache I think that this point of view can be defended from
both sides of the fence.

On the "let's have a practical language" side, the plain fact is that
you can learn to work around the limitations of any tool if only it will
stay put.  Prolog-as-we-know-it has defects, but it is an excellent tool
none the less.  I have no idea how to use BSI Prolog effectively.

On the "let's be serious about logic" side, surely it is clear that
_neither_ trying to write super-smart compilers _nor_ extending Prolog
is the right idea.  Voda himself has done neither of these things, but
has produced a new language.  If you don't have to support existing
programs, you have a _lot_ more freedom to design your language to make
optimisation more straightforward.

There are people working on partial execution, data flow analysis,
better compilers, and all sorts of exciting things, and that's great,
and should influence the design of Prolog's successor.  What is to be
avoided is the people who want a cleaner language forcing the present
inefficiency of partly baked ideas onto people who just want to get the
job done.

The thing which triggered the present topic was, I believe, my mention
of the BSI group's changing the definition of atom/1 rather than adding
a new is_atom/1.  Note that this taste for purity hasn't led them
	- to eliminate var/1
	- to replace cuts 
	- to replace assert/1 and retract/1 (it's now determinate, but there)
	- to introduce sound negation
	- to introduce a sound all-solutions predicate
or anything else of that sort.  That is no serious attempt to produce a
language closer to logic.