RESTIVO@SU-SCORE.ARPA (07/08/85)
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SU-SCORE.ARPA>
PROLOG Digest Monday, 8 Jul 1985 Volume 3 : Issue 29
Today's Topics:
Query - Numerical Analysis,
Implementations - A Standard Syntax
----------------------------------------------------------------------
Date: Fri, 5 Jul 85 09:40 EST
From: D E Stevenson <DSteven%Clemson@csnet-relay>
Subject: Numerical analysis
Can anyone point me to serious attempts to do numerical
analysis programming in either logic or functional
programming environments. I know there have been a couple
of papers in Newton quadrature schemes.
Thank you,
-- Steve
------------------------------
Date: Wed, 3-Jul-85 10:01:38 PDT
From: Vantreeck%Logic.DEC@DECWRL.ARPA
Subject: A standard syntax for Prolog
F. Pereira pointed out that it is difficult to convert
between Edinburgh and Micro-Prolog. I think that problems
of conversion between implementations is not due to syntax.
The problem is due to differences in semantics which are
reflected by different syntaxs. Before we can begin
thinking about a standard syntax for Prolog, we need to
standardize the semantics. But implementers can't even agree
on what cut means.
-- George Van Treeck
------------------------------
Date: Wed, 3-Jul-85 06:07:25 PDT
From: (Ray Reeves) decvax!cca!emacs!Ray@UCB-Vax
Subject: Bugs, and more bugs...
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,
------------------------------
Date: Sun, 30-Jun-85 10:54:58 PDT
From: (PEREIRA) sri-iu!PEREIRA@Seismo.ARPA
Subject: Bugs, and more bugs...
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 meta-level programming easier is not a good excuse to
confuse conceptually distinct datatypes, as well as making
compilation more difficult.
-- Fernando Pereira
------------------------------
Date: Fri, 28-Jun-85 08:05:06 PDT
From: (Ray Reeves) decvax!cca!emacs!ray@UCB-Vax
Subject: Bugs, and more bugs...
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
------------------------------
Date: Tue, 25 Jun 85 17:12 EDT
From: Tim Finin <Tim%UPenn@csnet-relay>
Subject: Prolog Standards
If there are many implementations of Prolog which try
to adhere to a common standard, there will undoubtedly
be numerous small differences. One aid for coping with
this situation would be a Prolog "read time
conditionalization facility" similar to that found in
Common Lisp. In this note I'd like to ask people to
consider the inclusion of this idea as a standard Prolog
feature.
Common Lisp's #+ and #- readmacros
----------------------------------
In Common Lisp, there is a global variable *features*
which is bound to a list of symbols which describe various
aspects of the current Lisp. For example, its initial
value for the Lisp runnig on our Vax is:
(COMMON COMPILER DEBUGGER EDITOR VAX VMS)
which indicates that this is a COMMON lisp with the
COMPILER, DEBUGGER and EDITOR resident running on a
VAX under VMS. The user is allowed to add or
remove features as he likes.
In Lisp code one can use expressions like
#+(and VAX VMS (not FRANZ)) <s-expression>
The effect is that the Lisp reader will see <s-expression>
only if the features VAX and VMS are in the list and the
feature FRANZ is not. If the test is not satisfied, the
whole expression will be treated as whitespace.
Thus it is typical to see things like:
(defun system (S)
#+VMS (dcl-command S)
#+UNIX (shell-command S))
This has been extremely useful to the Lisp community,
allowing one to write code which is portable over a
number of similar implementations in the generic Common
Lisp family (e.g., Franz, PSL, Maclisp, DECLisp, Zetalisp,
etc.). The fact that this is done by the reader makes it
very powerful, and allows it to even cover differences at
the character stream level.
Can we have this in Prolog?
---------------------------
I believe that we need some thing like this in Prolog. I
am currently faced with a situation in which I would like
to maintain a single system that can run in both C-Prolog
and in Symbolics Prolog. The implementations two are
sufficiently close to imagine this. I think I can do it
if there were such a "read time conditionalization
facility" that is commonly supported by various Prolog
implementations. There are, of course, some problems due
the the nature of the Prolog reader, but I believe that
they can be dealt with.
I would like to get some feedback on this idea and perhaps
some concrete suggestions for its form.
-- Tim
------------------------------
Date: Friday, 28 Jun 1985 06:55:51-PDT
From: Vantreeck%Logic.DEC@decwrl
Subject: Bugs, more bugs...
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 syntax of current
implementations suck! Variables should be predecared, as in
the proposed Meta-Prolog 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 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 Equipment Corporation.
-- George Van Treeck
------------------------------
End of PROLOG Digest
********************