🚀 go-pugleaf

In article <8803112331.AA09995@decwrl.dec.com>, vantreeck@curie.dec.com writes:
> Of course user defined operators can be useful for things like prototyping.
> [other stuff deleted]
> If user defined operators are such a good idea, how come other languages
> are not incorporating them into their standards?

To paraphrase his argument, "if it's so great, why doesn't ADA do it"?
Interestingly enough, ADA and C++ _do_ support overloaded operators,
which has at least as much potential for causing maintenance problems
as user-defined operators.

If I were designing Prolog, I wouldn't have user-defined operators in
the language either.  (It was Bill Clocksin who suggested this to me.)
So what?  Prolog ALREADY EXISTS!  It was designed years ago.

The fundamental question is "what is a standard FOR"?
As far as I am concerned, the purpose of a standard is not to advance
the state of the art, not to force the very latest word in straitjackets
onto people, not to pander to my ego by designing the glossiest language
on the block, but to protect the interests of USERS of the language, by
providing as clear as possible a description of the language so that
(a) someone who writes a program in the language can be confident about
    what it _should_ do
(b) someone who wants to run his program on another machine or with another
    vendor's product can be confident that if his program uses only
    standard constructions and if the vendor's claims to follow the
    standard are truthful his program will require minimal changes

To adapt an old joke:
    I am enamoured of the existing defects of Prolog,
    the BSI committee want to replace them by new ones.

I have two examples of what I think are good standards:
 1. The Pascal standard (particularly "A Model Implementation...").
 2. The draft ANSI C standard.

> You have a precedence parser for PROLOG with user defined operators that can
> run as fast and be as small as a one-pass recursive decent or LALR(1) parser
> on a PROLOG without user defined operators?

I repeat, user-defined operators as such do *NOTHING* to the cost of
parsing.  There are enough built-in operators in Prolog that it is
cleaner to look them up in a table than to wire them into the control
structure of your program (disgusting) or use a giant LALR table.
Of _course_ my code is as fast as a recursive-descent parser,
it _IS_ a recursive-descent parser (plus an operator-precedence level).

> Is this code public domain?
You must be joking.  But I gave half the secret away in a previous message.

> Look in the back of C, BASIC, Pascal, FORTRAN, PL/I, etc, manual. You can
> generally find a simple BNF and/or syntax diagram describing the language.

Now I **KNOW** he's joking!  The Pascal grammar is huge.  The C grammar is
not only far too large, it's far too confusing.  How many people knew that
	unsigned long x;
is legal, but that
	long unsigned x;
has always been supposed to be illegal (though some compilers accept it)?
Have you ever read the PL/I standard?  It is _most_ illuminating.  How do
you get a simple PL/I grammar?  You lie.  More generally, the typical C,
Pascal, Fortran &c grammar or syntax diagram over-generates grossly;
there are additional context conditions which simply aren't in the grammar.
For example, in an old PL/I manual I have, the rules for "DEFINED" run to
six pages, including two tables and a flow-chart.

> Why can't we have a simple syntax that the
> larger world can understand via traditional means of specifying syntax?

Because the traditional means LIE.

We're not talking about a back-of-the-manual grossly-over-generating
sketch of a language.  Prolog has one of those, and arguments and all it
is half a page.  We're talking about the COMPLETE, FINAL, AUTHORITATIVE
DEFINITION of a language in a STANDARD.  Again, I suggest that a fairer
comparison is not with the lies in the back of a PL/I manual, but with
the actual PL/I standard.  Take a look at Algol 68.  Just about the only
language I know of which was actually given a formal definition that a
mortal has any hope of reading is Turing.  I dislike the language, but
the definition is great.

> If there were no user defined operators allowed, then traditional means of
> specifying syntax would work just fine.

You mean operator precedence isn't traditional?

