Need Help....
M.B.Tajudin
Hi there,
I have a problem in Prolog Language for my M.Sc project.
I am using C-Prolog ver. 1.5+ in SUN.
The problem is how to write the IF...THEN...ELSE in Prolog ?
I have tried many ways such as :
1) NOT (X), OR (Y)
2) X < 1
statement
stamement...
X > 1
statement
statement...
In 1) NOT (X) is working but OR (Y) is not working
In 2) The first argument X < 1 is working but
when its come on the next argument
X > 1 is not working. I tried the other
way rounds also the same.
Any better idea ? Please help me.
Thanks in advance.
TJ.
part of the program :-
--------------------------------------------------------------------------
......
print('=> Fc/Pc + mMx/Mb + mMy/Mcy = '),print(BUCKLING),nl,
BUCKLING > 1,
print(' since > 1.0 ==> NOT O.K'),nl,
print(' Testing Pmodxx_try = '),print(Pmodxx_try),nl,
print(' STOP....test'),nl,
Pmodxx_try = Pmod_try,
Pmodxx_try is Pmod_try - 100,
print(' Testing Pmodxx = '),print(Pmodxx),nl,
print(' Testing Pmodxx_try = '),print(Pmodxx_try),nl,nl,
BUCKLING < 1,
print(' therefore O.K since < 1.0'),nl,nl,
print(' Section '),print(Size),
print(' X '),print(Mass),print(' kg is adequate.'),nl,
print(' ****************************************'),nl,main_menu.
........
---------------------------------------------------------------------------
prolog.help
Michael Covington
C-Prolog has it.
To express alternatives in Prolog, use multiple clauses. Simple
example:
classify(X) :- X > 0, write('Positive').
classify(0) :- write('Zero').
classify(X) :- X < 0, write('Negative').
You could make this fancier by adding cuts to the first two clauses,
so that if either of them succeeds the subsequent ones will not even
be tried.
But the key idea is that decisions (alternative execution paths)
in Prolog are expressed as multiple clauses.
--
< Michael A. Covington, Assc Rsch Scientist, Artificial Intelligence Programs >
< The University of Georgia, Athens, GA 30602-7415 USA mcov...@ai.uga.edu >
< Unless specifically indicated, I am not speaking for the University. > <><
For information about any U.Ga. graduate program, email gra...@uga.cc.uga.edu.
Sait Dogru
>Hi there,
>I have a problem in Prolog Language for my M.Sc project.
>I am using C-Prolog ver. 1.5+ in SUN.
>The problem is how to write the IF...THEN...ELSE in Prolog ?
>I have tried many ways such as :
>1) NOT (X), OR (Y)
>2) X < 1
> statement
> stamement...
> X > 1
> statement
> statement...
>In 1) NOT (X) is working but OR (Y) is not working
>In 2) The first argument X < 1 is working but
> when its come on the next argument
> X > 1 is not working. I tried the other
> way rounds also the same.
>Any better idea ? Please help me.
>Thanks in advance.
>TJ.
Hi,
Why not define your own if/3 predicate? Here it is:
if(Cond, Then, Else) :- (Cond, Then ; Else).
This is also bactrackable: if Cond is not a ground term,
first Then will execute, and then the Else part on bactracking.
If the Then and Else parts contain more than one predicate, you
need to put them in a pair of parantheses.
One note though. When the Cond fails and Else part is executed,
variables in Cond will get reported back (with no values, of
course). If you don't want that, just add the not Cond after the
or ( ";" ) operator.
Sait
do...@cs.umn.edu
J Lothian
|> There is an if-then-else structure (X -> Y ; Z) but I don't think
|> C-Prolog has it.
All together now... Oh yes it does! At least, cprolog 1.5+ certainly
does, and I'm sure it's been there for a while.
|> [...]
James
--
-------------------------------------------------------
James Lothian | "It's life, Jim,
ja...@uk.ac.ed.caad | but not as we know it"
-------------------------------------------------------
These opinions have nothing to do
with Edinburgh University.
Norbert E. Fuchs
("M.B.Tajudin") wrote:
>
> The problem is how to write the IF...THEN...ELSE in Prolog ?
>
Here is a general if-then-else
:- op(1170, fx, (if)).
:- op(1150, xfx, (then)).
:- op(1160, xfx, (else)).
if If_Condition then Then_Part else Else_Part :-
If_Condition,
!,
Then_Part.
if If_Condition then Then_Part else Else_Part :-
Else_Part.
You may have to adapt the priorities of the operators.
-----------------------------------------------------------
Norbert E. Fuchs Telephone +41-1-257 4313
Department of Computer Science Fax +41-1-363 0035
University of Zurich email fu...@ifi.unizh.ch
CH-8057 Zurich, Switzerland
-----------------------------------------------------------
Richard A. O'Keefe
>>I have a problem in Prolog Language for my M.Sc project.
>>I am using C-Prolog ver. 1.5+ in SUN.
>>The problem is how to write the IF...THEN...ELSE in Prolog ?
Why haven't you read the manual? It's part of the definition of an
Edinburgh-compatible Prolog that If->Then;Else is *already* available
as a built in control structure.
The form is
( Test1 ->
Then1
; Test2 ->
Then2
...
;
Else
).
For example,
max(X, Y, Max) :-
( X > Y ->
Max = X
;
Max = Y
).
It is there in the manual.
do...@myria.cs.umn.edu (Sait Dogru) writes:
> Why not define your own if/3 predicate? Here it is:
> if(Cond, Then, Else) :- (Cond, Then ; Else).
>
Why not? Because that isn't an if-then-else. It will perfectly
happily execute the Else *EVEN IF THE Cond IS TRUE*.
Please, people, Read The Fine Manuals and Try Before You Post.
--
Richard A. O'Keefe; o...@goanna.cs.rmit.oz.au; RMIT, Melbourne, Australia.
"C is quirky, flawed, and an enormous success." -- Dennis M. Ritchie.
Richard A. O'Keefe
>All together now... Oh yes it (C Prolog) does (have if->then;else)!
>At least, cprolog 1.5+ certainly does, and I'm sure it's been there for
>a while.
It has been there since 1.0. In fact, C Prolog got it from DEC-10 Prolog.
We're talking about a construct which has been in the Prolog language for
roughly 15 years (longer than floating-point numbers).
Michael Covington
>I recently presented some Prolog source (an attempt to formalise some
>course regulations) to colleagues, and was told off by one of them for
>using a non-standard '->' operator which was "not any part of Prolog
>as [he] was taught it". Sure enough, it isn't in Clocksin & Mellish
>2nd Ed. I had to bluff that it was a new feature which has become
>more-or-less standard (I recall some debate about its precise semantics).
>My colleague is not a Prolog user, but was under the impression that
>he had learnt the essentials of the language.
Conspicuously, Arity Prolog still lacks '->', which is the main reason
I don't use it in my books. (There's rather a lot of Arity Prolog around
our lab and our graduates' employers.) They do have ifthenelse(G1,G2,G3),
which is semantically equivalents but lacks the syntactic appeal.
Paul Singleton
>>In <2q8o7h$7...@rockall.cc.strath.ac.uk> cma...@ccsun.strath.ac.uk ("M.B.Tajudin") writes:
>...
>>>The problem is how to write the IF...THEN...ELSE in Prolog ?
> Why haven't you read the manual? It's part of the definition of an
> Edinburgh-compatible Prolog that If->Then;Else is *already* available
> as a built in control structure.
>...
I recently presented some Prolog source (an attempt to formalise some
course regulations) to colleagues, and was told off by one of them for
using a non-standard '->' operator which was "not any part of Prolog
as [he] was taught it". Sure enough, it isn't in Clocksin & Mellish
2nd Ed. I had to bluff that it was a new feature which has become
more-or-less standard (I recall some debate about its precise semantics).
My colleague is not a Prolog user, but was under the impression that
he had learnt the essentials of the language.
Does anyone want to buy my copy of Clocksin & Mellish 2nd Ed. ? :-)
Richard - to what "definition" of Edinburgh-compatible Prolog do you
refer (not the ISO standard, I guess :-)
----
__ __ Paul Singleton (Dr) email: pa...@cs.keele.ac.uk
|__) (__ Computer Science Dept. tel: +44 (0)782 583477
| . __). Keele University, Newcastle, fax: +44 (0)782 713082
Staffs ST5 5BG, ENGLAND road: M6 J15 follow signs
Richard A. O'Keefe
>There is an if-then-else structure (X -> Y ; Z) but I don't think
>C-Prolog has it.
I am sick and TIRED of this.
*YES C PROLOG ***HAS*** GOT IF->THEN;ELSE*
It's in the <swearword> manual! It has been in C Prolog (and in C Prolog's
manual) since day 1. I keep on saying that; are my postings not getting out?
>But the key idea is that decisions (alternative execution paths)
>in Prolog are expressed as multiple clauses.
It's a style point: sometimes a nice local if->then;else is clearer than
a nasty not-as-local-as-it-should-be cut.
Look, in the future, would people *PLEASE* at least take the trouble to
*read* the C-Prolog manual before they post saying it hasn't got something?
I mean, we're not talking about a lot of paper, here. Anyone who has a
legal copy of C Prolog has full source code, too, and there isn't a lot to
read in that either.
Jocelyn Paine
pa...@cs.keele.ac.uk (Paul Singleton) writes:
> From article <2qcbn2$b...@goanna.cs.rmit.oz.au>,
> by o...@goanna.cs.rmit.oz.au (Richard A. O'Keefe):
> IF...THEN...ELSE in Prolog]
>
>> Why haven't you read the manual? It's part of the definition of an
>> Edinburgh-compatible Prolog that If->Then;Else is *already* available
>> as a built in control structure.
>
> I recently presented some Prolog source (an attempt to formalise some
> course regulations) to colleagues, and was told off by one of them for
> using a non-standard '->' operator which was "not any part of Prolog
> as [he] was taught it". Sure enough, it isn't in Clocksin & Mellish
> 2nd Ed. I had to bluff that it was a new feature which has become
> more-or-less standard (I recall some debate about its precise semantics).
> My colleague is not a Prolog user, but was under the impression that
> he had learnt the essentials of the language.
non-standard (if one can define it for oneself, that surely doesn't
matter), but because those Prologs which do implement it as a built-in
don't do so efficiently. I was told that in general, conditionals built
from multiple clauses for a predicate are easier to optimise than those
built using a single clause which contains -> . I have no examples for
or against this though - any implementors care to comment?
Incidentally, what's the state of Prolog standardisation? Has the ISO
standard been completed yet?
Jocelyn Paine
Richard A. O'Keefe
>Here is a general if-then-else
If you are going to reinvent the wheel, you might at least
use the well-established names for the parts.
EVERY "Edinburgh-compatible" Prolog ALREADY has if->then;else.
If something claims to be Edinburgh-compatible, but doesn't have
if->then;else, demand your money back. In the mean time:
?- op(1150, xfx, (->)).
?- op(1100, xfy, (;)). % You are in BIG trouble if you lack this!
(If -> Then ; Else) :- call(If), !, call(Then).
(If -> Then ; Else) :- call(Else).
(If -> Then) :- call(If), !, call(Then).
These are the Edinburgh-standard operators with their required priorities.
One problem: in the real thing, you are allowed to have plain cuts in the
Then and/or Else parts, and if->then;else is transparent to them (lets
them affect the real parent).
Michael Covington
>mcov...@aisun3.ai.uga.edu (Michael Covington) writes:
>>There is an if-then-else structure (X -> Y ; Z) but I don't think
>>C-Prolog has it.
>
>I am sick and TIRED of this.
> *YES C PROLOG ***HAS*** GOT IF->THEN;ELSE*
>It's in the <swearword> manual!
I said "think". I don't have a C-Prolog manual. I was looking at early
editions of Clocksin & Mellish, which I thought were close to C-Prolog.
I stand corrected.
ozan s. yigit
| >C-Prolog has it.
|
| I am sick and TIRED of this.
| *YES C PROLOG ***HAS*** GOT IF->THEN;ELSE*
|
i suppose the maintainer of the FAQ will take note of the number of
times this topic came about, and will add this [along with richard's
code for if->then;else] to the FAQ. a list of prologs that do *not* have
this construct would probably be informative.
oz
---
a technology is indistinguishable from | electric: o...@sis.yorku.ca
its implementation. -- Marshall Rose | or [416] 736 2100 x 33976
Peter Ludemann
>Well, I have also been told off for using -> . Not because it's
>non-standard (if one can define it for oneself, that surely doesn't
>matter), but because those Prologs which do implement it as a built-in
>don't do so efficiently. I was told that in general, conditionals built
>from multiple clauses for a predicate are easier to optimise than those
>built using a single clause which contains -> . I have no examples for
>or against this though - any implementors care to comment?
I'm pretty sure that most Prolog compilers do a good job of handling
if-then-else---there are various forms of "shallow backtracking" that
can be implemented more efficiently than the create choicepoint and
cut style. For example:
count_down(N) :-
( N =:= 0
-> true
; do_something(N),
N2 is N - 1,
count_down(N2)
).
can easily be optimized to something similar to a C "for"-loop. I'm
pretty sure that Quintus, Sicstus, Aquarius, IBM, ECLiPSe, etc.
optimize such uses of if-then-else (and the arithmetic, that matter).
On the other hand, this form:
foo(X) :-
( X = one
-> bar(1)
; X = two
-> bar(2)
; bar(3)
).
would probably be better written (and better optimized by):
foo(one) :- !, bar(1).
foo(two) :- !, bar(2).
foo(_) :- bar.
because first-argument indexing can be used here.
As to if-then-else being non-standard ... I've yet to use a Prolog
that doesn't have some form of if-then-else, but I've only used about
a dozen different Prologs. :-)
--
Peter Ludemann Senior Computer Scientist
Institute for Medical Informatics InterNet: lude...@imi.kdsi.com
124 University Ave., Suite 350 Phone: +1-415-325-5178
Palo Alto, California 94301 FAX: +1-415-325-5177
Jamie Andrews
[re. if->then;else]
>i suppose the maintainer of the FAQ will take note of the number of
>times this topic came about, and will add this [along with richard's
>code for if->then;else] to the FAQ. a list of prologs that do *not* have
>this construct would probably be informative.
Sure. Frankly, I haven't been following this go-round
because I always read the manual for whatever Prolog I'm using
to find out if it has whatever constructs I need. But the
subject does come up a lot. So if Richard or anyone else wants
to summarize the points that everyone brings up all the time,
I'd be happy to put that summary in the FAQ.
--Jamie.
ja...@cs.sfu.ca
"Nkosi Sikelele iAfrika"
Chris Moss
In article <1994May16.095705.22829@oxvaxd>, po...@vax.oxford.ac.uk (Jocelyn Paine) writes:
> Well, I have also been told off for using -> . Not because it's
> non-standard (if one can define it for oneself, that surely doesn't
> matter), but because those Prologs which do implement it as a built-in
> don't do so efficiently. I was told that in general, conditionals built
Yes if->then;else IS in the standard, paragraphs 7.8.7 and 7.8.8.
The better Prolog compilers do compile out the tests in -> ; but simpler ones
interpret them, which is inefficient. When to use it is a subtle matter of style.
If you end up using lots of = then it's probably better NOT to use it.
> Incidentally, what's the state of Prolog standardisation? Has the ISO
> standard been completed yet?
Part 1 was registered as a Committee Draft (CD) in October 1992, went
through the first ISO ballot of SC22 which closed July 1993 (12
countries for, 3 against and 6 abstaining or not voting) and after some
cleanup was published as a Draft International Standard (DIS) in March 1994.
(ISO/IEC DIS 13211) This has still to be voted on to take it to a full standard.
Part 2, which defines modules, is still being argued about. As far as I can see
it's still a mess. (I don't go to the meetings, I only get the minutes.)
Chris Moss
Paul Singleton
| ?- are my postings not getting out.
no
Paul Holmes-Higgin
>From: cd...@doc.ic.ac.uk (Chris Moss)
>Subject: Re: Need Help....
>Date: 19 May 1994 13:38:34 GMT
>Part 2, which defines modules, is still being argued about. As far as I can see
>it's still a mess. (I don't go to the meetings, I only get the minutes.)
There was a 2 day meeting before PAP in London on Part 2. This resulted in
quite a shift in the draft proposal. It is likely that the proposal
will support modules that look quite similar to the Quintus style, but with
some syntactic and minor sematic differences. It is likely that there will
only be one operator (:) that combines the calling context and module
visibility operators specified in the last draft. Also the treatment of
metapredicates is likely to follow the Quintus style of a goal specification
with the arguments which need module expansion marked.
The plan is to have a new draft by early September.
Paul.
============================================================
Paul Holmes-Higgin E-Mail: p.holme...@surrey.ac.uk
Artificial Intelligence Group
Dept. of Mathematical and Computing Sciences
University of Surrey Tel: (0483) 259633
GUILDFORD GU2 5XH Int: +44 483 259633
England Fax: +44 483 300803
Michael Brady
> [...]
> Well, I have also been told off for using -> . Not because it's
> non-standard (if one can define it for oneself, that surely doesn't
> matter), but because those Prologs which do implement it as a built-in
> don't do so efficiently. I was told that in general, conditionals built
> from multiple clauses for a predicate are easier to optimise than those
> built using a single clause which contains -> . I have no examples for
> or against this though - any implementors care to comment?
>
> [...]
Well, I didn't use -> much, because (a) I couldn't understand it (!) and
(b) it looked messy.
It still looks messy, although I confess I use it quite a bit now.
Anyhow, Open Prolog is an interpreter and it has separate
tokens/instructions for the various parts of ->, so it makes very little
'efficiency' difference whether you use it or the alternatives.
---------------------
Mike Brady
Computer Science Department, Trinity College Dublin, Ireland
Richard A. O'Keefe
>Richard - to what "definition" of Edinburgh-compatible Prolog do you
>refer (not the ISO standard, I guess :-)
There were several Prolog systems developed at Edinburgh:
DEC-10 Prolog, EMAS Prolog, PDP-11 Prolog, C Prolog (and then came NIP
followed by others). The *only* one of those which did not have
if->then;else built in was PDP-11 Prolog. Chris Mellish left a fair
few things out of PDP-11 Prolog, such as negative numbers (yep, the
numbers in PDP-11 Prolog were 0..2**14-1) and curly brace notation.
PDP-11 Prolog ran eventually on little RT-11 boxes with 64k address
space total, including I/O devices (4k?) and monitor (another 4k?).
Clocksin & Mellish's book never at any time pretended to be complete;
it is neither a description of a complete language nor a complete
description of a sublangage. (What does ?-functor(_,_,_) do? C&M
does not say.)
If someone wants to deny if-then-else "Edinburgh-hood" on the basis that
it is not in C&M, they had better deny themselves floating point numbers,
negative integers, setof/3, and a whole bunch of stuff.
Roughly speaking, "Edinburgh compatible" is operationally defined as
"can run the DEC-10 Prolog library with only trivial edits other than
operating-system related ones". (PDP-11 Prolog couldn't.)
For a detailed definition, see my formal definition of Prolog
(Auckland 1985) and my detailed description of the built-in predicates
(Edinburgh 1984). Both were submitted to the BSI, which then went off
on a spree of inventing their own language.
Jocelyn Paine
p.holme...@surrey.ac.uk (Paul Holmes-Higgin) writes:
> In article <2rfq4q$h...@frigate.doc.ic.ac.uk>,
> cd...@doc.ic.ac.uk (Chris Moss) writes:
>>From: cd...@doc.ic.ac.uk (Chris Moss)
>>Subject: Re: Need Help....
>>Date: 19 May 1994 13:38:34 GMT
>
>>Part 2, which defines modules, is still being argued about. As far as
>>I can see it's still a mess. (I don't go to the meetings, I only get
>>the minutes.)
>
> There was a 2 day meeting before PAP in London on Part 2. This
> resulted in quite a shift in the draft proposal. It is likely that the
> proposal will support modules that look quite similar to the Quintus
> likely that there will only be one operator (:) that combines the
> calling context and module visibility operators specified in the last
> draft. Also the treatment of metapredicates is likely to follow the
> Quintus style of a goal specification with the arguments which need
> module expansion marked.
>
> The plan is to have a new draft by early September.
>
> Artificial Intelligence Group
> Dept. of Mathematical and Computing Sciences
> University of Surrey Tel: (0483) 259633
>
For goodness' sake. I think I first heard about the standard in
mid-1992, and it's clearly not ready yet.
This really is ludicrous. What the hell is the reason for the delay?
If it takes _two years_ to specify the semantics of a language which
has been in existence for the past 20, then isn't this a sign that
it's so messy that it should be scrapped immediately? And Paul's
comment does nothing to suggest otherwise. If it takes what - one year
- to retrofit a modularisation scheme to Prolog, then the language is
so complex that we can't hope reliably to understand programs written
in it. So what's the point of trying to promote it as a language for
software engineering or prototyping? People will look back on the
standardisation effort and say "it took the standardisation team over
four years to comprehend the language well enough to define the
semantics and add a module system. What hope in understanding it have
I?"
"Prolog is flawed and quirky. Unlike C, it will never be an enormous
success"
Jocelyn Paine
Lars-Henrik Eriksson
Only a draft? And not until mid-September? That's 120 days from now.
For goodness' sake. I think I first heard about the standard in
mid-1992, and it's clearly not ready yet.
This really is ludicrous. What the hell is the reason for the delay?
If it takes _two years_ to specify the semantics of a language which
has been in existence for the past 20, then isn't this a sign that
it's so messy that it should be scrapped immediately?
Judging from discussions here and in other places (do I recall a
debate between Chris Moss and Richard O'Keefe at the 1988 ICLP?), the
problem is not with the language itself but with the standardisation
procedure.
--
Lars-Henrik Eriksson Internet: l...@sics.se
Swedish Institute of Computer Science Phone (intn'l): +46 8 752 15 09
Box 1263 Telefon (nat'l): 08 - 752 15 09
S-164 28 KISTA, SWEDEN Fax: +46 8 751 72 30
Bill Hogan
: In article <p.holmes-higg...@surrey.ac.uk>,
: Jocelyn Paine
Why not make CTT the basis of a standard -- a standard that looks to the
future instead of one that codifies the past?
BH
--
Bill Hogan
{bho...@crl.com}
Richard A. O'Keefe
>I said "think". I don't have a C-Prolog manual.
I don't want to flame one of the most useful contributors to
comp.lang.prolog, but it _is_ part of net etiquette: if you don't
_know_, don't _post_. For example, Fernando Pereira (who is the
author of C Prolog) reads comp.lang.prolog. With him around (and
other people who have or worked on C Prolog) there is no need for
anyone to post what they _think_.
>I was looking at early
>editions of Clocksin & Mellish, which I thought were close to C-Prolog.
>I stand corrected.
But nowhere does Clocksin & Mellish in any edition claim to be a
*complete* description of *any* version of Prolog. What C & M 1 is
close to is ***PDP-11*** Prolog. More precisely, they confined themselves
to what DEC-10 Prolog, EMAS Prolog, and PDP-11 Prolog had in common, and
didn't go into detail about all of that.
Jacques Noye
|> On the other hand, this form:
|>
|> foo(X) :-
|> ( X = one
|> -> bar(1)
|> ; X = two
|> -> bar(2)
|> ; bar(3)
|> ).
|>
|> would probably be better written (and better optimized by):
|>
|> foo(one) :- !, bar(1).
|> foo(two) :- !, bar(2).
|>
|> because first-argument indexing can be used here.
Actually, a good compiler should be able to produce similar, if not identical,
code (with proper indexing) for both forms. As far as I can tell, Aquarius
does it.
-- Jacques NOYE
IRISA email: Jacque...@irisa.fr
Campus Universitaire de Beaulieu tel: +33 99 84 73 44
F-35042 Rennes Cedex fax: +33 99 84 71 71
France telex: UNIRISA 950 473F
Chris Moss
In article <1994May21.034447.23063@oxvaxd>, po...@vax.oxford.ac.uk (Jocelyn Paine) writes:
> Only a draft? And not until mid-September? That's 120 days from now.
> For goodness' sake. I think I first heard about the standard in
> mid-1992, and it's clearly not ready yet.
Hey Jocelyn, you're a new boy! I first went to a standardisation meeting in 1984,
or was it 1983?
>
> This really is ludicrous. What the hell is the reason for the delay?
> If it takes _two years_ to specify the semantics of a language which
> has been in existence for the past 20, then isn't this a sign that
> it's so messy that it should be scrapped immediately?
Lars-Henrik has already indicated some of the reasons. But a large part is the
standardisation process itself. For an ISO standard which has perhaps 6-10
countries attending it's only possible to have two meetings per year, given the
cost of travel. Then there are several levels of committees through which it has
to pass (WG17, SC22 etc.) The process is arcane but impossible to bypass.
As to the problems of specifying - it's brought out some of the difficulties of
using Prolog as a specification language. For example, unification without an
occurs-check fails in certain situations. One doesn't necessarily want to say how
it fails, but the algorithms which different implementors use produce different
results. It did take some time to resolve this problem and I'm glad to say the
result seems acceptable to most people.
Prolog is unusual as a programming language as there were at least three early
variations with very different syntax that could claim to be REAL Prolog: the
Marseille interpreter, the Waterloo interpreter and the Edinburgh compiler. What
compounds the difficulties is that Colmerauer (the undisputed author of the
language) then produced entirely different syntaxes for Prolog-II and III. Is it
surprising that France was one of the countries that voted against the DIS
(though not for this exact reason)?
Of course most of the time was spent arguing about which built-in predicates
should be included and what was their exact behaviour. This is thankless stuff
and those who persisted with the task are worthy of our admiration.
The trouble with modules is that everyone wants them but they're really a hack in
Prolog: there's no real rationale for them. I personally think we should forget
modules and try and work with objects instead, but I doubt if that would lead to
an early consensus. However it is depressing that the discussion in April sounded
very much like one we had in 1984.
Chris Moss
ozan s. yigit
...
For a detailed definition, see my formal definition of Prolog
(Auckland 1985) and my detailed description of the built-in predicates
(Edinburgh 1984).
are these papers available via ftp someplace?
Richard A. O'Keefe
>Only a draft? And not until mid-September? That's 120 days from now.
>For goodness' sake. I think I first heard about the standard in
>mid-1992, and it's clearly not ready yet.
The BSI committee actually started in 1984.
>This really is ludicrous. What the hell is the reason for the delay?
>If it takes _two years_ to specify the semantics of a language which
>has been in existence for the past 20, then isn't this a sign that
>it's so messy that it should be scrapped immediately?
After a standing start at the beginning of 1984, at the end of February
1985 I had
- a complete formal specification of Prolog with cuts, data base changes,
and I/O
- a large document explaining all the built-in operations
- public domain implementations of the read family, the write family,
the setof family, and a top level
My estimate is that it would have taken one year to tidy these things up
and produce a draft standard for the language as it then stood.
The problem has nothing to do with the complexity or otherwise of the
base "Edinburgh Prolog" language. The problem was that right from the
beginning the BSI committee never had the least intention of standardising
the existing language. Their aim was, and for a long time remained, to
design a _new_ language. (To this day, the syntax in the standard is _not_
compatible with most of my existing code.) Once you start deciding to
design a new language, you get fights about whose preferences will win,
and I have been told that every time a new country joined the ISO Prolog
committee all the old fights got fought all over again.
One major change to Prolog that _was_ needed was error handling.
I sent a proposal to the BSI committee in late '84 or early '85, but
it sank without trace until AFNOR suggested the same thing (but with
different names). The addition required adding about 10 lines to my
formal specification. I wrote a paper about that, but it was suppressed
by a certain company.
>And Paul's comment does nothing to suggest otherwise. If it takes what
>- one year - to retrofit a modularisation scheme to Prolog, then the
>language is so complex that we can't hope reliably to understand
>programs written in it.
It has been a lot longer than one year. The modules group was meeting
back in 1986. (PS/178 "Draft minutes, Modules group meeting, Nov 1986".)
Once again, the problem is not the retrofitting of any particular scheme.
_That_ is easy. The problem is designing a module system that enough
people on the committee will like.
>So what's the point of trying to promote it as a language for
>software engineering or prototyping? People will look back on the
>standardisation effort and say "it took the standardisation team over
>four years to comprehend the language well enough to define the
>semantics and add a module system. What hope in understanding it have >I?"
The language was comprehended very well indeed back in 1984.
See
"A Formal Definition of Prolog"
R. A. O'Keefe
Auckland Computer Science Report No. 36
January 1985
ISSN 0111-0942
available from the University of Auckland, Private Bag, Auckland, New Zealand.
There were other formal semantics produced before mine. If I recall
correctly, the original IF/Prolog engine was based on a formal semantics
that Preben Folkjaer had written. I think Mycroft and Jones did one that
handled cuts (I've got a copy somewhere).
The key point is that it did *NOT* take the standardisation team any time
at all to comprehend the language; they have spent their time arguing
about CHANGES to the language.
To give you one rather characteristic example:
DEC-10 Prolog had a predicate integer(X) which succeeded when
X was already an integer, and failed for anything else,
*including variables*.
Clearly that isn't as logical as one might hope for, so NU Prolog
has _two_ type test predicates:
integer(X) -- exactly like DEC-10 Prolog
isInt(X) -- delays until nonvar(X)
The spelling of isInt/1 is regrettable, but the idea is exactly right.
What did the committee do? They could have left integer/1 out of
the standard entirely, defining a new type test is_integer(X) which
had logical semantics (delay until nonvar(X) if you can, report an
error if var(X) if you can't delay). If they had done that, we
would have been able to put
integer(X) :- nonvar(X), is_integer(X).
in a compatibility library. Instead, they CHANGED the meaning of
integer/1! (And the other type tests.)
The result was that after prolonged dispute, they eventually had to
change it back. A complete waste of time, and _none_ of it caused by
failure to comprehend the existing language.
I am not making this stuff up. I explicitly suggested to the committee
that they adopt the same guiding principle as the ANSI C committee: the
language already exists and it's our job to standardise it, not to
break other people's working code. This principle was not merely not
adopted, it was explicitly rejected, or so Roger Scowen told me.
Fernando Pereira
> The trouble with modules is that everyone wants them but they're really a hack in
> Prolog: there's no real rationale for them. I personally think we should forget
> modules and try and work with objects instead, but I doubt if that would lead to
> an early consensus. However it is depressing that the discussion in April sounded
> very much like one we had in 1984.
has a perfectly good rationale. Lincoln and Sanella's adaptation of
SML's module system adds a treatment of parameterized modules that
has also a good rationale. In general, parameterized modules of that
kind fit well with naming mechanisms in logic and mathematics (cf. the
AXIOM algebraic manipulation system, nee ScratchPad). Objects, on the
other hand, what are they? Ways of organizing data (abstract
datatypes)? Ways of organizing program text? Both? Typical OO
languages make a hash of parameterization, or force the programmer to
fake parameterization with inheritance and virtual classes, hardly a
transparent technique. You know, even the cover of "Byte" is now
asking whether OO programming has failed...
--
Fernando Pereira
2D-447, AT&T Bell Laboratories
600 Mountain Ave, PO Box 636
Murray Hill, NJ 07974-0636
per...@research.att.com
Chris Moss
In article <PEREIRA.94...@alta.research.att.com>, per...@alta.research.att.com (Fernando Pereira) writes:
> I think that the Mycroft & O'Keefe module proposal, just to name one,
> has a perfectly good rationale. Lincoln and Sanella's adaptation of
> SML's module system adds a treatment of parameterized modules that
> has also a good rationale.
These particular proposals I don't remember so let me ask whether they cope
adequately with the problems which have caused the standardisation group to
thrash around so long: namely the dynamic aspects of Prolog:
to what module does a call to a constructed term refer?
how does a metapredicate defined within a module operate?
No there ARE workable implementations that cope. But do they have a rationale?
That I haven't seen. I don't think that parameterised modules are a substitute
for these.
>. Objects, on the
> other hand, what are they? Ways of organizing data (abstract
> datatypes)? Ways of organizing program text? Both?
Precisely the reasons I haven't seriously tried to introduce them into the
standardisation process, Fernando! I have my own answers to the questions
(see my book: Prolog++ the power of object-oriented and logic programming,
published next month by Addison-Wesley!) but they need some consensus and that I
DON'T see at the moment.
Chris
Richard A. O'Keefe
In article <1994May16.095705.22829@oxvaxd> po...@vax.oxford.ac.uk
(Jocelyn Paine) writes:
>Well, I have also been told off for using -> . Not because it's
>non-standard (if one can define it for oneself, that surely doesn't
>matter), but because those Prologs which do implement it as a built-in
>don't do so efficiently. I was told that in general, conditionals built
>from multiple clauses for a predicate are easier to optimise than those
>built using a single clause which contains -> . I have no examples for
>or against this though - any implementors care to comment?
In Quintus Prolog for one, this is the complete *reverse* of the truth.
The reason for that is simple: Quintus Prolog's compiler used to work
on one clause at a time, so that it _could_ optimise a conditional made
from if->then;else because it could see the whole thing at one time,
but it couldn't optimise a conditional made from several clauses because
it never saw two clauses together. (It still did first-argument indexing,
but that, for obvious reasons, did not require looking at entire clauses.)
[I use the past tense here because I do not know what improvements may have
been made to Quintus Prolog since I left Quintus.]
There are two very good reasons for compiling one clause at a time.
The first is that clauses *arrive* one at a time, and you may need to
execute a predicate before you _know_ that you have seen all the clauses.
Something like
p(a).
p(b).
?- forall(p(X), assert(q(X)).
p(c).
was perfectly legal in (interpreted) DEC-10 Prolog and C Prolog, and
Quintus Prolog was able to support that. The other reason is that it
saved memory: Stony Brook Prolog (which considers entire predicates)
often runs out of memory when Quintus Prolog (and SICStus 0.7) manage fine.
If the worst came to the worst, a Prolog compiler could implement
if->then;else by generating an auxiliary predicate, so an implementor
would have to try *very* hard to make if->then;else inefficient!
Actually, I'm rather tired of _not_ being able to rely on inter-clause
optimisation. Stony Brook Prolog does almost exactly the _same_
optimisations for disjunctions (intra-clause) and multiple clauses
(inter-clause) and the Prolog-D compiler that I never finished was going
to do the same thing.
To summarise, whoever told Jocelyn Paine off for using if->then;else
had it exactly backwards. (The proper reply to someone like that is
to write two versions of the code, benchmark them, and rub their
wretched noses in the results.)
Chris Moss
In article <2rrvmo$k...@goanna.cs.rmit.oz.au>, o...@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> It has been a lot longer than one year. The modules group was meeting
> back in 1986. (PS/178 "Draft minutes, Modules group meeting, Nov 1986".)
> Once again, the problem is not the retrofitting of any particular scheme.
> _That_ is easy. The problem is designing a module system that enough
> people on the committee will like
> I am not making this stuff up. I explicitly suggested to the committee
> that they adopt the same guiding principle as the ANSI C committee: the
> language already exists and it's our job to standardise it, not to
> break other people's working code. This principle was not merely not
> adopted, it was explicitly rejected, or so Roger Scowen told me.
Interesting though Richard's quotes are, he's always been seen on the outside
shouting in. As I said before, committees are groups of people meeting in a
physical location to try and come to decisions. That requires a chair,
representatives, the ability to listen to different points of view,
people to take and produce minutes and turn the decisions into
documents, and a productive procedure for taking decisions. Personally I hate
that whole process but I don't see and alternative. It may be these days that
it's better to use the net than meetings but many of the ingredients are still
necessary.
I'm sure Richard went to a number of the early meetings, though I don't recall
ever seeing him there. But too many of his proposals fell simply because there
was no-one to champion them - they were simply tabled. This was back in BSI days
(the British effort which started it). When it went to ISO the same thing
happened. He was ruled out because (partly my fault) he didn't get to a meeting
in Austria from New Zealand where he was at the time.
Richard's remarks about ANSI C don't take into account the great diversity of
early Prolog compared with a language authored, implemented and written about
by two people. In the case of Prolog all those people were different. It is
_partly_ the discussions in the standards committee that has brought about the
current convergence.
So we (all of us) didn't get the standard we wanted. But we have got a standard,
almost. And it's close.
Chris
Paul Holmes-Higgin
have the full text.
I think the standardisation process is interesting, but often more political
than pragmatic. It is also important to remember that when this started in
the mid-80s, there were quite a few more commercial implementations of Prolog
around. This was also the time of the expert systems explosion (Alvey, 5th
Gen., etc.). Prolog was a "new" language and was readily adjusted by each new
implementor. The BSI committee had a lot of commercially motivated people who
wanted to push their particular corner, or make Prolog into their idea of what
Prolog should be. There is still an element of that in the ISO
representatives today, but there is also a different commercial realism as far
as Prolog's place in the languages market.
Viewing the standardisation process as one of achieving concensus, perhaps
Prolog's European ancestry can be blamed (no smiley, I'm serious!).
>po...@vax.oxford.ac.uk (Jocelyn Paine) writes:
>>Only a draft? And not until mid-September? That's 120 days from now.
>>For goodness' sake. I think I first heard about the standard in
>>mid-1992, and it's clearly not ready yet.
Part 1, the main par,t is likely to become an ISO standard next year. The
module system was deliberately put in a separate part so that it didn't
impede the progress of the main text.
>>This really is ludicrous. What the hell is the reason for the delay?
>>If it takes _two years_ to specify the semantics of a language which
>>has been in existence for the past 20, then isn't this a sign that
>>it's so messy that it should be scrapped immediately?
>After a standing start at the beginning of 1984, at the end of February
>1985 I had
> - a complete formal specification of Prolog with cuts, data base changes,
> and I/O
> - a large document explaining all the built-in operations
> - public domain implementations of the read family, the write family,
> the setof family, and a top level
>My estimate is that it would have taken one year to tidy these things up
>and produce a draft standard for the language as it then stood.
... if the standardisation had started 2 years earlier, or 5 years later! And
did the database changes support the "logical" view, as is prevalent now?
Are there no improvements that have been made to Prolog (as a language)
since 1985?
>One major change to Prolog that _was_ needed was error handling.
>I sent a proposal to the BSI committee in late '84 or early '85, but
>it sank without trace until AFNOR suggested the same thing (but with
>different names). The addition required adding about 10 lines to my
>formal specification. I wrote a paper about that, but it was suppressed
>by a certain company.
>>And Paul's comment does nothing to suggest otherwise. If it takes what
>>- one year - to retrofit a modularisation scheme to Prolog, then the
>>language is so complex that we can't hope reliably to understand
>>programs written in it.
The problem with standardisation is also that the text must be tied down so
tightly that it is impossible to misinterpret it - this makes for a lot of
iterations on proof-reading, spread this over several countries and, well,
yes, a year goes by.
>It has been a lot longer than one year. The modules group was meeting
>back in 1986. (PS/178 "Draft minutes, Modules group meeting, Nov 1986".)
>Once again, the problem is not the retrofitting of any particular scheme.
>_That_ is easy. The problem is designing a module system that enough
>people on the committee will like.
Hmmm. It took until 1988 (PS/250, N14) for a discussion paper to be produced
that had a questionnaire as part of a requirements analysis exercise - does
sound a bit like language design rather than standardisation!
>I am not making this stuff up. I explicitly suggested to the committee
>that they adopt the same guiding principle as the ANSI C committee: the
>language already exists and it's our job to standardise it, not to
>break other people's working code. This principle was not merely not
>adopted, it was explicitly rejected, or so Roger Scowen told me.
It was this principle that we used to get the module proposal changed. I also
think that is largely due to Roger Scowen that the Prolog standardisation
process didn't curl up and die. I look forward to the standard finally
appearing next year, then everyone can have an excuse to produce another
edition of their book(s), with a tacky sticker on the front declaring that
it is now fully compatible with ISO Prolog (even though no one will be able to
buy a Prolog that supports it quite yet :-) ).
Paul.
>--
>Richard A. O'Keefe; o...@goanna.cs.rmit.oz.au; RMIT, Melbourne, Australia.
>"C is quirky, flawed, and an enormous success." -- Dennis M. Ritchie.
============================================================
Paul Holmes-Higgin E-Mail: p.holme...@surrey.ac.uk
Artificial Intelligence Group
Dept. of Mathematical and Computing Sciences
University of Surrey Tel: (0483) 259633
Fernando Pereira
> > In article <PEREIRA.94...@alta.research.att.com>, per...@alta.research.att.com (Fernando Pereira) writes:
> > I think that the Mycroft & O'Keefe module proposal, just to name one,
> > has a perfectly good rationale. Lincoln and Sanella's adaptation of
> > SML's module system adds a treatment of parameterized modules that
> > has also a good rationale.
> These particular proposals I don't remember so let me ask whether they cope
> adequately with the problems which have caused the standardisation group to
> thrash around so long: namely the dynamic aspects of Prolog:
to what module does a call to a constructed term refer?
how does a metapredicate defined within a module operate?
I don't remember if either proposal addresses those issues. Richard
may be able to answer. However, I fear that the problem here is the
semantic weirdness of constructed calls and metapredicates, modules or
no modules. There is simply no good solution without a serious
redesign of the langhage to replace those features by semantically
respectable ones (cf. lambdaProlog). Given that, what a standards
committee should have done is to take an existing modules system (take
a vote on the candidades as undivisible packages) and adapt it
minimally to fit the rest of the standard.
> No there ARE workable implementations that cope. But do they have a rationale?
> That I haven't seen. I don't think that parameterised modules are a substitute
> for these.
No, but then as I said, meta-calls have hardly any ``rationale'' anyway,
so adopting a practical modules system with a messy but workable
semantics shouldn't have required so much deliberation.
I fear I'll have to repeat here Richard O'Keefe's complaint about
standardisation: if you try to redesign the language rather than
codifying practice, the standard will fail or become irrelevant.
Ted Dunning
In article <PEREIRA.94...@alta.research.att.com> per...@alta.research.att.com (Fernando Pereira) writes:
I fear I'll have to repeat here Richard O'Keefe's complaint about
standardisation: if you try to redesign the language rather than
codifying practice, the standard will fail or become irrelevant.
no kidding.
the basic position of the committee appears to be:
1) when they started there were too many dialects for them to pick a
particular one.
2) in response to this situation, they decided to rectify the
situation by creating yet another dialect!
this was a *very* clever solution that would not occur to most people.
Richard A. O'Keefe
No. I don't have on-line copies myself, and it would take a couple of
days searching through archive tapes in strange formats to find the
originals, _if_ I still have them.
For what it's worth, the formal definition of Prolog is written in a
typed pure functional language modelled on Hope with the 'case' construct
borrowed from C Prolog version 1.5.edai (in 1989 I converted the spec to
Prolog and ran it). The only _written_ comment I ever saw from the
Prolog standardisers was a dismissive comment from AFNOR to the effect
that it was written in Pascal!!!
Micha Meier
>o...@ursa.sis.yorku.ca (ozan s. yigit) writes:
>>Richard A. O'Keefe:
>> ...
>> For a detailed definition, see my formal definition of Prolog
>> (Auckland 1985) and my detailed description of the built-in predicates
>> (Edinburgh 1984).
>
>>are these papers available via ftp someplace?
>
>No. I don't have on-line copies myself, and it would take a couple of
>days searching through archive tapes in strange formats to find the
>originals, _if_ I still have them.
As a matter of fact, I still have online the file plstd.doc dated 4 Oct 1984
with the Title: Draft Proposed Standard for Prolog Evaluable Predicates.
If Richard agrees, I can put it on our ftp server. It's ASCII.
--Micha
---
Micha Meier ------------------------------------------------
ECRC, Arabellastr. 17 The opinions expressed above are private
D-81925 Munich 81 and may not reflect those of my employer.
mi...@ecrc.de, Tel. +49-89-92699-108, Fax +49-89-92699-170
Richard A. O'Keefe
>Prolog was a "new" language and was readily adjusted by each new
>implementor.
The trouble was that for the most part they "adjusted" their implementations
*away* from each other. With a few praiseworthy exceptions, Prolog vendors
appear to have seen no competitive advantage in compatibility. They did not
realise that working together to establish interim standards would end up
reducing the cost of transition to an official standard (because they would
be able to beat the committee about the head with "*common* practice"), and
they did not realise that compatibility stood a chance of increasing the
total market. Some vendors didn't even bother to be compatible with
THEMSELVES! (Would you believe the Mac version and the DOS version of one
vendor's Prologs did not agree about whether trig functions took their
arguments in radians or degrees?) It's a heck of a state of affairs when
a programmer who wants to write portable Prolog code ends up writing his
own Prolog interpreter in Ada, and yet I've heard of two people having to
do that.
It is not that easy for an implementor to adjust their language.
When Quintus switched from "immediate update" data base changes to
the "transaction" model, some of our customers screamed blue murder and
talked about changing to other vendors. Vendors who _did_ adjust to
the BSI standard found themselves left behind as it changed like dreams.
>The BSI committee had a lot of commercially motivated people who
>wanted to push their particular corner, or make Prolog into their idea of what
>Prolog should be.
The BSI committee's charter (I still have a copy somewhere deep in a pile
of boxes) explicitly stated that the standard was to be based on "Edinburgh"
Prolog. Not micro-PROLOG, not Sigma-PROLOG, not MPROLOG, not Waterloo Prolog,
not you-name-it-Prolog. All of those may be excellent in their way, but the
"base document" was (unfortunately) Clocksin & Mellish. (The C Prolog manual
would have been a better base document because it was _designed_ to present a
complete language, which C&M was not.)
I wrote
>>After a standing start at the beginning of 1984, at the end of February
>>1985 I had
>> - a complete formal specification of Prolog with cuts, data base changes,
>> and I/O
>> - a large document explaining all the built-in operations
>> - public domain implementations of the read family, the write family,
>> the setof family, and a top level
>>My estimate is that it would have taken one year to tidy these things up
>>and produce a draft standard for the language as it then stood.
>... if the standardisation had started 2 years earlier, or 5 years later!
No. Let me repeat what I said. *MY* estimate is that it would have taken
one year to tidy up the base documents I had and produce a *draft*. You
should be aware that the original BSI "charter" said that a draft _would_
be ready in about that time-frame.
>And
>did the database changes support the "logical" view, as is prevalent now?
Yes. Whose names do you see on the paper that presented that view to an
admiring world? Tim Lindholm's and mine.
>Are there no improvements that have been made to Prolog (as a language)
>since 1985?
No. Oh, Quintus Prolog has a lovely module system and a really great
exception-handling facility (great because the exception terms were very
carefully thought out so that pattern matching was useful with them).
NU Prolog has 'when' declarations that are the cat's pajamas. Indeed,
_many_ Prologs now have some form of coroutining BUT THEY ARE ALL DIFFERENT.
Someone who is trying to write portable Prolog is still pretty much limited
to what was in C Prolog. My goodness gracious me, I still can't even rely
on first-argument indexing, still less anything better!
Having an early draft couldn't possibly have made matters worse.
Indeed, it _could_ have made matters better. At least having a portable
"core" that was frozen in 1985 would be better than having a sort-of-
portable (but not completely certain) core that was frozen in 1983.
>I also think that is largely due to Roger Scowen that the Prolog
>standardisation process didn't curl up and die.
About this there can be no possible doubt. He has put an _enormous_
amount of effort into the project, and as far as I am aware has at all
times acted in a thoroughly professional manner. In particular, he
_did_ take steps to find out what existing practice was in a number of
areas.
>I look forward to the standard finally appearing next year, then
>everyone can have an excuse to produce another edition of their book(s),
>with a tacky sticker on the front declaring that it is now fully
>compatible with ISO Prolog (even though no one will be able to buy a
>Prolog that supports it quite yet :-) ).
People have been selling Prolog systems with "ISO compatible" ads for
some time (you know who you are; how do you live with yourselves?).
John Stobo wrote a book "Problem Solving with Prolog". He was on the
BSI committee. The blurb for his book refers to "the emerging BSI
standard". And just about everything he says in the book that applies
to "the standard" rather than to DEC-10 Prolog no longer applies.
Richard A. O'Keefe
>the basic position of the committee appears to be:
>1) when they started there were too many dialects for them to pick a
>particular one.
Ah, but the original charter _did_ specify a particular dialect:
"Edinburgh Prolog, as described in Clocksin & Mellish". Trouble was,
some of the original committee members didn't know any Prolog at all
(I gave one of them his first Prolog lesson _after_ he joined the
committee) and some of the committee members had a financial interest
in other dialects (excellent tools, but not easily made compatible with
Edinburgh Prolog).
Micha Meier
on our ftp server: ftp.ecrc.de:/pub/eclipse/std/plstd.doc.
(I have write permission only for the eclipse directory, that's why it is
there, it has no relation to eclipse, except that we have used some
of the ideas in the implementation.)
Lee Naish
> to what module does a call to a constructed term refer?
> how does a metapredicate defined within a module operate?
>I don't remember if either proposal addresses those issues. Richard
>may be able to answer. However, I fear that the problem here is the
>semantic weirdness of constructed calls and metapredicates, modules or
>no modules. There is simply no good solution without a serious
>redesign of the langhage to replace those features by semantically
>respectable ones
I have the following perspective on the module debate (over the years
quite a few people have said this view clarifies things for them).
There is a sequence of steps to get from the Prolog source file to a
constructed call. For each transition there is a key Prolog builtin
(or builtins).
source file (chars)
|
| see/1, get0/1 (open,...)
V
Prolog strings (identifiers)
|
| name/2 (atom_chars)
V
Atoms (names)
|
| functor/3 ('=..'/2)
V
Compound terms
|
| call/1
V
Procedure calls (atoms in logic terminology)
get0, name and functor are packaged together in read/1.
The only transition which I have any problem with the logic of is the
first one, involving Prolog I/O. There is no declarative definition of
get0.
The others (atom_chars, functor and call) can all be defined easily,
albeit with an infinite number of clauses (you tend to need infinite
numbers of clauses to handle numbers also):
atom_chars(a, "a").
atom_chars(atom_chars, "atom_chars").
...
functor(f(_), f, 1).
functor(functor(_,_,_), functor, 3).
...
call(p(X)) :- p(X).
call(atom_chars(X, Y)) :- atom_chars(X, Y).
call((X, Y)) :- call(X), call(Y).
call(call(X)) :- call(X).
...
The only problem here is the handling of cut within call. I don't think
there are many portability freaks or implementors out there who would
shed a tear if the standard said cut was just not supported inside call.
So, how does this relate to modules?
The main point is that one of the transitions has to be broken.
Different choices of module schemes choose to break Prolog at different
points. So called predicate based schemes break call/1. Atom based
schemes break something earlier on (eg, atom_chars).
I have always been keen on simplicity and I think its simpler to break
things early on. You can even break the first transition (get0),
implementing a module system without changing Prolog at all, simply by
preprocessing the source file and renaming identifiers (we had an
implementation of this back in 1986 or 1987). The semantics of a (pure)
program can then be given very easily.
So, I think there is no problem designing a module system for Prolog
which is "semantically respectable". The problem is convincing people
that semantically respectability is important and getting them to agree
on such a module system.
lee
ozan s. yigit
I have put the text of R.A.O'Keefe's Prolog standard draft from 1984
on our ftp server: ftp.ecrc.de:/pub/eclipse/std/plstd.doc.
thank you for making this amazing document available.
oz
---
It is harder to get lost in an imagined forest than in a real one, for
the former assists the thinker furtively. -- golem [lecture XLIII]
Richard A. O'Keefe
>I'm sure Richard went to a number of the early meetings, though I don't recall
>ever seeing him there.
No, I didn't. By the time I received an _offer_ to attend a BSI meeting,
I was already back in New Zealand (broke). A little pre-history may be of
interest too: a bunch of people from Edinburgh ran an AI course at
Solartron. One of the things _they_ taught _us_ was that however much
they would like to use Prolog, their management were unhappy with them
using anything that didn't have a standard. They had Poplog, and I had
brought a tape with the C-Prolog version of the Edinburgh library, and
spent several hours fitting it into Poplog. So I went back to Edinburgh
and spent about a week writing the document that became PS/6. I posted
to the net (the Prolog Digest) asking for commments. Much later, at a
workshop on intelligent interfaces, Aaron Sloman told me that NPL had
started up a Prolog standardisation effort. I've forgotten who it was
at NPL that started the ball rolling. The really curious thing is that
the NPL guy said that he had started the process himself because he had
asked around in the UK and noone else was interested in doing it. But
***NO-ONE*** at Edinburgh had ever been contacted!!!
>But too many of his proposals fell simply because there
>was no-one to champion them - they were simply tabled.
This amounts to unprofessional behaviour. Recall: the standard was
supposed to be based on "Clocksin & Mellish Edinburgh Prolog". I had
worked on a tiny part of DEC-10 Prolog (print/1) and maintained C Prolog,
and was the principal author of the free and internationally available
Prolog library. I believe I was the only person sending proposals to the
committee *at the time* who had used all the Edinburgh Prologs (DEC-10,
C-, EMAS, NU7, ZIP). In context, the failure of the committee to even
_read_ my proposals properly does not reflect well on them. (Bill
Clocksin saw some of my stuff, and approved it, but the committee never
seem to have paid much attention to him either.)
I put a *hell* of a lot of *unpaid* work into writing documents for the
BSI Prolog effort (I mean that I was doing them at a time when my income
was zero total, not just that I wasn't being paid for that). My reward?
At the beginning of 1985 I sent a document to the BSI proposing an
exception-handling mechanism closely modelled on that in SMALL (and Ada).
The *only* written reference to it I have seen in any official document
is where someone berated me for proposing a global error handling, which
is the precise opposite of what I proposed! (What I proposed eventually
made it into Quintus Prolog. Look at that to see what I did propose.)
I provided a formal semantics that handled _everything_ except opening
and closing files (it did handle transput to existing connections), a
semantics written in a pure functional language. Again, the only written
admission that the thing exists is from an AFNOR guy who berated me for
using Pascal!
As I pointed out on the platform of a conference in 1985, some of the
people then on the BSI Prolog commitee knew no Prolog at all, and one
of those who did I had given his first lessons _after_ he joined.
(That was how the early proposal to base "Edinburgh" Prolog semantics
on Sigma-PROLOG data structures got as far as it did, or so he told me.)
If the committee had said "we shan't bother with this O'Keefe idiot,
we'll go straight to the _real_ experts like Warren, Pereira, Byrd,
Clocksin, and Mellish", I wouldn't have had a leg to stand on. They'd
have been _right_ to do so. Had they gone to Dave Bowen, again I'd have
had no leg to stand on. Did they have someone who had ported or tried to
port several large Prolog programs between several radically different
operating systems (not to mention dialects)?
The ALP _did_ eventually ask me to be an official representative on the
ISO committee and I was _very_ grateful for that offer. I very much
wanted to accept, but RMIT said "only if someone else will pay us for
the loss of your time", so that was that.
>Richard's remarks about ANSI C don't take into account the great diversity of
>early Prolog compared with a language authored, implemented and written about
>by two people.
Richard *does* take those things into account. I keep on saying it over and
over again: the remit of the standard was *explicitly* to develop a standard
based on Edinburgh Prolog as described in Clocksin & Mellish. The range of
dialects which fitted that description at that time is nowhere near as great
as one might suppose: DEC-10 Prolog, EMAS Prolog, C Prolog, NU7 Prolog,
Poplog (almost), one version of Waterloo Prolog, and ZIP. They were at that
time closer to each other than the current draft of the substandard is to
any of them. micro-PROLOG and Sigma-PROLOG clearly fell outside the
scope of the standard. (I have known people to deny that there was any such
"scope", but I have a copy of the document.)
I also take into account the fact that the range of variation in C was
rather greater than one might suppose. C on the DEC-10 running TOPS-10,
C on a PDP-11 running V6 UNIX, C on a VAX running 4.2BSD, Whitesmiths C,
Computer Innovations C86, VAX-11 C on a VAX/VMS, there were very important
differences. Having used these Cs, when the C standard was just under way,
and having used those Edinburgh Prologs, when the Prolog standard was
starting, I flatly deny that >>>Edinburgh Prolog, as described in Clocksin
& Mellish<<< was any more varied than >>>C, as described in Kernighan &
Ritchie<< from a practical point of view. Indeed, I would say that porting
a non-trivial C program from V7 UNIX to TOPS-10 was *harder* than porting
a similar program from Poplog to DEC-10 Prolog.
>It is _partly_ the discussions in the standards committee that has
>brought about the current convergence.
You have _got_ to be joking! The Aquarius Prolog manual says it's like
Quintus Prolog. The SICStus manual says it's like on Quintus Prolog.
They get _some_ of their syntactic compatiblity with Quintus Prolog by
starting from free code that I provided. The SEPIA 3.0 manual that I
have talks about C Prolog (appendix B), Quintus Prolog (appendix H),
and SICStus Prolog (appendix I). I can find no mention of the standard
in it at all. The IBM Prolog manual (V1 R1) talks about "Edinburgh"
Prolog, and it means DEC-10 Prolog and C Prolog. There is _no_ reference
to the standard at all. The LPA 386-Prolog manual talks about Quintus
Prolog, but not the standard.
Let's be really honest about this, shall we? When finally drafts of the
standard _did_ start appearing, they were too different from existing
practice, and changed too frequently, to help anyone converge to anything.
The designers of BNR Prolog _did_ make a conscious, praiseworthy, and
careful attempt to follow the then current draft. Surprise! Today's
drafts of the substandard are so different that no-one would suspect any
connection!
What *has* happened is that in the real world, those vendors who wanted
to be compatible with "Edinburgh Prolog" either took C Prolog as their
model, or Quintus Prolog. I think it is fair to say that the entire
credit for such commonality as currently exists belongs to Fernando
Pereira, who made C Prolog.
How can the committee take any credit when their dialect is *LESS*
compatible with existing dialects than they are with each other?
>So we (all of us) didn't get the standard we wanted.
>But we have got a standard, almost. And it's close.
Close to _what_, though? Close to coming out? Maybe.
Close to current practice? Closer than it _was_, but not close enough.
Consider this point:
- in Edinburgh Prolog, unquoted commas are punctuation marks,
NOT operators.
- in Edinburgh Prolog, *any* atom can be the operand of an operator,
provided the priority is high enough.
In the current draft, neither of these things is true.
Well, I wanted to experiment with arrays. Following BCPL, I was using
infix bang to mean subscript, so I could do
X := A!I
and the like. Now I am told that in the current draft substandard,
an atom which is an operator cannot be an operand unless it is enclosed
in parentheses, so that a clause like
p(I, _, A, X) :- X := A!I, !.
is illegal. What silliness. Existings Prologs neither have no need such
a restriction. (C Prolog, with its parser written entirely in C, didn't.)
So why does the substandard?
Sometimes a standard comes out and has no effect at all.
They were talking about ISO Pascal Extended in Sigplan Notices for years.
(Why didn't the Prolog committee publish things there from time to time?)
The standard came out in 1991. I am aware of only one ISO Pascal Extended
compiler, and it's not finished yet. And Borland satisfy an incredible
number of customers with a Pascal product that has never conformed to any
known language standard.
The latest draft of the substandard that I have seen is sufficiently
different from existing practice that no-one will have any reason to
switch over. Will it make any sense for Prolog vendors to switch over?
Many of them are just barely surviving; why should they spend time and
money making their product *less* compatible with their competitors,
and less useful to their customers?
SEPIA, CHIP, NU Prolog, SICStus Prolog, XSB, ...
the ISO Prolog substandard is already obsolete. It would be nice for
industry if they had something they could trust. Let's give them SWI
Prolog and tell them to get on with it.
--
30 million of Australia's 140 million sheep
suffer from some form of baldness. -- Weekly Times.
Fernando Pereira
[ illuminating discussion of module systems]
So, how does this relate to modules?
The main point is that one of the transitions has to be broken.
Different choices of module schemes choose to break Prolog at different
points. So called predicate based schemes break call/1. Atom based
schemes break something earlier on (eg, atom_chars).
I have always been keen on simplicity and I think its simpler to break
things early on. You can even break the first transition (get0),
implementing a module system without changing Prolog at all, simply by
preprocessing the source file and renaming identifiers (we had an
implementation of this back in 1986 or 1987). The semantics of a (pure)
program can then be given very easily.
So, I think there is no problem designing a module system for Prolog
which is "semantically respectable". The problem is convincing people
that semantically respectability is important and getting them to agree
on such a module system.
Your model is based on textual rewrite/substitution. I suspect that analysis
starts to get in trouble when applied to more powerful module systems
based on parameterization, eg. the higher-order functor extension of
the ML module system or some of the module proposals for
lambdaProlog. To analyse those, explicit notions of naming environment
and module elaboration seem required (cf. the formal defn of Standard
ML).
Fernando Pereira
>Richard's remarks about ANSI C don't take into account the great diversity of
>early Prolog compared with a language authored, implemented and written about
>by two people.
Richard *does* take those things into account. I keep on saying it over and
over again: the remit of the standard was *explicitly* to develop a standard
based on Edinburgh Prolog as described in Clocksin & Mellish. The range of
dialects which fitted that description at that time is nowhere near as great
as one might suppose: DEC-10 Prolog, EMAS Prolog, C Prolog, NU7 Prolog,
Poplog (almost), one version of Waterloo Prolog, and ZIP. They were at that
time closer to each other than the current draft of the substandard is to
any of them. micro-PROLOG and Sigma-PROLOG clearly fell outside the
scope of the standard. (I have known people to deny that there was any such
"scope", but I have a copy of the document.)
I believe that Richard's grim account of the Prolog
mis-standardization effort is right on the mark, but let me second in
particular the above point. I have ported many Prolog programs among
DEC-10 Prolog, PDP-11 Prolog, C-Prolog, Quintus Prolog and even
Waterloo Prolog and VM/Prolog. In the worst case it took me a few days
to convert 1000s of lines of Prolog. The reason why ports between most
early Prolog dialects was relatively easy is that, except for David
H. D. Warren's improved syntax and English names for builtins and a
few new builtins, all those systems were mostly based on readings of
the original reports and code from Marseilles and of David's papers
and code. So, even though there were more people implementing language
systems in the early history of Prolog than in the early history of C,
they all shared a lot of assumptions and so the operational semantics
of the systems were quite similar once the syntactic veneer was
removed. I believe that the early BSI standardization group completely
missed the underlying unity of that cluster, and got completely hung
up on superficial characteristics and turf battles (eg. the one
involving micro-Prolog and Sigma-Prolog, which *were* rather different
languages from Marseilles/Edinburgh/Waterloo systems in important
aspects of the operational semantics --- eg. a single functor
"cons"). The situation only deteriorated when the effort became
international and the new Prolog-like languages from Marseilles,
etc. entered the turf war.
SEPIA, CHIP, NU Prolog, SICStus Prolog, XSB, ...
the ISO Prolog substandard is already obsolete. It would be nice for
industry if they had something they could trust. Let's give them SWI
Prolog and tell them to get on with it.
There was a windonw of opportunity to standardize Prolog in the mid to
late 80s. A good standard would have mattered then to help the
language along in the business world. That opportunity is now lost, I
believe, as the interest surrounding Prolog then and the resources
supporting its development have dwindled. Whatever the intent of the
standardizers, especially those in the early BSI effort, I'm afraid
they undermined Prolog more effectively than most of its
opponents. ``The road to Hell...''
ozan s. yigit
A good standard would have mattered then to help the
language along in the business world. That opportunity is now lost [...]
that may be true, but so long as there are good implementations one can
count on, one can safely ignore a "standard" that clearly fails its
raison d'e^tre. i just hope implementors will have enough courage
to ignore this mess where necessary.
oz
---
a technology is indistinguishable from | electric: o...@sis.yorku.ca
its implementation. -- Marshall Rose | or [416] 736 2100 x 33976
Micha Meier
>... The SEPIA 3.0 manual that I
>have talks about C Prolog (appendix B), Quintus Prolog (appendix H),
>and SICStus Prolog (appendix I). I can find no mention of the standard
>in it at all.
As a matter of fact, we seem to be the only ones that have actually implemented
the BSI standard draft and we regretted it soon after. To avoid similar errors
in the future, we have decided to make SEPIA/Eclipse as general as possible,
which would allow us to adopt any reasonable standard easily enough, and which
also makes possible to write compatibility libraries for other dialects.
The BSI library, however, is still available in Eclipse, although not
documented.