🚀 go-pugleaf

In article <8803082357.AA01587@decwrl.dec.com>, vantreeck@curie.dec.com writes:
> RE: Chris Moss' comments on the proposed BSI standards for PROLOG syntax.
> 
> I read the reports also. I'd rather see user defined operators left out the
> standard entirely because it complicates the parsing current Edinburgh syntax
> such that it is difficult to write a parser in a low level language (which
> would provide significant space and time advantages).

Hmm.  The difficulty of writing a Prolog parser in a low-level language
(let's say "C", for argument's sake) is largely a matter of the skill of
the programmer.  The operator ambiguities in Prolog *do* cause problems
(though not nearly as many as people think!), but *not* user-defined
operators as such.  I've written a couple of Prolog parsers in C, and
the existence of user-defined operators as such doesn't complicate the
parser, no, not one little bit.  And I'll back mine against yours for 
speed.

> And I also don't like user defined operators because it makes it
> impossible to write a simple BNF to describe the syntax, i.e., makes
> makes the language much more difficult to understand for very little
> gain in language capability.

What do you want BNF for?  A DCG for Prolog is every bit as clear as BNF
and has no trouble with user-defined operators.  Let me show you two rules
from the grimoire:

5.8		term = prefix op, term | term, postfix op ;
Constraint	X		  f      f
Priority	N      N,R        R      L     N,L
Abstract func(F,[A])   F          A      A     F

5.9		term	       = term, infix op, term ;
Constraint	X		 f		 f
Priority	N		 L     L,N,R	 R
Abstract	func(F,[A,B])    A     F         B

There are also three rules (8, 9, 10 in the grimoire) to say which
things are prefix, postfix, and infix operators, but they just point to
tables, which have to exist anyway for built-in operators.  With the
exception of the rules for postfix operators, all of this is needed for
built-in operators like '<' and '-'. This is complicated?  If you don't
like the grimoire's NIH definition style, use an attribute grammar;
it comes to the same thing.

As DCGs, we'd have
	term(N, func(F,[A])) --> prefix_op(F, N, R), term(R, A).
	term(N, func(F,[A])) --> term(L, A), postfix_op(F, N, L).
	term(N, func(F,[A,B])) --> term(L, A), infix_op(F, N, L, R), term(R, A).

If you are prepared to object to the existence of built-in operators like
'<' and '-', then you are entitled to complain about the complexity of
these rules.  But if you want those operators, then you need two of these
rules to handle them, and user-defined operators do NOTHING to increase
their complexity.

> It seems like an lot of work is being done to make PROLOG 
> syntax work for a feature of very minor importance. 

By definition, "a feature of very minor importance" means "something
I don't use".  I think the same way.  For example, I would be quite happy
to see postfix operators removed entirely from the language; I've never
had any use for them at all.  But there are other people who use them.
So I'm wrong.

> It seems to me that type string is totally unnecessary.

Yes and no.  I whole-heartedly agree that Prolog as such has no need of
strings whatsoever.  There *is* a good reason for having strings in the
standard, though.  (There are grounds for doubting that it is the reason
that the BSI committee have in mind.  They appear to think that strings
are needed for text processing.  Someone should have told David Warren
before he wrote his editor in DEC-10 Prolog...)  The reason is this:
there are other programming languages in the world, and many Prolog systems
have to interface to them.  For example, a Prolog system embedded in Lisp
be given an atom and a string, and should be able to give them back.
There are enough Prolog+Lisp systems (Quintus have a good one, and of course
there's PopLog) to warrant standardising what strings look like, _if_ they
exist.  I agree that the standard should not _require_ their existence.

It is interesting to compare the speed of character list operations with
the speed of byte-vector operations.  In Xerox Quintus Prolog, for example,
text-processing operations which touch all the characters of a text object
are rather faster working on Prolog lists of characters than working on
Lisp strings.  For the most part, the desire to represent text as byte
vectors seems to result from either Basic envy or the use of slow Prologs.