Van Treeck has missed the biggest difference between Prolog and Pascal.
No disgrace:  the BSI committee seem never to have seen it either.  (By
the way:  don't imagine that I think I'm criticising Chris Moss.  The
BSI committee has been obstinately determined on that kind of grammar
since its inception, despite having been warned in December 1984 that
the approach couldn't possibly work.  I believe Chris Moss's contribution
to have been the method of presentation, which is admirably lucid.)

The point is this:  a language like Pascal or Turing is defined by saying
what a PROGRAM looks like and what a PROGRAM means.  But there isn't any
such animal as a Prolog program.  Prolog is the same kind of language as
Lisp:  you don't see grammars for "Lisp programs"!  What you see in
"Common Lisp, the Language" is a definition of what the language primitives
are (including "read") and a definition of how data structures are
interpreted as code.

The basic point which the BSI grimoire completely misses is that I may
want to use read/1 for other things than Prolog clauses.  I may want to
read some kind of circuit description language where
	r: p -> q.
means that there is a resistor connecting node p to node q.  Why not?
A grammar for Prolog programs which rigidly defines p->q to mean identically
the same thing as (p->q;fail) -- and the grimoire is just such a grammar --
is going to render read/1 utterly useless for this task.

There is a second basic point which the BSI grimoire also misses.
Telling me that consulting a file containing ... p->q ... will give
me sys(ifthenelse,[p,q,true]) -- the interpretation of which is _NOT_
given in the grimoire -- doesn't tell me what I am to do if I want to
construct such a term at run-time.

Let me give you another example of why it is useless to try to give a
grammar of the Pascal/ADA/BSI variety for real Prolog.  term_expansion/2.
DEC-10 Prolog has a built-in predicate expand_term/2, which takes care of
grammar rules.  The basic loop is

	see(File),
	repeat,
	    read(Term),
	    expand_term(Term, Clause),
	    (   Clause == end_of_file, !
	    ;   process(Clause), fail
	    ),
	/* ! done above */
	seen.

C Prolog added a user-definable hook term_expansion/2 to expand_term/2,
so that you can plug in your own translation rules.  Quintus Prolog
retains this feature.  It is extraordinarily useful.  For example, I
have used this hook to make

	rev(L) = rev(L, []).

	rev([], L) = L.
	rev([H|T], L) = rev(T, [H|L]).

acceptable as Prolog source code.  These things are read as terms, and
term_expansion/2 turns them into rather different clauses.

The grimoire doesn't leave these terms undefined.  It states clearly
and unambiguously that they *MUST* be treated as equivalent to

	rev(L) = rev(L, []) :- true.

and so on.  This is not because the grimoire is badly done, but because
it is a grammar for Prolog *code*, not a grammar for Prolog *data*.

> But I suspect the real reason the BSI are putting strings in the standard is
> that they want to manipulate atoms like strings without having to expand them
> to lists, but they feel that it is too slow to assert/retract new atoms from
> symbol tables.

I suspect this too.  In fact I know for a fact that one outfit represented
on the committee has exactly this motive.  But from my perspective, the
things you happen to like and the things I happen to like aren't all that
important.  Having argued that the point of a Prolog standard is to
protect the interests of people who are already using Prolog by standardising
the language we already have, I find that strings are a de facto part of
Prolog.  There are a lot of Prolog systems in daily use which have a string
data type.  The fact that I may think Prolog programmers who _use_ strings
are, um, not as skilled as they suppose, isn't a good enough reason for me
to break their programs.  Nobody asked me what Prolog should be like.
Nobody asked the BSI Prolog group either.  If I went over to someone using
Arity Prolog and told him "I think strings are so disgusting that none of
your programs should be allowed to run", he'd tell me where to get off.
It's the same with user-defined operations:  I don't believe that Steve
Hardy ever asked anyone on the Prolog committee "please design a new
version of Prolog for me which will break my programs."  For better or
worse, user-defined operators are part of most Prologs, and strings are
part of too many Prologs, and the BSI has no more of a divine mandate to
rubbish anyone else's work than I have.