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