🚀 go-pugleaf

>I disagree.  Even though user-defined operators do complicate
>prolog syntax, I have found them extremely useful when using
>prolog to prototype interpreters for new problem-specific
>languages.  We used Prolog to build the first version of the M.1
>expert system shell.  Because of user-definable operators, it
>was not necessary to to write an parser for M.1 per se.  This
>made development much simpler.  Recoding M.1 in C took more
>effort than the original development.  Much of the extra cost
>was incurred because of the need to write an explicit M.1 parser
>in the C version.
> 
>Steve Hardy, SHARDY@TEKNOWLEDGE.ARPA, (415) 424-0500

Of course user defined operators can be useful for things like prototyping.
They can also end up as code that needs to be maintained by programmers that
have to carefully reverse engineer the thinking behind the priorities and
associativities of user defined operators to understand exactly how the
program should behave. Often the maintainers may be people who don't
thoroughly understand operator precedence and associativity.

Careful use of a user defined operator can increase readability. But the
potential for abuse is large. Languages that are being actively used by
business and government are evolving into languages that strongly "encourage"
programmers to write easilly maintainable code. For example, it's tough to get
an Ada program to compile. But once it does compile, it tends to be more
maintainable than something typically written in K&R's C or BASIC. 

Some complain that this trend makes it more difficult to write quick
programs. But that's not the interest of people who increasingly have to bet
their business or their country on correct, maintainable, software. If PROLOG
is to be accepted by business and government, it had better emphasize good
software engineering methodolgy (at the expense of convenience). 

If user defined operators are such a good idea, how come other languages
are not incorporating them into their standards?

>Newsgroups: comp.lang.prolog
>Path: decwrl!sun!quintus!ok
>Subject: Re: BSI standards
>Posted: 10 Mar 88 05:47:53 GMT
>Organization: Quintus Computer Systems, Mountain View, CA

>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.

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? Is this code public domain?
I'd like to look at it.
 
>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. 
 
>This is complicated?  If you don't
>like the grimoire's NIH definition style, use an attribute grammar;
>it comes to the same thing.

Look in the back of C, BASIC, Pascal, FORTRAN, PL/I, etc, manual. You can
generally find a simple BNF and/or syntax diagram descibing the language. It
doesn't require special non-standard BNFs (ones with an extra lines describing
priority and associativity), nor does it require DCGs with explicit
definitions of priority and associativity, nor do they require attribute
grammars. Operator precedence and associativity in the above languages is
implicit in the BNF or diagram. Why can't we have a simple syntax that the
larger world can understand via traditional means of specifying syntax? Or
is this to be standard which is fathomable only by the initiated?

If there were no user defined operators allowed, then traditional means of
specifying syntax would work just fine. I doubt the mountain of programmers in
this world will come to Mohammud. 

RE: the need for strings in PROLOG.

I agree PROLOG must be able to communicate with other languages. But that is
what a calling standard is for. And conversion of an atom to/from a string
should be isolated to the call of the foreign language. There should be no
string type visible to the PROLOG programmer. There's no reason why
conversions can't be handled automatically by the PROLOG compiler via glue
routines. If strings are not visible to the programmer, then there's no need
for it in the standard. 

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. This is because most implementations never garbage collect the
symbol tables, they use hash tables which would have to be extended more
frequently, they don't use a reference count for each string in the symbol
table to know if it can be deleted, i.e., they are letting their
implementation details drive the standard. Speaking from experience, I can say
that it is easy to add string functions that operate on atoms and efficiently
assert/retract them from the symbol tables. I resent the idea of having to add
them to my PROLOG (if want to I conform to a standard) because others don't
wish to garbage collect their symbol tables!

My symbol table on my Mac PROLOG is an AVL tree (with a reference count). All
atoms are simply pointers the strings in the tree. Often, the newly created
atom becomes part of clause that is asserted. So, when backtracking happens, I
simply decrement the reference count. Yes, this slower than just moving the
pointer to top of heap back. But I doubt most _PROLOG_ programs spend their
time doing string functions, i.e., asserting/retracting from the symbol table
is infrequent. I think it's more important to have a simple, consistent
language than have the fastest possible language. 

George Van Treeck
Digital Equipment Corporation

These are my opinions and not necessarily those of my employer.