Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!ames!sgi!decwrl!curie.dec.com!vantreeck From: vantreeck@curie.dec.com Newsgroups: comp.lang.prolog Subject: BSI standards Message-ID: <8803112331.AA09995@decwrl.dec.com> Date: 11 Mar 88 23:31:31 GMT Organization: Digital Equipment Corporation Lines: 113 >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.