vantreeck@logic.DEC (06/26/85)
>Date: Sun 16 Jun 85 16:34:38-PDT >From: Pereira@SRI-AI >Subject: Bugs, more bugs... >If anyone doubted the urgent need for a Prolog standard and >test suite, the increase of messages of the form ``The >Prolog system I got from Dr. Il Logical is behaving >strangely and my students are crying over their terminals'' >is a clear indication of the lack of any accepted means to >test the performance and reliability of Prolog systems. >-- Fernando Pereira A standard suite of tests would be nice. Maybe we can get the DoD to "validate" Prologs also? - Just joking! I think it would be particulaly nice if there were a standard suite of tests which could also be used for benchmarking. What does 20KLIPS mean if every one is using a different formula to compute the LIPS in a naive reverse? There are several people in Digital investigating various implementations of Prolog. They also think that current implementations of Prolog are severely lacking in features that help produce reliable and maintainable programs. But some experts think that there is so much good work being done on the theoretical issues of how to extend the language to make it more useful while remaining strictly first order logic that to put Prolog into concrete at this time would be not be productive. For example, M-Prolog has implemented modules. Modular programming is good thing. But was the modularity built on a theory or simply for the need for modularity. Recent work by Ken Bowen and Toby Weinberg provides a mechanism of adding modules within a first order logic framework. As far as I know, no current Prolog has implemented modules based on theoretical work that indicates that it is consistent with some system of logic. Should we freeze the syntax and sematics of modules on a current implementation, like M-Prolog, or wait for some promising theoretical work to be completed? I think modules should be implemented whether there's a theoretical framework to support it or not. But if it appears that a clean theoretical framework might be available, then it's worth waiting a few months or even a year for that work to finish before making a standard for modules. I don't see any reason, except political, why we can't come up with a standard syntax. I'm glad there's no standard syntax, because I think the syntaxs of current implementations suck! Variables should be predecared, as in the proposed MetaProlog at Syracuse U., And variables should not be case sensitive, e.g., for_all [x,y]: foo(x,y) if bar(x) and snafu(y). There is a minor kink in predeclaring variables in a clause that also asserts a clause containing variables. The kink is that a standard should exist on how to deal with it the interpretation. I think the parser should automatically uppercase (or lowercase) all strings before being converted to atoms, unless it was a quoted string of characters. We should move the syntax of the language from something cryptic (particularly bad are those Prologs with LISP-like syntax) to something that is more natural to the uninitiated. The ":-", ",", and ";" of DEC-10 and C-Prolog, should be replaced with "IF", "AND", and "OR". We need to standardize cut. In particular, should a cut on disjuction (or) be a soft cut or hard cut? I vote for the hard cut. I would rather see an exclusive or, "XOR", predicate than the else-like predicate, "->", of C-Prolog. All Prolog error messages should be in a file(s) seperate from the rest of the Prolog code. Prologs should index to the error message, via a standardized error number, instead of the messages being built into the bodys of clauses. DISCLAIMER: These are my opinions, and are not necessarily the opinions of my employer, Digital Equiment Corporation. George Van Treeck AI Technolog Group Digital Equip. Corp. (617) 568-6163
ray@emacs.uucp (Ray Reeves) (06/28/85)
I would like to follow up Van Treeck's comments avoiding, if I can, the patois of perversion. His point about having a theory of modularisation is a good one, but he may not be aware that micro-Prolog has been a modular system since it was first introduced in 1980. 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? 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. 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. 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. -- Ray Reeves, CCA-UNIWORKS,20 William St,Wellesley, Ma. 02181. (617)235-2600 emacs!ray@CCA-UNIX
PEREIRA@sri-iu.UUCP (PEREIRA) (06/30/85)
I am not about to enter in religious discussions over syntax, but it should be noted that micro-Prolog syntax *loses* information with respect to Edinburgh syntax, because it confuses lists with functor application. This means that Edinburgh Prolog programs cannot in general be converted to micro-Prolog syntax without major rewriting. Micro-Prolog syntax cannot thus be used as a standard or interchange format. Making metalevel programming easier is not a good excuse to confuse conceptually distinct datatypes, as well as making compilation more difficult. -- Fernando Pereira
shebs@bcsaic.UUCP (stan shebs) (07/02/85)
In article <2909@decwrl.UUCP> vantreeck@logic.DEC writes: >(particularly bad are those Prologs with LISP-like syntax) to something that is >more natural to the uninitiated. The ":-", ",", and ";" of DEC-10 and C-Prolog, >should be replaced with "IF", "AND", and "OR". I just don't understand this! Why should a language's syntax be mangled to facilitate its use by the "uninitiated"? Contrary to some claims, Prolog will never be used by upper management types - it's a *language*, not a mail system! If all Prologs lived up the standard set by some (and by some Lisps), surface syntax would not be an issue - everybody could mung it as desired. The *abstract syntax* is the important thing, as everybody in the Lisp world has known for years. The other comments are about semantics, and I agree that LP languages in general and Prolog in particular are in a very unsettled state these days. On the other hand, I prefer this to an uncritical acceptance of a language that will probably be obsolete in a few years (a la Fortran). stan shebs
ray@emacs.uucp (Ray Reeves) (07/03/85)
I must gently rebuke Fernando for using pejorative terms like "religous" and "confuse" when I make a valid point. Micro-Prolog uses one data type - lists - for aggregates, instead of distinguishing lists from structures. It is not confused about that, and if it leads to better meta-programming it *is* a good excuse for doing so. Of course, when translating Dec-10 syntax to lisp syntax it cannot maintain that distinction, but that is only important if it is required to translate back again. It so happens that micro-Prolog does now support Dec-10 syntax so it can't be such a big deal. The points that lisp syntax is unsuitable for a reference language and that it makes compilation more difficult seem perfectly valid, although we might observe that the Symbolics Prolog compiler has made a pretty good job of it. -- Ray Reeves, CCA-UNIWORKS,20 William St,Wellesley, Ma. 02181. (617)235-2600 emacs!ray@CCA-UNIX