Why hasn't Prolog Taken over the World?
Roland Karlsson
> Why hasn't Prolog Taken over the World?
1. You need that AHA experience before you understand how good it is.
It is much easier to start programming C. (Why the industry tries
to use C++ I do not know, it is much much harder to learn than C.)
2. Most Prolog environments are just that - environments. The Prolog
query top loop is very nice for debugging and for some applications.
For most applications though, you need to be able to make small,
easy to compile stand alone applications.
3. Conservatism. A company needs some serious motivation before trying
something new.
4. Prolog has an academic flavour. Industry tends to look at
academic work with some amusement.
5. Lack of control over memory allocation. This is a serious one!
6. It should not! Different problems needs different tools. I write all
my image manipulaton programs in C and all my problem solving
in Prolog and almost all my UNIX system tools in csh.
--
-----------------------------------------------------------------------------
Roland Karlsson Inet: rol...@sics.se Telex: 812 6154 7011 SICS
SICS, PO Box 1263, Tel: +46 8 752 15 40 Ttx: 2401-812 6154 7011=SICS
S-164 28 KISTA, SWEDEN Fax: +46 8 751 72 30
-----------------------------------------------------------------------------
Michael Covington
programming languages for different purposes. There is a lot of
"C chauvinism" (and, earlier, Fortran or assembler chauvinism); that
is, there are lots of managers (and programmers) who believe that all
work, of whatever type, should be done in the same programming language.
--
< Michael A. Covington, Assc Rsch Scientist, Artificial Intelligence Center >
< The University of Georgia, Athens, GA 30602-7415 USA mcov...@ai.uga.edu >
< Unless specifically indicated, I am not speaking for the University. > <><
> "To 'see through' all things is the same as not to see them." -C.S. Lewis <
Herb Martin
I think it helps (maybe not) that I know Lisp. I am learning Prolog
because many of my clients are facing problems that should be solved with
AI -- especially rules based -- techniques.
If I indeed have 'gotten it', I am still concerned that I must next 'explain
it'.
BTW, I think is was the example in Bratko where he shows that 'del' (on
a list) can be used to create member and even 'conc'. That was weird but
when I saw it my paradigm shifted.
Cliff High (ch...@halcyon.com) wrote:
: In article <3a6lf4$m...@mozo.cc.purdue.edu> he...@ecn.purdue.edu (Randall A Helzerman) writes:
: >From: he...@ecn.purdue.edu (Randall A Helzerman)
: >Subject: Why hasn't Prolog Taken over the World?
: >Date: 14 Nov 1994 03:27:32 GMT
: >I used to be a confirmed Prolog hater. I took a class in it
: >a long time ago and determined that it was the absolutely most
: >bizzare programming language I ever saw.
: >However, recently, I've been forced into using it again, and I finally
: >"got it". Whatever that "aha" experience is which people go through,
: >I went through it and now think that Prolog and declarative programming
: >is wonderful.
: >But what I'm wondering now is, why isn't Prolog more popular than it
: >is?
: Prolog is an unknown quantity as far as corparations are concerned. It cannot
: take over the world until there is sufficient ground breaking in the
: development houses. It takes money to make money, it takes risk and success to
: convince others to follow.
: However, the ability of corp. dev to keep pace with the demands with the
: programming tools that they have is failing. The staffers are producing huge
: amounts of code and it is still not enough.
: I recently completed the Vortex 1 project on a deadline of one week in prolog
: from LPA (WinProlog). It took less than 500 lines of program code on a
: prototype that had to function with some sophistication. It took me so long be
: cause it has been 7 years since I last programmed in Prolog. Since then I have
: been cutting C++ code. I had to unlearn a lot.
: Prolog will take over but it is hell to learn until the flow experience take
: hold.
: Cliff High
: Tenax SE
: ch...@halcyon.com
Richard Pitre
really available thing with a built in optimized searcher/backtracker. For many
problems where a solution must be *found* as opposed to simply procedurally
encoded then PROLOG is the thing to do. If you already know an algorithm to
compute what you want then you don't need a backtracker, you need an optimized
proceedural language like C.
In article <3a6lf4$m...@mozo.cc.purdue.edu> he...@ecn.purdue.edu (Randall A
Helzerman) writes:
> I used to be a confirmed Prolog hater. I took a class in it
> a long time ago and determined that it was the absolutely most
> bizzare programming language I ever saw.
>
> However, recently, I've been forced into using it again, and I finally
> "got it". Whatever that "aha" experience is which people go through,
> I went through it and now think that Prolog and declarative programming
> is wonderful.
>
> But what I'm wondering now is, why isn't Prolog more popular than it
> is?
>
> Efficiency? Well, I coded a resolution/refutation theorem prover
> once, and let me tell you it wasn't nearly as fast as even the cheesiest
> prolog implementations I've tried.
>
> Price? There's good PD implementations, and for professional tools price
> really isn't an issue.
>
> Bigotry? I can understand this one. All of the Object-oriented weenies
> make much ado about the "paradigm shift" to the "object" way of thinking,
> but my personal experience is that next to the declarative shift,
object-oriented
> programming is so traditional as to be traditional.
>
> Or is there something else I'm missing? Is there some "hidden gotcha" to
> prolog which makes it ultimatly not usable for anything but toy projects?
Wayne Citrin
Prolog would be much more successful if systems included a number of
features that most systems seem to lack.
- Most Prologs I've encountered offered no support for modularity. In the
ones that had it, it was rudimentary. Such support is necessary if Prolog
is to be used for the development of large software systems.
- Usable commercial Prolog systems should support something like strong
typing (preferably without sacrificing too much of the power of the
model). Many bugs in Prolog programs are essentially type errors.
- Debuggers employing the Byrd box model are very hard to use, and are an
artifact of a time when graphics was expensive. Usable Prolog systems
should employ TPM's AORTA-diagram visual model as a standard.
Wayne
--
Wayne Citrin cit...@soglio.colorado.edu cit...@cs.colorado.edu
Michael Brady
cit...@cs.colorado.edu (Wayne Citrin) wrote:
> [...]
>
> - Debuggers employing the Byrd box model are very hard to use, and are an
> artifact of a time when graphics was expensive. Usable Prolog systems
> should employ TPM's AORTA-diagram visual model as a standard.
Another point about the box model is that it conceals an important part of
any real Prolog implementation, namely last call optimisation. You need to
do considerable violence to the memory management of an implementation to
build the box model into it, and even then it's unsatisfactory.
Instead of doing this, most implementers seem to build a special debugging
interpreter on top of their implementation to incorporate the box model.
Does AORTA reflect what's happening more accurately?
--
Mike Brady
Computer Science Department, Trinity College Dublin, Ireland
Alexander Bottema
> typing (preferably without sacrificing too much of the power of the
> model). Many bugs in Prolog programs are essentially type errors.
First, I do not agree that most errors in Prolog are type errors. I
have written quite large Prolog programs (including a Prolog -> WAM
compiler; ok. it isn't that large) and my experiences are that type
errors are uncommon. Why? Well, Prolog use Herbrand terms as
fundamental data structures. There are some natural extensions due to
efficiency such as integers, float numbers and such, but one rarely
mixes these with Herbrand terms.
Second, it isn't trivial to develop a type system for Prolog (or for
logic programming languages). What is the type of a predicate? In
functional languages the type inference mechanism is obvious; the type
is simply derived from its components.
However, one possible extension would be to introduce contraints on
Prolog variables. Perhaps you would like this notation:
p(X:[int],Y:[int],Z:[int]) :- ... X ... Y ... Z ...
But this is the same as writing:
p(X,Y,Z) :- integer(X), integer(Y), integer(Z), ... X ... Y ... Z
And a good Prolog compiler with global data flow analysis would of
course optimize calls to this predicate by skipping the integer
predicates if X, Y and Z are known to be integers before the call,
e.g.
q :- X is 42, Y is 4711, Z is 17, p(X,Y,Z), ...
So, instead of augmenting the language with syntactic sugar it would
be much better to make the compilers more efficient, e.g. by
introducing global data flow analysis.
--
Alexander Jean-Claude Bottema, Email: d91...@meryl.csd.uu.se
University of Uppsala, Computing Science Department.
#include <stddisclaim.h> LINUX,GCC,Eiffel,Haskell,ML,CAML-light,Prolog
http://www.csd.uu.se/~d91a1bo/ LINUX LINUX LINUX LINUX LINUX LINUX
Wayne Citrin
(Michael Brady) wrote:
> Another point about the box model is that it conceals an important part of
> any real Prolog implementation, namely last call optimisation. You need to
> do considerable violence to the memory management of an implementation to
> build the box model into it, and even then it's unsatisfactory.
>
> Instead of doing this, most implementers seem to build a special debugging
> interpreter on top of their implementation to incorporate the box model.
>
> Does AORTA reflect what's happening more accurately?
We probably want different things out of a debugger. I would like a
debugger that explicitly displays the current choice point structure, and
how it relates to the source code. I imagine an AORTA diagram could be
modified to say something about last call optimization, but it isn't
standard. What you would probably like is a visualization of the stack.
This isn't surprising. Different debuggers should be used for different
purposes.
Wayne Citrin
d91...@Ankara.meryl.csd.uu.se (Alexander Bottema) wrote:
> > - Usable commercial Prolog systems should support something like strong
> > typing (preferably without sacrificing too much of the power of the
> > model). Many bugs in Prolog programs are essentially type errors.
>
> First, I do not agree that most errors in Prolog are type errors. I
> have written quite large Prolog programs (including a Prolog -> WAM
> compiler; ok. it isn't that large) and my experiences are that type
> errors are uncommon. Why? Well, Prolog use Herbrand terms as
> fundamental data structures. There are some natural extensions due to
> efficiency such as integers, float numbers and such, but one rarely
> mixes these with Herbrand terms.
Yes, Herbrand terms are untyped in the sense you mention, but that doesn't
mean that type errors don't occur, in the sense of calling a procedure
with a structure with the wrong functor or arity, or calling a procedure
with an atomic argument when a structure was expected, or vice versa. I
think these errors are fairly frequent. The problem is that no
distinction is made among kinds of failure - failure as part of the normal
execution of the program vs. failure due to incorrect operands - which
makes them difficult to track down.
>
> Second, it isn't trivial to develop a type system for Prolog (or for
> logic programming languages). What is the type of a predicate? In
> functional languages the type inference mechanism is obvious; the type
> is simply derived from its components.
I agree this wouldn't be trivial. It might well be useful, however, for
detecting certain errors before the program is run.
>
> However, one possible extension would be to introduce contraints on
> Prolog variables. Perhaps you would like this notation:
>
> p(X:[int],Y:[int],Z:[int]) :- ... X ... Y ... Z ...
>
> So, instead of augmenting the language with syntactic sugar it would
> be much better to make the compilers more efficient, e.g. by
> introducing global data flow analysis.
No, this isn't what I had in mind. What I had in mind was a global
structural analysis to make sure that the arguments of a call were in some
sense compatible with the called procedure's arguments. A good deal of
this could be done without any additional input from the programmer, but
it would be even more effective with some programmer-supplied data.
Corin Gurr
>First, I do not agree that most errors in Prolog are type errors. I
>have written quite large Prolog programs (including a Prolog -> WAM
>compiler; ok. it isn't that large) and my experiences are that type
>errors are uncommon. Why? Well, Prolog use Herbrand terms as
>fundamental data structures. There are some natural extensions due to
>efficiency such as integers, float numbers and such, but one rarely
>mixes these with Herbrand terms.
I disagree. I have also written quite large Prolog programs which had
errors that a type system would have detected and this has nothing to
do with Prolog using Herbrand terms. A lot of (in my experience)
common errors (eg: mis-spelled constant, functor and predicate names,
missing arguments in predicates, predicates with arguments in wrong
order etc) would be detected by a type-checker at *compile-time*
rather than spending hours tracing through program execution.
I was convinced of the advantages of a typed logic programming
language when I started using Goedel. I have written some very large
programs in Goedel and I would estimate that at least 80% of the
errors I made when writing them were detected at compile-time by the
type-checker. Of course, I may simply be a very bad typist but I now
find untyped Prolog vastly inferior by comparison.
>Second, it isn't trivial to develop a type system for Prolog (or for
>logic programming languages). What is the type of a predicate? In
>functional languages the type inference mechanism is obvious; the type
>is simply derived from its components.
Well, while it is not trivial I think it is a lot more obvious than
you imply. Goedel's type system is based on the following:
@inproceedings{hill92,
author = "P M Hill and R W Topor",
booktitle = "Types in Logic Programming",
editor = "F Pfenning",
publisher = "MIT Press",
title = "A Semantics for Typed Logic Programs",
year = "1992",
pages = "1--62"
}
Obviously this is not the only possible type system for logic
programming but it's pretty good. Developing a type system for
logic programming languages *is* trivial if someone else has already
done it.
>However, one possible extension would be to introduce contraints on
>Prolog variables. Perhaps you would like this notation:
> p(X:[int],Y:[int],Z:[int]) :- ... X ... Y ... Z ...
>But this is the same as writing:
> p(X,Y,Z) :- integer(X), integer(Y), integer(Z), ... X ... Y ... Z
In Goedel the equivalent type declaration would look like this:
PREDICATE P : Integer * Integer * Integer.
I don't see that it takes any more effort/space to write this as
opposed to your suggestion.
>And a good Prolog compiler with global data flow analysis would of
>course optimize calls to this predicate by skipping the integer
>predicates if X, Y and Z are known to be integers before the call,
>e.g.
> q :- X is 42, Y is 4711, Z is 17, p(X,Y,Z), ...
>So, instead of augmenting the language with syntactic sugar it would
>be much better to make the compilers more efficient, e.g. by
>introducing global data flow analysis.
This is a good suggestion - but I suspect that implementing a data
flow analysis of the kind you suggest would involve a lot of
work. If you already know the types of X, Y and Z because you
were using a typed language then you could perform the same compiler
optimisations without the compiler having to do the global analysis to
identify the types in the first place.
I have written large programs in Prolog and I have written large
programs in Goedel. I prefer Goedel for lots of reasons, but if its
*only* advantage were the type system, that would be enough.
>--
> Alexander Jean-Claude Bottema, Email: d91...@meryl.csd.uu.se
> University of Uppsala, Computing Science Department.
> #include <stddisclaim.h> LINUX,GCC,Eiffel,Haskell,ML,CAML-light,Prolog
> http://www.csd.uu.se/~d91a1bo/ LINUX LINUX LINUX LINUX LINUX LINUX
--
Corin Gurr
Human Communication Research Centre Tel.: +41 31 650 4448
Edinburgh University Email: co...@cogsci.ed.ac.uk
2 Buccleuch Place FAX: +41 31 650 4587
Cliff High
>Subject: Why hasn't Prolog Taken over the World?
>Date: 14 Nov 1994 03:27:32 GMT
>I used to be a confirmed Prolog hater. I took a class in it
>a long time ago and determined that it was the absolutely most
>bizzare programming language I ever saw.
>However, recently, I've been forced into using it again, and I finally
>"got it". Whatever that "aha" experience is which people go through,
>I went through it and now think that Prolog and declarative programming
>is wonderful.
>But what I'm wondering now is, why isn't Prolog more popular than it
>is?
Prolog is an unknown quantity as far as corparations are concerned. It cannot
Matthew Huntbach
: If you need to search for a solution then Prolog seems to be about the only
Only if you want a depth-first left-to-right search. In most cases you don't
want something so simplistic, so when writing search programs in Prolog
you end up having to put the search in yourself and sabotage Prolog's built-in
search with cuts.
Matthew Huntbach
Matthew Huntbach
: I need no convincing that Prolog is a great language. My guess is that
: Prolog would be much more successful if systems included a number of
: features that most systems seem to lack.
: - Most Prologs I've encountered offered no support for modularity. In the
: ones that had it, it was rudimentary. Such support is necessary if Prolog
: is to be used for the development of large software systems.
: - Usable commercial Prolog systems should support something like strong
: typing (preferably without sacrificing too much of the power of the
: model). Many bugs in Prolog programs are essentially type errors.
The Goedel logic programming language (see the book published this year by
MIT Press, authors Patricia Hill and John Lloyd) has both these things. I've
been critical of Goedel in the past in this group for other reasons, but I
agree with it on types and modules: these things have to be in a language,
logic or otherwise, if it's to be a serious tool for serious programming and
not just a toy.
Matthew Huntbach
Randall A Helzerman
a long time ago and determined that it was the absolutely most
bizzare programming language I ever saw.
However, recently, I've been forced into using it again, and I finally
"got it". Whatever that "aha" experience is which people go through,
I went through it and now think that Prolog and declarative programming
is wonderful.
But what I'm wondering now is, why isn't Prolog more popular than it
is?
Efficiency? Well, I coded a resolution/refutation theorem prover
Don Ferguson
dead, or just resting? And if it's not dead, then what can be done to
breathe some life into it?
I'm afraid that features such as multi-threading, better modules, constraints,
etc. won't make a difference. If people believe that Prolog is dog meat, then
new and improved dog meat isn't going to make 'em salivate. The same is
true for standardized dog meat. Standardization comes roughly 8 years too
late.
Nevertheless, in a world where Richard Nixon can become an elder statesman,
and where Marion Barry can be re-elected, anything is possible (for non-u.s.
readers, Marion Barry is the crack smoking mayor of Washington D.C., and
Richard Nixon was a notorious criminal).
Perhaps pockets of Prolog fanatics will survive the current C++ plague.
Perhaps they will rise from the rubble, emerging from the dank corners
and corridors of research labs around the world, and Prolog will be
recognized as the true savior of Computer Science.
Man, I gotta lay off those drugs.
Amzi!
>The question I have is whether it is too late for Prolog. Is the language
>dead, or just resting? And if it's not dead, then what can be done to
>breathe some life into it?
That's the key question...(see response below)
>I'm afraid that features such as multi-threading, better modules, constraints,
>etc. won't make a difference. If people believe that Prolog is dog meat, then
>new and improved dog meat isn't going to make 'em salivate. The same is
>true for standardized dog meat. Standardization comes roughly 8 years too
>late.
>...
>Perhaps they will rise from the rubble, emerging from the dank corners
>and corridors of research labs around the world, and Prolog will be
>recognized as the true savior of Computer Science.
Prolog does not have to take over the world to be a successful, useful
tool. Very few products enjoy the widespread use of 'C' or Cobol.
Trying to convince major development organizations to ditch such well
entrenched standards is extremely difficult for the reasons cited by
others in this thread.
But, Prolog is an ideal tool as a component of a larger application
(written in C, Basic or Cobol). Then, you can use Prolog for the things
it does best: search, pattern matching, multiple constraints, etc. and
use C/Basic for the rest of the application. Used in this way Prolog
becomes like any other database, graphics or other library/API. It is a
service for the main application to call upon when advice, diagnosis or
other logic functions are needed.
So getting back to the first question. Prolog is resting and waiting. I
think the time is here for tools that help manage application
complexity. As every programmer and user of Windows can attest, it is
just too complex, and its getting more so each day. We are not going to
reduce the complexity, but the advent of wizards, advisors, tutors,
intelligent help, on-line diagnostics, automated configuration and more
signals the beginning of a search for tools to manage complexity.
Microsoft is using Prolog in its NT network configuration and
installation tools. We're seeing more and more major companies using
Prolog as components of their larger applications. Now is the time to
make Prolog accessible and understandable to C/Basic programmers and to
standardize on a single, portable dialect.
Mary
--
Amzi! inc. 40 Samuel Prescott Dr.
Stow, MA 01775, U.S.A.
--------------------------------------------------------
tel 508/897-7332 am...@world.std.com fax 508/897-2784
--
Amzi! inc. 40 Samuel Prescott Dr.
Stow, MA 01775, U.S.A.
--------------------------------------------------------
Walter Howard
got very addicted to Prolog at the time but there was no work around
here for that.
From what I have seen, many languages get penetration into the real
world via this series of events:
1) Small company needs some computerization.
2) They hire the cheapest programmer they can afford who uses the
language of his choice ( Visual Basic is a good example here ). In
many cases the programmer is a friend of the business owner or
recommended by word of mouth.
3) The Small company grows larger and so does the original system. Now
we have a major system built from a language whose selection was made
on a whim, not an assessment of real capability.
4) Every company I have been in, without exception, at this point
gets the notion that they could sell their internal computer system
to others in their particular vertical market.
5) Some of these successfully do this and then sell the system to
a Software Only type marketing company.
6) Voila. It looks like the product was developed from scratch by
this software company but in reality is was just a kludge put
together years before and repackaged with new flair.
The above scenario provides some hints to those who want their language
accepted.
1) Compilers must be made available cheaply to the original
progammers/ hackers who get them used in the real world. More than
$100 is too much.
2) The language has to be understandable to newbies.
3) The language has to be appealing to newbies. In many cases lots of
bells and whistles and pretty lights do the trick ( thus the
popularity of the god-awful garbage dump called Microsoft Windows )
Visual Basic fits all of the above and it is shocking how much demand
there is for programmers who know it. It's a sad state of affairs.
My wife is glancing at her watch and wants to go christmas with me
shopping so I have to sign off now.
--
+=============================================================+
You may think I'm crazy, but remember, you heard it here first!
+=============================================================+
Michel BILLAUD
Michael Covington (mcov...@ai.uga.edu) wrote:
: I think industry is generally resistant to the idea of using different
: programming languages for different purposes. There is a lot of
: "C chauvinism" (and, earlier, Fortran or assembler chauvinism); that
: is, there are lots of managers (and programmers) who believe that all
: work, of whatever type, should be done in the same programming language.
Hiring new programmers, or training old ones to another programming
language, simply costs a lot of money in the short term, and in the
medium term the "enhanced programmer" could very well leave the shop
for a better paid job.
Using only one wide-spread programming language (that is C, C++, Cobol
or Fortran) has some advantages
- the language is here to stay (the compiler will be supported by the
next OS version)
- a missing programmer can be replaced straight off by someone else.
- new (or experienced) programmers are easy (and cheap) to find
when needed
M Billaud
Thomas Sj|land
>(written in C, Basic or Cobol). Then, you can use Prolog for the things
>it does best: search, pattern matching, multiple constraints, etc. and
>use C/Basic for the rest of the application. Used in this way Prolog
>becomes like any other database, graphics or other library/API. It is a
>service for the main application to call upon when advice, diagnosis or
>other logic functions are needed.
My 2 cents:
Logic programming environments, like those of other languages
developed in the 70s and 80s has in my opinion a serious problem
(apart from their often inherent single-threadedness):
- It is often difficult to write small programs that load quickly and
perform a simple task without interaction with a "top level". More
efforts must be put into interoperability and GUI-integration so that
small handlers for various tasks are at least as natural to write in a
logic programming language as in C/C++ or BASIC. It would be nice if all
different dialects adopted similar abstractions for these aspects, of
course.
There is also a need for more "success applications", i.e. programs (partly)
written in Prolog, that perform tasks that are accepted as important by
the majority of developers who couldn't care less for theoretical elegance.
The example mentioned sounds like an interesting one.
Apart from this, access to a good development system at a reasonable price
is crucial. You must be able to write programs that can be distributed
without requiring licences for the full development environment.
--
(Alf) Thomas Sjoeland
Internet e-mail: a...@sics.se
Snailmail: SICS, PO Box 1263, S-164 28 KISTA, SWEDEN
Tel: +46 8 752 15 42 Fax: +46 8 751 72 30 Tel home: +46 8 80 44 08
URL: http://www.sics.se/people/thomas-sjoland.html
##
The right to communication is a privilege.
Let's make more people privileged.
Paul Singleton
> I think industry is generally resistant to the idea of using different
> programming languages for different purposes. There is a lot of
> "C chauvinism" (and, earlier, Fortran or assembler chauvinism); that
> is, there are lots of managers (and programmers) who believe that all
> work, of whatever type, should be done in the same programming language.
Is industry resistant to the use of 'lex' or 'yacc'? Does the fact that
these are translated into 'C' help their acceptability? Surely no-one
ever reads or (heaven forbid) hacks the 'C' source which they generate? *
Maybe we can promote Prolog by repackaging its compilers as Prolog-to-C
translators? Even if the 'C' is unintelligible? This may seem a
retrograde step from a Prolog implementation perspective, but ...
I'm aware of at least one Prolog-to-C converter which has been publicised
here recently. Also, Quintus Prolog compiles to linkable .o files: could
it compile to .c files which C compilers would obligingly convert to
suitable .o files? Even if they consisted of a dummy function call and
an initialised array of bytes? Although preferably it would convert to
mega-lines of code so we could demonstrate amazing productivity :-)
* I must own up here to stream-editing 'lex' output to rename some of its
private symbols so that I could link more than one tokeniser into a Unix
executable - this was years ago and no doubt there are better ways of
doing this nowadays.
Paul S.
Richard Pitre
writes:
I wasn't trying to push Prolog or say that it is technically superior to
someone's favorite idea or language or idea. If someone wants to write their
own optimized search mechanism for each application that they write then that
is their business.
I used the words "really available" and "built in" on purpose. In any specific
problem there is always something or some method that is better. If you want to
argue that there are other things out there that are smarter, faster, more
generally applicable, with more supporting educational publications, and better
support etc. then fire away. I would guess that the main general purpose
competitors to Prolog are variants of Prolog with compilers which aren't
completely stupid about the search method and hybrids like Godel.
richard
Richard Pitre
cost I mean development and maintenance $$$ and I mean the cost in bug related
deaths. Once businesses are given a believable cost comparison and government
mandates to stop killing people with expensive junk then the game will be over.
Roger Scowen
mentions
:
> Yes, Herbrand terms are untyped in the sense you mention, but that doesn't
> mean that type errors don't occur, in the sense of calling a procedure
> with a structure with the wrong functor or arity, or calling a procedure
> with an atomic argument when a structure was expected, or vice versa. I
> think these errors are fairly frequent. The problem is that no
> distinction is made among kinds of failure - failure as part of the normal
> execution of the program vs. failure due to incorrect operands - which
> makes them difficult to track down.
distinguishes different kinds of failure and regards some of them as
errors so that such mistakes will be easier to track down and correct.
The definition of each built-in predicate defines a set of error
conditions. If any of them are satisfied, an error occurs which can be
caught by programmers who wish to retain control, but by default
will cause the program to take some implementation dependent action,
probably outputting an error message.
But one of the reasons why it has taken so long to reach a Draft
International Standard has been the need to agree on the precise
error conditions and outcome for every built-in predicate.
Some of the objectives have been:
-- The error conditions should be mutually exclusive, so that the
result of an error is uniquely specified.
-- Too many possible solutions e.g. functor(T, f, N), result in an
instantiation error.
-- An instantiated argument with a type that will cause failure,
e.g. functor(T, f, a) results in a type error.
-- As far as possible, it should be possible for the error conditions
to be checked before execution of the built-in predicate has caused
side effects.
Roger Scowen
ISO/IEC JTC1 SC22 WG17 (Prolog) Convener and Project Editor
Don Ferguson
: By cost I mean development and maintenance $$$ and I mean the cost in bug
: related deaths. Once businesses are given a believable cost comparison and
: government mandates to stop killing people with expensive junk then the
: game will be over.
The game will be over for C++, but that does not mean that Prolog, or
a Prolog-like language will take over. Smalltalk stands a better chance.
One thing Prolog has going for it is that the hardware environments have
finally caught up. With Pentiums and PowerPCs, the desktop hardware finally
has enough speed for Prolog to be practical for commercial applications.
And with GUI's chewing up gobs of memory, Prolog's footprint is not even
a major issue.
Quintus has demonstrated that Prolog can be used to develop and deliver
sophisticated client/server systems on standard hardware, and compete
head-to-head with systems written in C++. Quintus WorkPro, which serves
the Customer Support/Help Desk markets, is a successful product in a highly
competitive market. And Prolog enabled Quintus to develop this product
on a shoestring budget, compared to the well-funded competitors. Yet
Quintus is considering re-writing it all in C++. Why? In part because
Quintus' competitors use the fact that it is written in Prolog to imply
that the technology is wierd, proprietary, and maybe flaky.
So I ask, if success is not enough to justify Prolog, what is? There are
tidal forces that underlie technological shifts, and those forces are
more powerful than logic and reason.
Perhaps I'm jaded. I spent nearly 10 years at Quintus fighting the good
fight, and was the original author of Quintus WorkPro. To see that
technology transform Quintus such that they would reject Prolog for a
'mainstream' technology like C++ must give one pause. If Prolog is to have
a savior, it won't be Quintus.
Don Ferguson
Christian Barmala
of several critical success factors for a language
is the availability of predefined objects, modules,
libraries or what so ever.
It's not enough to have such a nice language as
C++, you need nice class libraries too. Noone
is satisfied with the hint: "In an OO-Language
you can write any classlib you like". I expect
that these libraries are already written.
One of the success factors for Visual Basic
is the availability of numerous VBXes.
So what about Prolog? Are there predefined
"knowledge libraries" available for a
reasonable price, well supported and
standardized?
Christian Barmala
Matthew Huntbach
This doesn't explain why C++ has taken over in a big way. After all, it was
only a few years ago that it was a new language. Prolog is a relatively old
langauge compared to C++.
Matthew Huntbach
Richard Pitre
In the short term we have piston engines. Suppose that you raised this kid so
that he learned all about the principles underlying all modern propulsion
technologies but you never told him what technology actually propelled a car.
The vibrations and the roaring noises interest him but he doesn't get to peek.
So he reaches the end of his training and you take him for a tour underneath
the hood of a modern automobile. He would start to laugh when you explained how
all of the moving parts work together at many thousand rpm's and when you
explained how much horsepower this crazy Rube Goldberg contraption produces he
would fall on the floor holding his stomach. When you finally laid it on him
that there are four valves per cylinder he would actually die laughing(I mean
like you would have to bury the little fucker).
Life will catch up with this infernal combustion insanity but only after our
nation is covered in concrete, we have killed a few zillion people over oil,
and we are all impoverished by car payments. Its really hilarious when you
think about it. I really love my car.
richard
Roger Scowen
clarified:
> [...] What I had in mind was a global
> structural analysis to make sure that the arguments of a call were in some
> sense compatible with the called procedure's arguments. A good deal of
> this could be done without any additional input from the programmer, but
> it would be even more effective with some programmer-supplied data.
The Draft International Standard for Prolog (ISO/IEC DIS 13211-1)
should make this more practicable. By default a procedure is `static',
i.e. its clauses cannot be changed during execution, nor can it be
abolished and replaced completely. Further, clause 5.5.5 states:
A processor may support one or more additional directives
(7.4.2) as an implementation specific feature.
So it will be possible for a standard-conforming Prolog compiler to
perform compile time analysis, checking and optimization on all goals
which call only static procedures, and for implementers to provide
additional directives which permit even better checks.
Roger Scowen ISO/IEC JTC1 SC22 WG17 (Prolog) Convener and project editor
Roland Karlsson
> This doesn't explain why C++ has taken over in a big way. After all,
> it was only a few years ago that it was a new language. Prolog is a
> relatively old langauge compared to C++.
The reason why C++ became so popular is that it was supposed to be
just an object extension to C, and there are lots of C programmer out
there, and objects that's what we need - right?. Unfortunately, C++
is just an ugly kludge that introduces more problems than it solves.
But it is unclear if that will stop this C++ nonsense. Only the
future will tell.
--
-----------------------------------------------------------------------------
Roland Karlsson Inet: rol...@sics.se Telex: 812 6154 7011 SICS
SICS, PO Box 1263, Tel: +46 8 752 15 40 Ttx: 2401-812 6154 7011=SICS
S-164 28 KISTA, SWEDEN Fax: +46 8 751 72 30
-----------------------------------------------------------------------------
Fernando Pereira
In article <3atq9b$550@deneb>, e...@mda.ca (Eric Hawthorne) writes:
> |> Personally, I don't care whether my type error shows up at
> |> run-time or compile time. It's all the same to me if I have
> |> an effective debugging environment.
> There is an important difference between detecting a given type of error at run
> time or at compile time. In the latter case, all errors are detected when you
> compile. In the former case, you detect only the errors that happen in
> executed code. Thus it is very likely that you will miss some, unless you have
> an exhaustive set of test cases.
Exactly. Or put more harshly: with compile-time type checking, you
find the error. With runtime type-checking (or no type-checking) your
customers do. I don't need to elaborate on which one is better for
your reputation and for development costs ove the program's lifetime.
As for the standard counterargument "I'm writing this for myself
only". Most programs worth writing are worth sharing with others, or
at least keeping for one's own use later. Thus every program worth
writing has customers, if only oneself later on, when the details of
the program's innards have been forgotten and thus fixing the runtime
error becomes much more expensive.
--
Fernando Pereira
2D-447, AT&T Bell Laboratories
600 Mountain Ave, PO Box 636
Murray Hill, NJ 07974-0636
per...@research.att.com
Alexander Bottema
> errors that a type system would have detected and this has nothing to
> do with Prolog using Herbrand terms. A lot of (in my experience)
> common errors (eg: mis-spelled constant, functor and predicate names,
> missing arguments in predicates, predicates with arguments in wrong
> order etc) would be detected by a type-checker at *compile-time*
> rather than spending hours tracing through program execution.
True, but much of that could be done without the need of a type
system, e.g. by using data flow analysis.
> I was convinced of the advantages of a typed logic programming
> language when I started using Goedel. I have written some very large
> programs in Goedel and I would estimate that at least 80% of the
> errors I made when writing them were detected at compile-time by the
> type-checker. Of course, I may simply be a very bad typist but I now
> find untyped Prolog vastly inferior by comparison.
Yes, I know what Goedel is and I have used it myself. It is an
interesting approach.
> Obviously this is not the only possible type system for logic
> programming but it's pretty good. Developing a type system for
> logic programming languages *is* trivial if someone else has already
> done it.
This is exactly what I mean that it isn't trivial; there are several
alternatives that one may choose amongst. Goedel has an interesting
approach, but there are so many extensions to the original logic
programming concept (since Kowalski). Lambda Prolog is another such
example.
All these extensions are interesting but they need future work before
they really become efficient. The WAM needs to be modified and THAT
isn't trivial since WAM was made with many optimizations in mind. It
takes a lot of research before one can know that the outcome of the
changes leads to a fast implementation.
Finally, I would like to add that I'm one of those plain students here
at the university; hence my limited knowledge of the current research
in these areas. So, I'm sorry if I'm simply wrong :-)
Roger Scowen
Scowen) wrote:
R> The Draft International Standard for Prolog (ISO/IEC DIS 13211-1)
R> distinguishes different kinds of failure and regards some of them as
R> errors so that such mistakes will be easier to track down and correct.
R>
R> The definition of each built-in predicate defines a set of error
R> conditions. If any of them are satisfied, an error occurs which can be
R> caught by programmers who wish to retain control, but by default
R> will cause the program to take some implementation dependent action,
R> probably outputting an error message.
Wayne Citrin (Mon, 21 Nov 1994 13:46:24 -0700) commented:
W> This is good. A next step would be for the user to be able to define
W> error conditions for user-defined predicates.
Users can define their own error conditions by making the tests,
and then calling
throw(E)
where E is an appropriate term identifying the error.
For example, with the normal definition of reverse/2, a goal
reverse(X, [1,2])
will go into a loop. By adding a clause to its definition, the programmer
can make such cases give an instantiation error.
I append an example, showing the before and after effects using SICStus.
Roger Scowen
----------------------------------------
(1.1) THE NORMAL DEFINITION OF reverse/2.
% reverse(L1, L2) is true if 'L1' is a list, and
% 'L2' unifies with a list identical to 'L1'
% except that the elements occur in opposite order.
reverse(XYZ, ZYX) :-
reverse(XYZ, [], ZYX).
reverse([X | YZ], Acc, ZYX) :-
reverse(YZ, [X | Acc], ZYX).
reverse([], ZYX, ZYX).
(1.2) TESTING IT USING SICStus
pear% sicstus
SICStus 2.1 #9: Fri Jun 3 16:07:05 BST 1994
| ?- consult(temp).
{consulting /annex/users/rss/da/temp...}
{/annex/users/rss/da/temp consulted, 10 msec 800 bytes}
yes
| ?- reverse(X, [1,2]).
^C
Prolog interruption (h for help)? ab
{Execution aborted}
| ?- halt.
(2.1) THE ERROR CHECKING VERSION OF reverse/2.
% reverse(L1, L2) is true if 'L1' is a list, and
% 'L2' unifies with a list identical to 'L1'
% except that the elements occur in opposite order.
reverse(X, _) :-
var(X),
throw(error(instantiation_error, ' argument 1 of reverse/2')).
reverse(XYZ, ZYX) :-
reverse(XYZ, [], ZYX).
reverse([X | YZ], Acc, ZYX) :-
reverse(YZ, [X | Acc], ZYX).
reverse([], ZYX, ZYX).
% throw(Ball) is defined in the Prolog standard (7.8.10).
% it can be simulated (approximately) in SICStus as follows:
throw(Ball) :-
raise_exception(Ball).
(2.2) TESTING IT USING SICStus
pear% sicstus
SICStus 2.1 #9: Fri Jun 3 16:07:05 BST 1994
| ?- consult(temp).
{consulting /annex/users/rss/da/temp...}
{/annex/users/rss/da/temp consulted, 30 msec 1168 bytes}
yes
| ?- reverse(X, [1,2]).
{ERROR: error(instantiation_error,' argument 1 of reverse/2')}
| ?- reverse([1,2], X).
X = [2,1] ?
yes
| ?- halt.
-------------------------- end of example -----------------
Jean-Francois Puget
|>
|> Personally, I don't care whether my type error shows up at
|> run-time or compile time. It's all the same to me if I have
|> an effective debugging environment.
|>
|>
There is an important difference between detecting a given type of error at run
time or at compile time. In the latter case, all errors are detected when you
compile. In the former case, you detect only the errors that happen in
executed code. Thus it is very likely that you will miss some, unless you have
an exhaustive set of test cases.
--
Jean-Francois Puget net : pu...@ilog.fr
ILOG S.A. url : http://www.ilog.fr
2 Avenue Gallieni - BP 85 tel : +33 1 46 63 66 66
F-94253 Gentilly Cedex FRANCE fax : +33 1 46 63 15 82
Eric Hawthorne
: > Second, it isn't trivial to develop a type system for Prolog (or for
: > logic programming languages). What is the type of a predicate? In
: > functional languages the type inference mechanism is obvious; the type
: > is simply derived from its components.
In my interpretation of prolog (and logical theorem-provers in general)
a predicate IS a type (is an intensional and/or extensional definition
of a set etc.).
Axioms involving the predicate are the rules to which members of the
type must conform.
You want that checked at compile time? Good luck. Some common
mistakes could be checked, and we could have a shorthand for
simple typing predicates which apply to single arguments, and
do some compile-time inference on those.
Wayne Citrin
> distinguishes different kinds of failure and regards some of them as
> errors so that such mistakes will be easier to track down and correct.
>
> The definition of each built-in predicate defines a set of error
> conditions. If any of them are satisfied, an error occurs which can be
> caught by programmers who wish to retain control, but by default
> will cause the program to take some implementation dependent action,
> probably outputting an error message.
>
This is good. A next step would be for the user to be able to define
error conditions for user-defined predicates.
Wayne
--
Wayne Citrin cit...@soglio.colorado.edu cit...@cs.colorado.edu
Saumya K. Debray
Alexander Bottema <d91...@Ankara.meryl.csd.uu.se> wrote:
>However, one possible extension would be to introduce contraints on
>Prolog variables. Perhaps you would like this notation:
>
> p(X:[int],Y:[int],Z:[int]) :- ... X ... Y ... Z ...
>
>But this is the same as writing:
>
> p(X,Y,Z) :- integer(X), integer(Y), integer(Z), ... X ... Y ... Z
>
>And a good Prolog compiler with global data flow analysis would of
>course optimize calls to this predicate by skipping the integer
>predicates if X, Y and Z are known to be integers before the call,
Actually, you don't need global dataflow analysis for this
optimization: when you encounter a call to p/3 where argument types
are known, it's straightforward to simply redirect the call to skip
the tests at entry to p/3. In other words, p/3 has multiple entry
points, and each call enters at the appropriate point. This is the
basic idea in "call forwarding", an optimization described in a paper
we had in POPL-94. A simple variant of this idea is used in our Janus
compiler and produces pretty good performance improvements.
One can get much of the effects of call forwarding even in
implementations that compile a clause at a time, since one can get a
lot of mileage in practice simply by optimizing deeply nested loops
(tail-recursive clauses). Our experience has been that a lot of the
time these tend to be fairly small, and one can get a lot of
information from local type analysis: for example, in code of the form
p(X, ...) :- integer(X), ..., X1 is X-1, p(X1, ...)
knowing that X is an integer when the body is executed [else the
integer/1 test would fail], it's easy to infer that X1 must be an
integer as well, allowing the recursive call to skip the integer/1
test. This effectively "hoists" the integer/1 test out of the loop
(though call forwarding subsumes traditional invariant code motion out
of loops, since it works for arbitrary recursion and can handle
"partially invariant" code).
--
Saumya Debray
Dept. of Computer Science, University of Arizona, Tucson
deb...@cs.arizona.edu
Peter Ludemann
Paul Singleton <pa...@cs.keele.ac.uk> wrote:
>Is industry resistant to the use of 'lex' or 'yacc'? Does the fact that
>these are translated into 'C' help their acceptability? Surely no-one
>ever reads or (heaven forbid) hacks the 'C' source which they generate? *
Having just written some code using yacc/lex (actually, bison/flex),
and being a big fan of DCGs, here are a few thoughts:
- yacc is blindingly fast (I remember when compiler-compilers took several
minutes for a simple grammar; bison took 1.6 seconds on my 486/66 for a
grammar with 353 rules (yacc was 2.6 seconds). Flex was fast, too
(under a second). Of course, the compilation steps were slower
... about 12-16 seconds, depending on optimization level for the
parser and 5.5-10 seconds for the lexical analyzer. So, I could edit
my grammar and do a complete rebuild in about 30 seconds. Not as fast
as Prolog, but still, not bad.
- The resulting compiler was fast enough (> 4000 lines/sec.). I suspect
that a DCG-written compiler would have been faster, but I'm not sure.
- The compiler executable was 78K.
- yacc could handle left recursion in grammar rules. This was easy
for me to handle it would have been difficult for somebody who hasn't
spent his youth doing grammar transformations. On the other hand,
understanding the "shift/reduce conflict" messages isn't easy for
beginners.
- Once yacc stopped complaining about the grammar, I knew it was
unambiguous. If I had written a DCG parser, I wouldn't have had
such an assurance.
- I got cc (actually gcc and g++) and yacc/lex (also bison/flex) free
on my machine.
Up to this point (the parser simply produces a modified syntax tree),
I would estimate that yacc/lex programming was about 50% more time
than using DCGs, mainly because of the extra typing I had to do in C
(I also wrote a trivial memory allocator and pretty-printer in C).
For the next step of optimization and code generation, Prolog would be
at least 2-3 times more productive, probably more. But, if I were a
conventional programmer, I would already be "hooked" on the yacc/lex/C
paradigm and wouldn't even think of using Prolog. [Ironic aside: in
today's newspaper there was an article on how VLIW design could
dominate in a few years ... the major book on this (the "Bulldog"
compiler) has about 2 pages explaining why Lisp should be used for
developing such as complex compiler.]
So, to summarize, the apparent advantages of using yacc/lex/C were:
- readily available tool that generated C (free, in this case).
- good enough productivity at the beginning (getting me "hooked").
- lots of people have already done it this way, and there's lots
of documentation (even if it's not all correct).
- I can easily distribute the resulting code (if I had used Prolog,
I would have had to package it up with an existing "free" Prolog
distribution, such as SWI-Prolog).
Would Prolog be more acceptable if there were an LALR(1) parser
generator packaged with it? I don't know. But it wouldn't hurt.
BTW, if anybody wants to rewrite my parser in Prolog, I can provide
the source. Just send me a note (lude...@netcom.com).
--
Peter Ludemann lude...@netcom.com
Michel BILLAUD
: This doesn't explain why C++ has taken over in a big way. After all, it was
: only a few years ago that it was a new language.
C++ is , in a first approximation, C plus something : that is a language
that (apparently) requires an average C programmer much less effort than
the "all recursive all backtracking" way of Prolog programming.
: Prolog is a relatively old langauge compared to C++.
And so is Lisp and so on. To far away from good old imperative
languages.
M Billaud
Amzi!
We've got exactly what you want. We can load small programs quickly, you
can easily issue any kind of query (as you can do from the listener) and
get the Prolog variables mapped back to C/C++ or Basic. And the full
system with royalty-free runtime distribution is $298.
Mary Kroening
Thomas Charles CONWAY
>> Why hasn't Prolog Taken over the World?
>
[deletia]
>5. Lack of control over memory allocation. This is a serious one!
I couldn't let this one pass! If Prolog implementations lack good
garbage collectors, then complain to the implementors. Automatic
memory management is one of the biggest strengths of the logic
and functional programming paradigms. A good proportion of the
bugs in C programs (particularly C programs) are memory management
related. In a logic or functional language, the implementor needs
to get it right only once, and then it works for everyone.
I believe there is also research that has demonstrated that the
amortised cost of automatic memory allocation is lower than the
cost of explicit memory management, but I don't know the references.
Thomas
--
Thomas Conway con...@cs.mu.oz.au
AD DEUM ET VINUM
Amzi!
>rol...@sics.se (Roland Karlsson) writes:
>>> Why hasn't Prolog Taken over the World?
>>
> [deletia]
>>5. Lack of control over memory allocation. This is a serious one!
>I couldn't let this one pass! If Prolog implementations lack good
>garbage collectors, then complain to the implementors. Automatic
>memory management is one of the biggest strengths of the logic
>and functional programming paradigms. A good proportion of the
>bugs in C programs (particularly C programs) are memory management
>related. In a logic or functional language, the implementor needs
>to get it right only once, and then it works for everyone.
I don't believe the original reference was about the quality of garbage
collectors, nor bugs in memory management. The issue with many Prolog
systems is that they want to control the memory and then allocate pieces
to you (a C/C++ program). What I think C/C++ programmers want is to
start up a Prolog engine and tell it exactly how much memory to use for
heaps, stacks, code, etc. Then when the C/C++ program shuts down the
Prolog engine, they want it to clean everything up, releasing all the
memory it used.
Anyways our Cogent Prolog does this because we agree with the original
author that Prolog needs to be a well-behaved component of an
application, not an all-encompassing system.