Shebs%UTAH-20@sri-unix.UUCP (05/29/84)
From: Stan Shebs <Shebs@UTAH-20> The exchanges between Dave Bowen and Richard O'Keefe about Prolog syntax are hard for me to understand. As a Lisper I only approve of syntax when certain constructs appear so frequently that it's time to define a readmacro. The nature of the readmacro definition process is such that it's very difficult to overload any readmacro character, so that almost no symbols ( the period being an exception) have more than one meaning. I should perhaps mention that the PSL dialect of Lisp has long had an Algolized frontend called Rlisp, and in fact most of the original PSL sources are still written in Rlisp. Despite all the syntax, Rlisp is much more difficult to read, and is now only used by people doing lots of computational and algebra work. The moral? Syntax is not such a Good Thing after all. The Prolog Standard should be a fully parenthesized Prolog, with real names for all of the builtin predicates. Those who can't tear themselves away from syntax, or who just love to have peculiar symbols floating about their code, can spend their time building elaborate parsers (but of course building a Prolog parser in Prolog is easy, right?). I defy anyone to define a data and program representation more general, elegant, and consistent than s-expressions... -- Stan Shebs
vantreeck@logic.DEC (07/08/85)
I'm glad to see all the responses. I was wondering if very many read this notes file. Text from: Ray Reeves, CCA-UNIWORKS,20 William St,Wellesley, Ma. 02181. (617)235-2600 emacs!ray@CCA-UNIX >Organization: CCA Uniworks, Wellesley, MA . . . >On the other hand, his endorsement of systems that modify >text behind your back seems capricious. What possible >merit is there in constraining the expressive power of the >ASCII set of characters? Modify what text? Did I say something I didn't mean. >His plea for a more pedantic style of syntax is misplaced. >Any Prolog can be made to support a special interface, what >the Lisp style does is represent a clause with minimum >syntax, and the fact that it can be entered that way is >much appreciated by those who don't care for typing. >Building spurious noise marks into the syntax has the >unfortunate consequence of preempting those marks from use >elsewhere. >The important point about Lisp syntax is that it is more >suitable for reflective programming. Not only does it >vitiate the need for "univ" but it enables a term to be >represented totally abstractly, whereas reference to a >structure needs some knowledge of it's form. For example, >"((X|Y)|Z)" in micro-Prolog matches any clause. >Meta-programming in Dec-10 style is a much more clumsy >business. Indeed, the S-expression of Lisp is a powerful syntax to express both functional and logic programming, e.g., the language TAO. Other languages, e.g., APL, have put a higher premium on expression "with a minimum of syntax" than on ease of reading. It's said that C code can be made very readable. Unfortunately, too many follow the path least resistance. I think that the DoD chose a Pascal-like syntax for Ada, because it tended to encourage self documenting code. Suppose a major computer/software company were going to market a language for which there is no standard. Should the company make it's implementation such that it targets those logicians and AI researchers that prefer the economy of expression? Or should it make its implementation be usable by logicians and AI researchers by remaining within the bounds of first order logic and also provide software engineering features that the more conventional software shops prefer? Some large corporations are staffing up with PhDs to lead the development of expert systems. But many of the programmers will be in house people from COBOL/FORTRAN backgrounds who will have to learn a new language. Having tried to introduce some people to Prolog, I've learned that most have enough difficulty understanding bactracking, cut, and unification. And the syntax was no great help in the learning process. The last thing these people need to hear about are S-expressions, lambda calculus, predicate calculus, horn clauses, etc.. Their need is very pragmatic: "This is what I want to do. How do I do it in Prolog?" >The idea of a "lambda" style syntax is also good, but I >suggest that lambda is a better word than "for_all", which >suggests universal quantification. Variables that do not >first appear in the head are not universally quantified. "for_all" is not a universal quantifier. It is an existential quantifier, i.e., one per clause. Want an alternative name? Lambda? Sounds like Greek to me. How about an existential quantifier that I can understand, like "exists". >It seems to me that soft cuts under a disjunction are very >important. There is a distinct need for them there, and >the semantics of soft cut in that context does not seem >strange if the disjunction is thought of as a separate >anonymous clause set which has been made local to share >variable scope and generally increase efficiency. That, >after all, is what it is. The practise of treating cuts >under a disjunction as soft seems quite satisfactory. Should cut be implemented in a way that allows one to write a faster program, or should cut behave in a consistent manner? I think it's a question of speed versus consistency. I vote for consistency (the hard cut). When I say cut, that means that I want to exit the procedure on backtracking to the cut - no exceptions.