Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site decwrl.UUCP Path: utzoo!watmath!clyde!burl!ulysses!unc!mcnc!decvax!decwrl!dec-rhea!dec-logic!vantreeck From: vantreeck@logic.DEC Newsgroups: net.lang.prolog Subject: Re: Bugs, and more bugs... Message-ID: <2909@decwrl.UUCP> Date: Wed, 26-Jun-85 12:01:50 EDT Article-I.D.: decwrl.2909 Posted: Wed Jun 26 12:01:50 1985 Date-Received: Thu, 27-Jun-85 07:48:20 EDT Sender: daemon@decwrl.UUCP Organization: DEC Engineering Network Lines: 84 >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