Mainstreaming Prolog a Pragmatic Approach?
Benjamin Johnston
Hello Fellow Prologgers,
I read with interest the recent discussion regarding mainstreaming Prolog.
This has been something on my mind quite a bit lately. I, for one, would
love to see Prolog enter the mainstream. In fact, I'm optimistically hoping
that one day I'll be able to read the job listings in the newspaper and see
at least a handful of positions requiring Prolog or logic programming skills
(okay, okay, at this stage it looks like it probably won't happen, but I'm
hoping...).
So, I'm wondering, are there things that could realistically be done to help
"mainstream Prolog"?
Let us, for the sake of argument, assume that this is something desirable.
And also, that I'm not proposing that Prolog be the next Java, but just that
it becomes considered an essential part of the programmer's toolkit - like
shell/batch scripting, like GUI builders or like a nifty little graphing
library.
Please, I don't want this to deteriorate into a religious war - but what
*constructive* ideas do you have for people like I who want to make Prolog
more credible and popular?
I've some ideas of my own:
- Of course, USING IT, whenever appropriate and whenever I can present a
convincing argument in my job.
- I'd like to set up a website specifically directed to commercial usage of
Prolog, entirely independently of any of the major vendors.
- I'm wondering that maybe an abstraction layer would be helpful - a set of
modules (that differ for each vendor) that sets up a "standard API" that
looks the same - providing a uniform access to the many different module
systems, IO interfaces, GUI interfaces that are available.
- I implemented a "Prolog Server Pages" once that proved to be impressively
powerful (and simple), I'm thinking opening that up when I've got some time
to make it really robust would really be a boost. Maybe also implementing a
Prolog Server Pages interpreter in PHP so that it can be used conveniently
with virtually any web-hosting company.
- I'm wondering that maybe this issue of too many different platforms might
be somewhat alleviated if there was a unified documentation effort (a single
online source that provided explanations, examples, and information about
compatibility for as many known predicates on as many known platforms as
possible).
- Occasionally sponsoring events in the local developer community.
Any thoughts of your own?
My goals are rather long term - I may not get any of these done in the next
12 months; I think a continuous patient effort for many years is what it
might take to bring some of these ideas to reality.
-Benjamin Johnston
Nick Wedd
Johnston <supe...@benjaminjohnston.com.au> writes
>- I implemented a "Prolog Server Pages" once that proved to be impressively
>powerful (and simple), I'm thinking opening that up when I've got some time
>to make it really robust would really be a boost. Maybe also implementing a
>Prolog Server Pages interpreter in PHP so that it can be used conveniently
>with virtually any web-hosting company.
I would really like to be able to run a web site that uses Prolog as its
database. At present I am running one that uses SQL and PHP, and I find
it a right pain.
Nick
--
Nick Wedd ni...@maproom.co.uk
Martin Sondergaard
> > impressively powerful (and simple), I'm thinking opening that up
> > when I've got some time
> > to make it really robust would really be a boost.
That sounds good.
Nick Wedd wrote :
> I would really like to be able to run a web site that uses Prolog as its
> database.
Me too, I'd like to run a website using Prolog too.
I've discovered that CGI and Prolog just don't work together.
For Prolog to be used with a website something new is needed.
I think that SWI Prolog has some predicates in its library that can be used
for this purpose. I think it has an HTML server written in Prolog.
Possibly this can be modified to use a Prolog database and send the data out
as HTML pages.
I haven't tried out this feature of SWI Prolog yet,
but I heard that it has this HTML server.
--
Martin Sondergaard,
London.
Jan Wielemaker
>> > - I implemented a "Prolog Server Pages" once that proved to be
>> > impressively powerful (and simple), I'm thinking opening that up
>> > when I've got some time
>> > to make it really robust would really be a boost.
>
> That sounds good.
>
> Nick Wedd wrote :
>
>> I would really like to be able to run a web site that uses Prolog as its
>> database.
The SWI-Prolog application database (available from the website) runs
in something I also called PSP (obvious name :-). I never published
the code though and I don't think it is in a state where it is worth
publishing :-)
> Me too, I'd like to run a website using Prolog too.
>
> I've discovered that CGI and Prolog just don't work together.
> For Prolog to be used with a website something new is needed.
Why? CGI is often a bit clumsy anyway, but otherwise it runs just
fine. All you need is a predicate to read form data and a library
to produce a web page.
> I think that SWI Prolog has some predicates in its library that can be used
> for this purpose. I think it has an HTML server written in Prolog.
> Possibly this can be modified to use a Prolog database and send the data out
> as HTML pages.
*HTTP* server (which can serve HTML documents). This is quite useful
for many purposes, such as providing an embedded HTTP server in an
application. The web version of the manual of the graphics package
runs on top of one of the variations (an old variation) of this
package.
> I haven't tried out this feature of SWI Prolog yet,
> but I heard that it has this HTML server.
The trouble is often that you need some place to host it. If you run
your own server this problem isn't too hard, though you will often see
yourself forced to use a different port (not 80), wich can cause
problems with firewalls. Nevertheless it sometimes proves to be
a very practical library, especially as you can run the debugger
while the page is requested.
Cheers --- Jan
Paul Singleton
> ...
> So, I'm wondering, are there things that could realistically be done to help
> "mainstream Prolog"?
Random ideas in no significant order:
* learn from how Java has developed: whether they got it
right or wrong (mostly right?) we can learn from it...
* sort out database persistence
* establish some decent and practicable standards for
everything important which is beyond the ISO standard
* make some friends in the real world (bring IBM and other
Prolog users out of the closet)
* standardise embedding in all popular languages (i.e.
Visual Basic and maybe Java ;-)
* get all commercial Prolog vendors to pledge something,
e.g. open sourcing something neat, or complying with
at least some of our API standards
* get a nice logo, like Apache or MySQL, and use it
everywhere
* figure out how to establish a standard library
(see Java above)
* agree what junk Prolog baggage to deprecate
Note that most of our problems are political, not technical
:-/
Paul Singleton
Michael D. Kersey
<snipped>
> - I implemented a "Prolog Server Pages" once that proved to be impressively
> powerful (and simple), I'm thinking opening that up when I've got some time
> to make it really robust would really be a boost. Maybe also implementing a
> Prolog Server Pages interpreter in PHP so that it can be used conveniently
> with virtually any web-hosting company.
And here's yet another "Prolog Server Pages" implementation:
http://conference.iasi.roedu.net/site/conference/papers/SUCIU_A-Prolog_Server_Pages.pdf
or in Google's HTML format:
http://216.239.41.104/search?q=cache:CZQGjuYJzS8J:conference.iasi.roedu.net/site/conference/papers/SUCIU_A-Prolog_Server_Pages.pdf+mod_psp+Prolog&hl=en&ie=UTF-8
Michael D. Kersey
<snipped>
> The SWI-Prolog application database (available from the website) runs
> in something I also called PSP (obvious name :-). I never published
> the code though and I don't think it is in a state where it is worth
> publishing :-)
And here's yet another "Prolog Server Pages" implementation:
Oskar Bartenstein
> database. At present I am running one that uses SQL and PHP, and I find
> it a right pain.
This is done today with ready-made commercial grade components.
Use MINERVA http://www.ifcomputer.co.jp/MINERVA/
in a servlet web server like Tomcat
http://jakarta.apache.org/tomcat/ .
For MINERVA based Prolog server pages, use *.mss , cf
"Software Components for Internet based Self Service Consulting Systems"
linked from
http://www.ifcomputer.co.jp/inap/inap2001/program/Title.html
For illustration, a commercial exploit is http://dialogengines.com
where Prolog is not only the database, but does also the
recommendation expert, drive the pseudo-NPL frontend,
the virtual character agent gestures etc.
Both MINERVA and *.mss are commercial and proprietory.
Oskar Bartenstein os...@ifcomputer.co.jp http://www.ifcomputer.co.jp
Dr Andrew R. Verden
the other discussion points on foreign language interface definition,
where a generic FL interface could be specified.
Assuming your goal is really to make a high level defininition in your
Prolog code as to which routines (predicates) you would like to export
across the foreign language interface to produce an API, DLL, package
or whatever the latest term is for what used to be called a dynamic
linked library.
The obvious way to me seams to place this at the module definition
layer, through module extensions.
For example, of what we have now as module interface definition:
% define the modules which should be loaded
:- ensure_loaded module1.
:- ensure_loaded module2.
% define what the module exports
:- module new.
:- export [predicate/4].
:- end_module new.
% implement the module
:- begin_module new.
:- import module1.
:- import module2.
predicate(A,A,A,A).
:- end_module new.
Separating the module specification from the implementation is useful
to remove dangling module references and allow uses to choose to
include several modules in files or spread the implementation of
modules across files.
If we were to extend the export part of the syntax to include
:- export_fl [predicate/4].
Then that is on the face of it fine, but the arguments need to be
specificed through some kind of type declaration as most FLs are
strongly typed. Before I re-invent wheels has anyone done such a
definition for common languages such as C++, Java, VB, XML. Of course
the Java world would say use auto discovery, but here I am trying to
be more astract and stay in Prolog and an XML view of arguments is
probably more appropriate.
For our own APIs in C++ and Java we built an interface generator which
takes a Prolog type specification of the API interface and generates
the C++ and Java interface code using IF/Prologs own low-level C/Java
interface. Objects and structures are converted to Prolog terms in
both directions, from FL to Prolog and back. The benefit has proven
worthwhile as there are no annoying interface errors and it is easy to
change and maintain. We never though made it clean enough to reach the
module layer of the Prolog system. We also generate Java doc to
describe the API but that is by the by.
I could imagine a Prolog program which parses a Prolog module tree (in
ISO a Prolog text) and builds the propriety interface to a particular
Prolog incarnation using common module specifications for a particular
FL language and spcifications for the Prolog incarnation.
We would be happy that such interface generator and the code to
interface to our Prolog be in the public domain. Vendors would
contribute the implemtations of low level features to pass Objects and
structures into Prolog terms in their systems. The build/compile and
link process would also have to be compatible between say Visual
Studio and UNIX makefiles.
All we need is a champion with time to implement such a interface
generator.... :-)
Martin Sondergaard
> > Me too, I'd like to run a website using Prolog too.
> >
> > I've discovered that CGI and Prolog just don't work together.
> > For Prolog to be used with a website something new is needed.
Jan W replied :
> Why? CGI is often a bit clumsy anyway, but otherwise it runs just
> fine. All you need is a predicate to read form data and a library
> to produce a web page.
The way CGI works is like this.
The user fills in a form in a Web page (an HTML page),
then clicks the Submit button on the page.
The page is sent to a CGI program on the web server.
The CGI program on the web server starts up,
generates an HTML page as a reply, then sends it back to
the browser which sent the web form.
Then the CGI program is shut down.
So every time the user clicks on a Submit button, the CGI program
is started up and shut down.
If the program which is on the webs sever is a Prolog program,
when the user clicks on the Submit button,
the Prolog interpreter starts up, then it loads up the Prolog program,
then it "consults" a Prolog database, all of which takes several seconds.
Only then can it generate a response to send back to the browser.
After it has send the response back to the browser,
the Prolog interpreter is shut down again.
This process is why a Prolog program can be too slow to use with CGI.
Especially if its a large Prolog program, or if it uses a large file of
Prolog facts.
Another problem with this process is this.
If it needs to remember data from the form, the obvious way to remember data
is to assert it as Prolog facts. But if the Prolog interpeter is shut down
and restarted every time the Submit button is clicked,
these prolog facts would be forgotten.
So if the prolog program needs to remember facts, then it needs to
store them in a file, and read them in again.
So ideally I want my Prolog program to remain open all the time,
and it would have to handle multiple CGI calls
without having to exit and restart all the time.
Would I have to use the HTTP server,
to keep the Prolog interpreter open, handling CGI calls?
>
> > I think that SWI Prolog has some predicates in its library that can be
used
> > for this purpose. I think it has an HTML server written in Prolog.
> > Possibly this can be modified to use a Prolog database and send the data
out
> > as HTML pages.
>
> *HTTP* server (which can serve HTML documents). This is quite useful
> for many purposes, such as providing an embedded HTTP server in an
> application. The web version of the manual of the graphics package
> runs on top of one of the variations (an old variation) of this
> package.
>
> > I haven't tried out this feature of SWI Prolog yet,
> > but I heard that it has this HTML server.
>
> The trouble is often that you need some place to host it. If you run
> your own server this problem isn't too hard ...
Yes, a couple of years ago that was a problem, finding a host.
Recently broadband connections to the Internet have become available
at reasonable prices in my country, England.
So I can now get an affordable always-on connection to the internet.
So I expect that I will be able to run a server from home.
Using the SWI Prolog HTML server seems an rather indirect way
of keeping the Prolog interpreter open, to respond to multiple CGI calls,
but I guess I can do it this way.
--
Martin Sondergaard,
London.
Andrzej Lewandowski
<supe...@benjaminjohnston.com.au> wrote:
>
>Hello Fellow Prologgers,
>
>I read with interest the recent discussion regarding mainstreaming Prolog.
>This has been something on my mind quite a bit lately. I, for one, would
>love to see Prolog enter the mainstream. In fact, I'm optimistically hoping
>that one day I'll be able to read the job listings in the newspaper and see
>at least a handful of positions requiring Prolog or logic programming skills
>(okay, okay, at this stage it looks like it probably won't happen, but I'm
>hoping...).
>
>So, I'm wondering, are there things that could realistically be done to help
>"mainstream Prolog"?
>
>Let us, for the sake of argument, assume that this is something desirable.
>And also, that I'm not proposing that Prolog be the next Java, but just that
>it becomes considered an essential part of the programmer's toolkit - like
>shell/batch scripting, like GUI builders or like a nifty little graphing
>library.
This is not the issue. Programmers and their toolboxes don't decide
what languages and technology is used. Prolog (or other language)
becomes "mainstream" when large corporations start using this
language. I don't see why large corporations should use Prolog.
Introducing new language into production environment is very costly
and must be economically justified. The argument that "X is better
language than Y" is not sufficient justification. "Killer
application" will also not help.
Interesting discussion of this issue is in the article by Phillip
Wadler "How Enterprises Use Functional Languages and Why They Don't"
in "The Logic Programming Paradigm: A 25 Year Perspective", by
Krzysztof Apt and others (this article was published, as I recall,
in SIGPLAN, and is available on Wadler's web page).
Yes, I am using Prolog in production environment, but this was more
by accident than by making educated choice, and using Prolog creates
more troubles than fun.
In other words, I think that Prolog has no chance to be a
"mainstream" language. It is a "niche language", sitting in the
"niche" in good companion of Lisp, Ada, Eiffel, Smalltalk and such.
A.L.
Cesar Rabak
[snipped]
>
> The way CGI works is like this.
>
> The user fills in a form in a Web page (an HTML page),
> then clicks the Submit button on the page.
> The page is sent to a CGI program on the web server.
> The CGI program on the web server starts up,
> generates an HTML page as a reply, then sends it back to
> the browser which sent the web form.
> Then the CGI program is shut down.
>
> So every time the user clicks on a Submit button, the CGI program
> is started up and shut down.
>
> If the program which is on the webs sever is a Prolog program,
> when the user clicks on the Submit button,
> the Prolog interpreter starts up, then it loads up the Prolog program,
> then it "consults" a Prolog database, all of which takes several seconds.
For this to work you'll need to have the Prolog program to be considered
executable in the platform the Web server runs (perhaps with the
sheebang trick), so isn't it more simple just compile the Prolog program
in a native executable anyway?
AFAICT Prolog programs will always be more or less platform/compiler
dependent so leaving them as 'scripts' has not many advantages.
Do you agree?
--
Cesar Rabak
Benjamin Johnston
Okay, I'd be interested in your opinions on syntax of PSP...
%%%%%%%%%%%%%%%
I am now aware of four syntaxes:
- Suciu and Pusztai
- My own
- Jan Wielemaker from SWI-Prolog (I haven't seen this code, however)
- MINERVA Prolog, has MSS (but I can't find what that stands for)
%%%%%%%%%%%%%%%
% Suciu and Pusztai
%%%%%%%%%%%%%%%
Suciu and Pusztai,
http://conference.iasi.roedu.net/site/conference/papers/SUCIU_A-Prolog_Serve
r_Pages.pdf
used a syntax like this:
<html>
<head><title>Hello World example</title></head>
<body>
<?psp
msg('Hello, World!').
?- msg(X),write(X).
?>
</body>
</html>
I quite like this because it allows clauses to be defined, and queries
submitted in the one document. Furthermore, if a query fails, it does not
cause the entire page to "fail". On the downside, however, it doesn't really
look like it allows the programmer to directly mix the Prolog and HTML.
%%%%%%%%%%%%%%%
% My own
%%%%%%%%%%%%%%%
I experimented with many possibilities, but in my work I settled on the idea
that a PSP page is a query. So I had code like this:
<html>
<head><title>Hello World example</title>
</head>
<body>
<?, X is 3 + 2, ?>
Hi, the sum of 3 and 2 comes to <?= X ?>
The members of my family are:<br>
<?, forall(
member(Person, ['ben','michael','sue','graham']),
?> <b><?= Person?></b><br> <?
),?>
</pre>
</body>
</html>
In other words, each PSP page was a single query - the parser basically just
replaced the HTML sections with writes, so that:
hello <?, X=1, ?> X is equal to <?= X ?>
would be translated into the following query,
write('hello '), X = 1, (write('X is equal to'), write(X)).
Predicates could be defined by the user because every .pl file in the
current directory was automatically consulted on the webserver startup.
The thing that I like about my approach is that it quite easy and natural to
produce fairly complex page layouts -- and that it works in a way that is
very similar to the other server-pages technologies. The downside is that
there is a greater need to be careful about coping with failure - because if
a particular subclause fails then the bottom of the page is likely to be
chopped off. I don't think this is too big a deal, however, because this is
exactly the same issue that you need to consider when writing any old Prolog
predicate. Use of things that always succeed (such as forall) also prevent
that from happenning. Another downside is that predicates cannot be defined
in-line --- however, I don't see any reason that I couldn't extend the
syntax to include a <?prolog ?> or <?psp ?> tag that allows predicates to be
defined.
%%%%%%%%%%%%%%%
% Jan Wielemaker
%%%%%%%%%%%%%%%
As far as I can tell, Jan's code is not available.
%%%%%%%%%%%%%%%
% MINERVA
%%%%%%%%%%%%%%%
I could only find one sample .mss file in the MINERVA evaluation (I can't
seem to find any online discussion of it, or mention of it in the
documentation). But, the basic idea appears to be that you write something
like a Java servlet in Prolog. It appears that MINERVA also has a special
syntax to simplify development.
I don't want to quote MINVERA's sample file in full -- you can download a
free trial edition if you're interested. But, it looks like an .mss file
consists of the following parts:
<%!
a set of prolog predicates to define how to respond to a particular query --
specifically taking POST/GET requests, and then appropriately "invoking" the
next "function" to handle it.
in this case we might have an clause that says (sample copied directly from
MINVERA's file):
select_method(_, Request, Response) :- !,
response_setContentType(Response, 'text/html'),
response_getWriter(Response, Writer),
request_getContentType(Request, ContentType),
show_error(Writer, ContentType).
%>
<%@ function show_error(ContentType) %>
<html>
some html content can go here
</html>
<% end %>
<%@ function show_content(Request, MultipartRequest) %>
<html>
<body>
<%@ include show_data(Request) %>
<%@ include show_parts(MultipartRequest) %>
</body>
</html>
<% end %>
<%@ function show_data(Request) %>
here's an in-line display: <%= request_getMethod(Request) %><br>
<% end %>
<%@ function show_parts(Request) %>
<% loop multipart_element(Request, Element) %>
<%@ include show_element(Request, Element) %>
<% end %>
<% end %>
and so on...
The advantage of this format, appears to be first and foremost a closer
relationship to the underlying mechanisms themselves. It appears to be more
like what Java Servlets are to Java, but for Prolog. Of course, the downside
is that it looks like a lot of effort if all you really want to do is
produce a simple website from a bit of Prolog.
%%%%%%%%%%%%%%%
I think I prefer my single query technique, but I like the way that Suciu
and Pusztai allowed for predicates to be defined within the file. Maybe the
hybrid approach with <?prolog ?> or <?psp ?> defining the compile-time tasks
(that cannot generate input) and the single query approach is the best
combination.
Any thoughts?
-Benjamin Johnston
Benjamin Johnston
I have read Philip Wadler's paper, but not for a long time - and I can't
seem to find it online.
"Mainstreaming" may not have been the best word. I would say that Perl, PHP
and Python are mainstream. I want to see Prolog like that.
PHP is a language that is completely inappropriate for large scale
development, however its still got a large following because its a great way
to put together a simple dynamic website. I'd like to see Prolog have the
same kind of recognition and familiarity as PHP and Python. Sure, it will
probably never become more than niche, but I'd like to see the niche large
enough so that it gets consideration in those situations where it would be
the perfect fit (rather than missing out on showing its colors just because
nobody even considered it) and where there is an exciting user base that
isn't primarily dominated by research.
In this case i hope I'm talking about something outside of the control of
large organizations. Everybody's got their pet tools to get things done when
they need to do a little bit of coding outside of the core software
developments - prototyping, file transformation, quick web scripting, etc.
These are the things that I often find Prolog perfect for.
-Benjamin Johnston
"Andrzej Lewandowski" <alewando_tego_nie@oddpost_tego_tez_nie.com> wrote in
message news:tdkm50l60haeosuui...@4ax.com...
Benjamin Johnston
Oh, sorry... I just noticed the post from Oskar Bartenstein, in which we
were referred to the following document that explained MINERVA's syntax:
http://www.ifcomputer.co.jp/inap/inap2001/program/inap_bartenstein.ps
I take back my comment about it being low level (apparently the first
section isn't necessary) -- however, in my opinion, it doesn't really look
like Prolog programming.
But, on the other hand, none of the methods that I have seen or suggested
really allow for the possibility of writing webpages in a recursive manner
(with the exception of MINERVA - to a certain extent).
-Benjamin Johnston
"Benjamin Johnston" <supe...@benjaminjohnston.com.au> wrote in message
news:405bcb31$0$22512$5a62...@freenews.iinet.net.au...
billh
Someone else in this thread suggested it would be a good idea if
Prolog emulated some of the things that the Java people got right. The
main thing I think the Java people got right was to use the
p-Pascal/p-machine approach based on relatively easy-to-port virtual
machine and a self-compiling compiler that produces machine code that
runs in that VM.
I would like to see Prolog do the same.
--
Jan Wielemaker
You can avoid part of the problem by compiling the program so it starts
quicker as someone else remarked. Start time, as you indicate, is only
one of the problems. The most sensible solution is to have a Prolog system
acting as a server that stays alive (like your database engine) and have
a simple CGI client contacting this server for fast startup. This isn't
hard to program. It also allows you to place the `server' on a different
host.
> Using the SWI Prolog HTML server seems an rather indirect way
> of keeping the Prolog interpreter open, to respond to multiple CGI calls,
> but I guess I can do it this way.
You can yes, but for most situations I'd go the way described above.
Using Prolog directly probably provides better performance, so it that
is an issue I'd go that way.
Cheers --- Jan
Jan Wielemaker
Benjamin Johnston wrote:
>> - Jan Wielemaker from SWI-Prolog (I haven't seen this code, however)
Basically the page provides
<script language=prolog>
(prolog sourcecode)
</script>
and
<?Goal>
where the output of Goal is replaces the programming instruction. Nothing
fancy. Just wrote it for the fun of it and gave it the obvious name. It
isn't public, though if someone wants to have the code, just contact me.
Don't ask me questions about it though :-)
Cheers --- Jan
Martin Sondergaard
> > So ideally I want my Prolog program to remain open all the time,
> > and it would have to handle multiple CGI calls
> > without having to exit and restart all the time.
> >
> > Would I have to use the HTTP server,
> > to keep the Prolog interpreter open, handling CGI calls?
Jan W. answered :
> You can avoid part of the problem by compiling the program so it starts
> quicker as someone else remarked. Start time, as you indicate, is only
> one of the problems. The most sensible solution is to have a Prolog
> system acting as a server that stays alive (like your database engine)
> and have
> a simple CGI client contacting this server for fast startup. This isn't
> hard to program. It also allows you to place the `server' on a different
> host.
>
> > Using the SWI Prolog HTML server seems an rather indirect way
> > of keeping the Prolog interpreter open, to respond to multiple CGI
> > calls, but I guess I can do it this way.
>
> You can yes, but for most situations I'd go the way described above.
> Using Prolog directly probably provides better performance, so it that
> is an issue I'd go that way.
>
> Cheers --- Jan
Thank you Jan.
I can write a CGI client in Prolog, which uses DDE to communicate with
the permanently open Prolog program.
I already know something about DDE, so I don't have to spend too much time
learning new programming methods.
As to how I can find a web host on which to run these Prolog programs,
I expect that I can use Apache on my home PC, so I can host it myself.
I just hope that Apache lets me run a program that stays open permanently.
If Apache assumes that all programs are CGI programs,
which need to be shut down if they don't exit by themselves,
that would be a problem.
--
Martin Sondergaard.
Jan Wielemaker
Martin Sondergaard wrote:
> I wrote :
>
>> > So ideally I want my Prolog program to remain open all the time,
>> > and it would have to handle multiple CGI calls
>> > without having to exit and restart all the time.
>> >
>> > Would I have to use the HTTP server,
>> > to keep the Prolog interpreter open, handling CGI calls?
>
> Jan W. answered :
>
>> You can avoid part of the problem by compiling the program so it starts
>> quicker as someone else remarked. Start time, as you indicate, is only
>> one of the problems. The most sensible solution is to have a Prolog
>> system acting as a server that stays alive (like your database engine)
>> and have
>> a simple CGI client contacting this server for fast startup. This isn't
>> hard to program. It also allows you to place the `server' on a different
>> host.
>>
> the permanently open Prolog program.
I won't go for DDE. It is a proprietary and clumsy way to handle this.
Simply make the server open an TCP/IP socket. It is really simple,
especially if server and clients are both Prolog and thus can use
Prolog read/write to exchange terms.
> I already know something about DDE, so I don't have to spend too much time
> learning new programming methods.
>
> As to how I can find a web host on which to run these Prolog programs,
> I expect that I can use Apache on my home PC, so I can host it myself.
This is no problem
> I just hope that Apache lets me run a program that stays open permanently.
> If Apache assumes that all programs are CGI programs,
> which need to be shut down if they don't exit by themselves,
> that would be a problem.
You should start the server seperately or use the a bit hacky way to
make the small CGI script check for the existence of the server and
start one if it doesn't exist. Not really easy if you don't want the
theoretical possibility to have two of them.
Cheers
--- Jan
Michael D. Kersey
<snipped>
> If the program which is on the webs sever is a Prolog program,
> when the user clicks on the Submit button,
> the Prolog interpreter starts up, then it loads up the Prolog program,
> then it "consults" a Prolog database, all of which takes several seconds.
> Only then can it generate a response to send back to the browser.
> After it has send the response back to the browser,
> the Prolog interpreter is shut down again.
>
> This process is why a Prolog program can be too slow to use with CGI.
> Especially if its a large Prolog program, or if it uses a large file of
> Prolog facts.
>
> Another problem with this process is this.
> If it needs to remember data from the form, the obvious way to remember data
> is to assert it as Prolog facts. But if the Prolog interpeter is shut down
> and restarted every time the Submit button is clicked,
> these prolog facts would be forgotten.
> So if the prolog program needs to remember facts, then it needs to
> store them in a file, and read them in again.
>
> So ideally I want my Prolog program to remain open all the time,
> and it would have to handle multiple CGI calls
> without having to exit and restart all the time.
>
> Would I have to use the HTTP server,
> to keep the Prolog interpreter open, handling CGI calls?
The developers of Ciao Prolog anticipated these problems during their
development of the PiLLoW library ("Programming in Logic Languages on
the Web") which is discussed in the article:
"The PiLLoW/CIAO Library for INTERNET/WWW Programming using
computational Logic Systems" by Daniel Cabeza, Manuel Hermenegildo, &
Sacha Varmaa and located at
http://clip.dia.fi.upm.es/lpnet/lp-internet/pillow/lpnet3.html
In particular, the section titled "10. A High-Level Model of
client-Server Interaction: Active Modules" of that article addresses
your concerns.
Ciao Prolog includes libraries that implement Active Modules. The Ciao
Reference manual describes Active Modules at
http://clip.dia.fi.upm.es/Software/Ciao/ciao_html/ciao_101.html#SEC385
The CLIP Lab website:
http://clip.dia.fi.upm.es/
Ciao Prolog:
http://clip.dia.fi.upm.es/Software/Ciao/index.html#ciao
The Ciao Reference manual:
http://clip.dia.fi.upm.es/Software/Ciao/ciao_html/ciao_toc.html
Active Modules in Ciao Prolog:
http://clip.dia.fi.upm.es/Software/Ciao/ciao_html/ciao_101.html#SEC385
Paul Singleton
> Someone else in this thread suggested it would be a good idea if
> Prolog emulated some of the things that the Java people got right. The
> main thing I think the Java people got right was to use the
> p-Pascal/p-machine approach based on relatively easy-to-port virtual
> machine and a self-compiling compiler that produces machine code that
> runs in that VM.
I think they got a lot more than just this right...
But now that the JVM is so well established,
should we introduce a new "PVM" for Prolog, or
use the JVM?
If we use the JVM, isn't it smarter to compile
Prolog to Java *source* code so as to leverage
all the good work that (free) Java compilers can
do for us (inc. linking to Java)
Prolog Cafe already does this, but it hasn't
exactly set the world on fire.
It's all rather puzzling...
Paul Singleton
no-spam
> billh wrote:
>
>> Someone else in this thread suggested it would be a good idea if
>> Prolog emulated some of the things that the Java people got right.
>> The main thing I think the Java people got right was to use the
>> p-Pascal/p-machine approach based on relatively easy-to-port virtual
>> machine and a self-compiling compiler that produces machine code that
>> runs in that VM.
>
>
> I think they got a lot more than just this right...
>
I did not say that adopting the p-Pascal/p-machine approach was the
only thing the Java people got right; I said I thought it was the main
thing they got right, by which I meant that, in terms of its commercial
success, I do not think Java would have gone as far as it did as fast as
it did if they had not adopted that strategy.
> But now that the JVM is so well established,
> should we introduce a new "PVM" for Prolog, or
> use the JVM?
>
If you agree that the Java/JVM development strategy contributed in
any significant measure to the commercial success of Java in the 1990s
then, yes, I think you should consider the possibility that a Prolog/PVM
development strategy might do the same for a rejuvenated Prolog in the
decade ahead.
What would it be like to have a PVM on a par with the JVM and to be
able to buy books with titles like "Generating Bytecode for The Prolog
Virtual Machine"? Where does that idea lead? Does anyone know? Has
anyone been there?
I would love to see a Prolog counterpart to Wirth's "Algorithms +
Data Structures = Programs": a PVM and a p-Prolog-to-PVM compiler
written out in p-Prolog would open a lot a doors for a lot of students,
and I would be very much surprised if it did not lead in a perfectly
natural way to the notion of Prolog as a kind of generalized
block-structured Pascal for nondeterministic stepwise-imperative machines.
Ultimately, it's a question of energy and imagination, and I believe
that the hallmark of a good development model is that it unleashes both.
billh
--
<sequitur AT sonic DOT net>
Bart Demoen
> I would love to see a Prolog counterpart to Wirth's "Algorithms +
> Data Structures = Programs": a PVM and a p-Prolog-to-PVM compiler
> written out in p-Prolog would open a lot a doors for a lot of students,
Maybe I have missed something important in this discussion - but I was
a bit baffled from the beginning I must say: the PVM is usually named
the WAM and it exists since at least 20 years. There are many compilers from
Prolog to the WAM written in Prolog, in commercial systems (SICStus Prolog),
as well as in more open source systems (GNU-Prolog, XSB ...).
So you can find Prolog2WAM compilers for free in many places.
In cases the WAM is used for emulation (as opposed to JIT compilation),
the systems are relatively esay to port to many platforms.
Of course, all use their own refinement of the WAM.
So my question is:
is this thread mainly suggesting that the WAM should be standardized ?
Cheers
Bart Demoen
Matthew Huntbach
> What would it be like to have a PVM on a par with the JVM and to be
> able to buy books with titles like "Generating Bytecode for The Prolog
> Virtual Machine"? Where does that idea lead? Does anyone know? Has
> anyone been there?
The standard way of implementing Prolog is, and has been for a very long
time, through a well-understood virtual machine, the WAM.
> I would love to see a Prolog counterpart to Wirth's "Algorithms +
> Data Structures = Programs": a PVM and a p-Prolog-to-PVM compiler
> written out in p-Prolog would open a lot a doors for a lot of students,
> and I would be very much surprised if it did not lead in a perfectly
> natural way to the notion of Prolog as a kind of generalized
> block-structured Pascal for nondeterministic stepwise-imperative machines.
>
> Ultimately, it's a question of energy and imagination, and I believe
> that the hallmark of a good development model is that it unleashes both.
Prolog has existed for a very long time (about 30 years), has had a
lot of energetic and imaginative people working on it, has been
very widely taught to students, and has had quite a few major textbooks
written for it. If it was just a matter of the right textbook coming onto
the market for Prolog to hit the "mainstream" that would have happened by
now. While Prolog has pottered along, other languages - I'm thinking of
things like Perl and PHP - have taken off in a big way without anything like
the sort of support that Prolog has had. So I think we have to accept that
Prolog isn't going to hit the big time, for reasons instrinsic to Prolog
itself.
I think Prolog suffers from a lack of structure, meaning that large
programs become very verbose and hard to follow. Also, while it's often
sold as some soiphisticated "look, it works like magic" language,
actually its search-through-backtracking mechanism is very crude, useful
for a few little tricks, but not something that is easily scaled up. If you
want to do serious search or constraint satisfaction stuff, you don't use
Prolog (or if you do use Prolog, you don't use its built-in search).
The only niche I can see Prolog fitting into is the one that SQL already
fits in nicely, and I don't see Prolog forcing out SQL.
I think there are things we can take from Prolog and move on, so I don't
think logic programming itself is a dead end. But I see Prolog as a nice
toy language, that for a while was over-hyped.
Matthew Huntbach
Torkel Franzen
> If you
> want to do serious search or constraint satisfaction stuff, you don't use
> Prolog (or if you do use Prolog, you don't use its built-in search).
I don't quite understand the content of the above observation.
> But I see Prolog as a nice toy language, that for a while was over-hyped.
What is the technical meaning of "toy language"?
I seem to remember that you've commented from time to time on Prolog
being over-hyped. Sure it's been over-hyped, but so has democracy,
relativity theory, and sliced bread. I doubt that any of our favorite
languages - Prolog, Mercury, Haskell, Oz, other nice things - will
ever be a huge mainstream success. That doesn't detract from their
usefulness.
Matthew Huntbach
> Matthew Huntbach <m...@dcs.qmw.ac.uk> writes:
>> If you
>> want to do serious search or constraint satisfaction stuff, you don't use
>> Prolog (or if you do use Prolog, you don't use its built-in search).
> I don't quite understand the content of the above observation.
The main thing that Prolog has that other languages don't have is search
with backtracking. Actually there aren't that many areas where search with
backtracking is what you want. If you don't want search with backtracking,
why not use functional programming, which has higher order functions and
embedded function calls inside other function calls, which lead to better
structured and less verbose programs than Prolog gives us?
>> But I see Prolog as a nice toy language, that for a while was over-hyped.
> What is the technical meaning of "toy language"?
I mean a language that is small and demonstrates a principal, that you can
pick up and use without there being a lot of baggage attached you have to
master to use it.
> I seem to remember that you've commented from time to time on Prolog
> being over-hyped. Sure it's been over-hyped, but so has democracy,
> relativity theory, and sliced bread. I doubt that any of our favorite
> languages - Prolog, Mercury, Haskell, Oz, other nice things - will
> ever be a huge mainstream success. That doesn't detract from their
> usefulness.
I'm simply suggesting we are honest. Prolog has been around a long time. If
it was simply, as someone was suggesting, that all it needed was the right
textbook to be written for it to "take off", that would have happened by
now. When I first learnt Prolog 25 years ago, it really was sold as the
language that everyone would be using in future. We need to work out why
that hasn't been the case - why instead of the logic programming paradigm
taking off, the object-oriented one did.
Part of the problem may be that while Prolog was sold as a "simple and easy
to use language, more like human thinking than conventional languages"
experience - not least the many questions from novices in this newsgroup -
suggest that it is not. Novice programmers seem to find Prolog "hard"
compared to imperative languages. If the main selling point of Prolog was
ease of use, but it doesn't actually have ease of use when used by people
other than a few mathematically inclined sorts, what does it have?
I'm quite happy to accept that some of the deficiencies of Prolog are dealt
with in later logic programming languages. Part of the problem is that to
most people logic programming is Prolog and Prolog is logic programming, and
no other language has managed to succeed it. It may well be it's the high
profile of the limited Prolog that stands in the way of any other logic
programming language succeeding.
Matthew Huntbach
Torkel Franzen
> The main thing that Prolog has that other languages don't have is search
> with backtracking.
I don't agree. Having partially instantiated structures is a much more
striking feature of Prolog. Depth-first search is OK, but of course
no panacea. It can be used to implement any search algorithm you like.
> I mean a language that is small and demonstrates a principal, that you can
> pick up and use without there being a lot of baggage attached you have to
> master to use it.
So a toy language is a simple language? Then toy languages are
clearly the way to go!
> When I first learnt Prolog 25 years ago, it really was sold as the
> language that everyone would be using in future.
There isn't any such language and never will be.
> Part of the problem may be that while Prolog was sold as a "simple and easy
> to use language, more like human thinking than conventional languages"
> experience - not least the many questions from novices in this newsgroup -
> suggest that it is not.
"More like human thinking" is always a dubious sell.
Matthew Huntbach
> Matthew Huntbach <m...@dcs.qmw.ac.uk> writes:
>> The main thing that Prolog has that other languages don't have is search
>> with backtracking.
> I don't agree. Having partially instantiated structures is a much more
> striking feature of Prolog. Depth-first search is OK, but of course
> no panacea. It can be used to implement any search algorithm you like.
The logic variable is much more powerful in a concurrent setting, but
Prolog with its backtracking mechanism is inherently sequential. While
the logic variable does it very nicely, I'm not sure that a partially
instantiated data structure is a feature which is strikingly unique to
Prolog. The same sort of thing is accomplished in standard imperative
languages with pointers into structures.
>> I mean a language that is small and demonstrates a principal, that you can
>> pick up and use without there being a lot of baggage attached you have to
>> master to use it.
> So a toy language is a simple language? Then toy languages are
> clearly the way to go!
So we'd be happy programming in lambda calculus? My point is that a simple
language may seem powerful and satisfying on a small scale, but scale it up
to large programs and it becomes very verbose and obscure. Also, languages
for realistic use in modern systems do require a lot of baggage to link them
up to the sort of interactive networked world we want to write programs
for. We language theorists may find such things an annoying distraction, but
for ordinary programmers they are the important bit.
>> When I first learnt Prolog 25 years ago, it really was sold as the
>> language that everyone would be using in future.
> There isn't any such language and never will be.
I think however there were optimistic hopes that Prolog would become much
more mainstream and widely used than it has. This was also seen in the
Japanese Fifth Generation project's adoption of the logic programming
paradigm in 1981. People really did believe it would become a fundamental
part of how programming is done, instead it has become a sideline.
>> Part of the problem may be that while Prolog was sold as a "simple and easy
>> to use language, more like human thinking than conventional languages"
>> experience - not least the many questions from novices in this newsgroup -
>> suggest that it is not.
> "More like human thinking" is always a dubious sell.
Indeed. Various imperative languages were sold on the basis that because
they had keywords which were English words, the languages were "just like
English". When Prolog started, however, there was a genuine belief that
because it wasn't just sugared machine code as imperative languages are, but
instead based on a notation (logic) originally defined entirely for human
use, it would somehow be more natural and easy for humans to use. Clearly
this is not so - indicated by the constant flow of novice programmers to
this newsgroup who clearly think of Prolog as something "hard" compared to
imperative languages.
Part of the problem may be that Prolog was over-sold with its backtracking
mechanism treated as some sort of magic which would solve problems without
you having to think how it does it, when the reality is that it's fairly
crude and to make effective use of it you actually do have to have a good
idea of exactly how it works. Another part of the problem is recursion. You
have to use recursion in Prolog. For some people, myself included, recursion
is a simple and natural way to solve problems. My experience of teaching
programming, however, and this seems to be backed up by quite a few
empirical studies, is that most people do have real difficulties using it.
I'm seeing this myself in an exercise I've set to my programming class which
I'm now marking - there's an obvious and simple recursive solution, use of
recursion has been a major feature of my teaching, and I've told them how to
solve this sort of problem using recursion, and showed them that an iterative
approach is much more messy and fiddly - yet most of the class have still
chosen to tackle it using iteration.
Matthew Huntbach
Torkel Franzen
> While
> the logic variable does it very nicely, I'm not sure that a partially
> instantiated data structure is a feature which is strikingly unique to
> Prolog. The same sort of thing is accomplished in standard imperative
> languages with pointers into structures.
Surely there is nothing "strikingly unique" in any programming
language. What you can do in one language, you can do in another, one
way or the other. You can implement depth-first backtracking in C, for
example. So that's no more unique to Prolog than anything else. What
is "striking" is a matter of what we find useful in practice.
> My point is that a simple
> language may seem powerful and satisfying on a small scale, but scale it up
> to large programs and it becomes very verbose and obscure. Also, languages
> for realistic use in modern systems do require a lot of baggage to link them
> up to the sort of interactive networked world we want to write programs
> for.
Sure.
> We language theorists may find such things an annoying distraction, but
> for ordinary programmers they are the important bit.
Distraction from what? Prolog has its uses, where it works
wonderfully well. How to spend ten million dollars, or six months of
your time, or any other combination of resources, to actually produce
a working game or ticket booking system or bookkeeping system or tax
filing system or any other such application that needs to interact
with various systems or users using various protocols is a different
matter.
> I think however there were optimistic hopes that Prolog would become much
> more mainstream and widely used than it has.
So now we can take a more realistic view: Prolog is a splendidly
useful language, but not "the language of the future".
Matthew Huntbach
> Matthew Huntbach <m...@dcs.qmw.ac.uk> writes:
>> While the logic variable does it very nicely, I'm not sure that a partially
>> instantiated data structure is a feature which is strikingly unique to
>> Prolog. The same sort of thing is accomplished in standard imperative
>> languages with pointers into structures.
> Surely there is nothing "strikingly unique" in any programming
> language. What you can do in one language, you can do in another, one
> way or the other. You can implement depth-first backtracking in C, for
> example. So that's no more unique to Prolog than anything else. What
> is "striking" is a matter of what we find useful in practice.
Sure you can implement depth-first backtracking in C, but it's not a
fundamental part of the language as it is in Prolog. If C had depth-first
backtracking as Prolog has, it would have special statements which gave
indeterminate choice, and if you were executing a lis of statements at
some point if one statement hit a failure condition, you would backtrack.
But in C you can't make it have a list of statement {stat1;stat2;stat3}
witj execution of stat3 failing and what was accomplished previously by
stat2 and stat1 being undone to allow backtracking.
>> We language theorists may find such things an annoying distraction, but
>> for ordinary programmers they are the important bit.
> Distraction from what?
From the nice simple model which a toy language gives us. As language
theoreticians we're interested in developing the underlying model of a
language. Once we've done that, we don't want to spend our time working on
all the libraries and things which have nothing to do with the underlying
model but are needed to make the language usable in real world contexts.
> Prolog has its uses, where it works
> wonderfully well. How to spend ten million dollars, or six months of
> your time, or any other combination of resources, to actually produce
> a working game or ticket booking system or bookkeeping system or tax
> filing system or any other such application that needs to interact
> with various systems or users using various protocols is a different
> matter.
>> I think however there were optimistic hopes that Prolog would become much
>> more mainstream and widely used than it has.
> So now we can take a more realistic view: Prolog is a splendidly
> useful language, but not "the language of the future".
The thesis of this thread is that Prolog *could* become a "mainstream"
language, and it's the fault of the Prolog community that it hasn't - all
that is required is for the right sort of textbook to be written, or for
people who teach Prolog to do it in a different way. I don't think this is
so, I think Prolog is a language whose limitations mean it will not achieve
any more widespread use than it has already.
I'm not even sure that Prolog is a "splendidly useful" language. Even though
it's a language I've played with for a long time and am quite familiar
with, I find it difficult to think of any circumstances where it's the
language I would choose to use for any significant piece of programming.
Once again, when I say this I don't mean to condemn the whole of logic
programming, since I distinguish Prolog as just one example of the logic
programming paradigm - I'm not using "Prolog" tomean "any logic programming
language".
Matthew Huntbach
Torkel Franzen
> Sure you can implement depth-first backtracking in C, but it's not a
> fundamental part of the language as it is in Prolog.
So is backtracking any more "unique" to Prolog than partially
instantiated structures?
> From the nice simple model which a toy language gives us. As language
> theoreticians we're interested in developing the underlying model of a
> language.
I'll take your word for it. I'm just interested in using languages.
> I don't think this is
> so, I think Prolog is a language whose limitations mean it will not achieve
> any more widespread use than it has already.
Sure, along with Mercury, Oz, Haskell, and so forth.
> I'm not even sure that Prolog is a "splendidly useful" language. Even though
> it's a language I've played with for a long time and am quite familiar
> with, I find it difficult to think of any circumstances where it's the
> language I would choose to use for any significant piece of
> programming.
What does "significant" mean here?
billh
>
> The thesis of this thread is that Prolog *could* become a "mainstream"
> language, and it's the fault of the Prolog community that it hasn't - all
> that is required is for the right sort of textbook to be written, or for
> people who teach Prolog to do it in a different way. I don't think this is
> so, I think Prolog is a language whose limitations mean it will not achieve
> any more widespread use than it has already.
>
> I'm not even sure that Prolog is a "splendidly useful" language. Even though
> it's a language I've played with for a long time and am quite familiar
> with, I find it difficult to think of any circumstances where it's the
> language I would choose to use for any significant piece of programming.
> Once again, when I say this I don't mean to condemn the whole of logic
> programming, since I distinguish Prolog as just one example of the logic
> programming paradigm - I'm not using "Prolog" tomean "any logic programming
> language".
>
> Matthew Huntbach
You are playing games with the word "Prolog".
Is it the "thesis" of this thread "that Prolog *could* become a
"mainstream" language, and it's the fault of the Prolog community that
it hasn't"?
No, this thread is asking the question: why hasn't Prolog met with
widespread acceptance and what might be done to bring that about?
Your answer? Because everthing that could have been done to make
Prolog acceptable was done, and done in the best of all possible ways,
if Prolog has not been widely accepted then, since as part of this, the
now "standard" ISO definition of Prolog is necessarily the best of all
possible definitions of "Prolog", the fault cannot lie with the ISO
definition of Prolog but, rather, must be inherent in the very concept
"Prolog".
I do not accept your premise and I find your conclusion repugnant on
its face.
Bill Hogan
Matthew Huntbach
> Matthew Huntbach wrote:
>> The thesis of this thread is that Prolog *could* become a "mainstream"
>> language, and it's the fault of the Prolog community that it hasn't - all
>> that is required is for the right sort of textbook to be written, or for
>> people who teach Prolog to do it in a different way. I don't think this is
>> so, I think Prolog is a language whose limitations mean it will not achieve
>> any more widespread use than it has already.
>>
>> I'm not even sure that Prolog is a "splendidly useful" language. Even though
>> it's a language I've played with for a long time and am quite familiar
>> with, I find it difficult to think of any circumstances where it's the
>> language I would choose to use for any significant piece of programming.
>> Once again, when I say this I don't mean to condemn the whole of logic
>> programming, since I distinguish Prolog as just one example of the logic
>> programming paradigm - I'm not using "Prolog" tomean "any logic programming
>> language".
No, I don't think so. If we are going to talk about Prolog, hadn't we better
make sure we agree what we mean by the word? Sometimes the word has been
used rather sloppily to mean any logic programming language (which would
incorporte things like Mercury), but I've always been keen that it should
not be used in that way. The reason for this is that people who may have
been put off Prolog by its limitations may not realise that there are other
logic programming languages which overcome those limitations. My preference
is to use the word "Prolog" for that subset of logic programming with strict
left-to-right execution of goals, depth-first search with backtracking, and
no types.
> Is it the "thesis" of this thread "that Prolog *could* become a
> "mainstream" language, and it's the fault of the Prolog community that
> it hasn't"?
>
> No, this thread is asking the question: why hasn't Prolog met with
> widespread acceptance and what might be done to bring that about?
This discussion started off when someone made an accusation against the
Prolog community that we deliberately teach our language in a way that makes
it seem hard in order to prevent it becoming mainstream, in order that we
should remain some sort of exclusive clique. I thought this was a crazy
accusation - I am sure the last thing any enthusiast for a programming
language would want to do is stand in the way of it becoming mainstream, and
it is the dream of nearly every enthusiast of a programming language that it
will take off and become a standard language used in real-life applications
by large numbers of people. So, in a way, I'm defending the Prolog community
against what I thought was an unfair accusation.
> Your answer? Because everthing that could have been done to make
> Prolog acceptable was done, and done in the best of all possible ways,
> if Prolog has not been widely accepted then, since as part of this, the
> now "standard" ISO definition of Prolog is necessarily the best of all
> possible definitions of "Prolog", the fault cannot lie with the ISO
> definition of Prolog but, rather, must be inherent in the very concept
> "Prolog".
I don't think the fault lies with the ISO definition of Prolog, because the
ISO definition just cleans up the edges and subsidiary issues, the
essentials of Prolog - left-to-right depth-first search with unification
and backtracking - were around long before the ISO definition.
In the course of this conversation, the languages Perl, PHP and Python were
mentioned as languages which had become mainstream. Now these are languages
which have had nothing like the support that Prolog has had. Prolog is
taught in universities across the world, and has been for many years. A lot
of government money has been thrown into Prolog and other logic programming
languages - particularly when the Japanese government latched onto them for
use in its Fifth Generation project in the 1980s. Hundreds if not thousands
of academics have spent large amounts of time researching and developing
logic programming languages, there have been major academic conferences on
the subject. So why is it that Perl, PHP and Python, which spread with no
sort of official or academic backing or the prestige that Prolog has long
enjoyed amongst the academic community, have become mainstream, while Prolog
which has been around for decades longer hasn't?
> I do not accept your premise and I find your conclusion repugnant on
> its face.
This is just throwing abuse. I'm a logic programmer, have been since I was
an undergraduate taught Prolog by Bob Kowalski, have been employed on grants
to develop logic programming, have written a book on logic programming,
continue to research, write on and play with logic programming. It's a
matter of great concern to me that logic programming hasn't taken off. But I
think we need to be honest with ourselves when we ask why. Maybe it was
over-hyped and suffered a backlash. Maybe it isn't such a natural and easy
to use programming paradigm as we believed. Maybe there have been too many
competing research teams which have created the impression of confusion.
Maybe the dominance of one imperfect or problematical form of logic
programming has stifled the development of a better one.
What I do know is that if when someone asks these questions all he gets is
abuse thrown back at him, it will not help the promotion of logic
programming. It's something one often sees in life - a good idea or
something worthwhile is killed by kindness because its supporters won't
listen to criticism which is actually intended to be constructive and to
bring out and correct its weak points.
Matthew Huntbach
Benjamin Johnston
Thanks, Matthew for a well written and well thought out posting. My personal
experience is that Prolog is an incredibly useful language for virtually all
of my "non-serious" programming. Parsing files, performing transformations,
processing text, generating websites and performing web-scraping are among
many tasks that I've been impressed with Prolog's practical usefulness. Even
though I know many of the mainstream scripting and web languages, I more
often than not end up using Prolog. That is why I believe it has a place as
a mainstream language.
I think your point about Prolog's support (government, academic) is a good
one. I think you're right when you question whether logic programming really
is a natural and easy to use programming language as it is claimed to be. I
know people who have excelled at learning Prolog (in a university course),
but when I ask them why they don't use it in "real life", they indicate that
they just can't see how Prolog would be used.
I think with languages like Java you can get away with writing
copy-and-paste code without actually understanding what it does. You can
have a fully functioning program immediately but then learn the exact
nuances of the language later. It's possible to write Java code with a
disengaged brain. Prolog, I think, is a lot more demanding -- the truth of
the matter is that Prolog is *executed* on a computer even though Prolog is
is said to be "declarative". I think this level of indirection is what makes
it difficult.
However, I also feel that Prolog isn't really taught in the right way. My
feeling is that way too many textbooks and courses devote too much time to
solving problems about mothers, grandmothers and ancestors. I think a more
practically oriented course or textbook might make some difference -- the
very first page should introduce some plausibly practical but simple program
(like, say, something that transforms lines from one set of codes to
another, or maybe a query language for a CSV-text or RDF based database). An
emphasis on actually getting things done would bridge the gap between
knowing Prolog and knowing how to apply Prolog.
I'm really beginning to think that Prolog Server Pages might be something
worthwhile for me to go ahead and properly implement. It is a simple idea,
it offers a natural transition from beginner to advanced programmer, it can
demonstrate practical database querying, it can demonstrate writing parsers
and interpreters, and it produces quite visual output that is rewarding for
beginners.
I also realize that you suggest that there may be deeper questions that also
need to be answered. I'm not sure that I have a response to those -- but I
will certainly spend some time considering them. Maybe you're right, and
maybe the language will never capture the imaginations of anybody but a
small minority who have for whatever reasons been exposed to just the right
conditions to enjoy and understand the language and not be put off by it.
-Benjamin Johnston
"Matthew Huntbach" <m...@dcs.qmw.ac.uk> wrote in message
news:c3rmoq$f0g$1...@beta.qmul.ac.uk...
Jamie Andrews; real address @ bottom of message
The role of the word "paradigm" is interesting here.
Originally, "paradigm" meant just "one that serves as a
pattern or model" (thanks dictionary.reference.com). When the
philosopher of science Thomas Kuhn was writing his book "The
Structure of Scientific Revolutions" in 1962, he was casting
around for an appropriate word to mean a mindset or point of
view that is replaced by another mindset or point of view in a
scientific revolution. He chose "paradigm" even though he knew
that the word did not mean exactly what he wanted. So he spoke
of the phlogiston paradigm (the theory that burning materials
lose negative weight) being replaced by the oxygen paradigm (the
theory that burning materials gain oxygen), the Newtonian
paradigm being replaced by the Einsteinian relativity paradigm,
etc.
As far as I can tell, the use of "paradigm" in computing
originated with Robert W. Floyd's 1978 Turing Award lecture,
"The Paradigms of Programming". In that lecture, Floyd
explicitly cites Kuhn and suggests that programming paradigms
compete with each other -- though oddly, by "paradigm" Floyd
seems to mean not primarily a style of language, but rather a
general approach to solving a problem (he speaks of languages
"supporting" or "not supporting" a paradigm).
However, in the 1970s and 1980s there certainly was a
feeling in the air that different styles of programming
languages -- GOTO-imperative, structured-programming,
functional, logic, and then OO -- were competing Kuhnian
paradigms, and that one would win out. The fact that GOTO
became virtually eliminated, and that many shops converted
(however weakly) to OO, seemed to support this view.
Logic programming was born at the heyday of this point of
view. It was difficult at that time to say "we have a new style
of programming language, and we think it would be good for some
specialized applications", because the response from many people
would have been "Not another programming language for
specialized applications! We have too many as it is! We should
be striving for ONE dominant language." Therefore Prolog was
hyped -- not so much in printed articles as far as I can tell,
but on the conference circuit -- as the exemplar of a new
paradigm that would sweep away all other paradigms. This was
especially true in the AI community, where Prolog was closely
associated with the "neat" AI mindset (as opposed to the
"scruffy" mindset).
There are still many people who take this point of view.
Many therefore tend to view logic programming as a "failed
paradigm", since it did not become dominant and the AI projects
that it was closely associated with (e.g. 5th Generation) did
not achieve any more stunning success than any other projects.
Meanwhile, the real Kuhnian paradigm that has been more or
less overthrown is the very idea that programming languages are
competing for absolute dominance. Many programmers now
recognize that different languages and styles of languages are
good for different things. Commercial programmers often use a
mixture of C, Java and Perl for their tasks. Languages like
Python and Ruby enjoy a small but enthusiastic following,
unencumbered by any dreams of glory about "dominant languages".
ML and Haskell are the languages of choice among many
researchers, not just in universities.
I think that logic programming languages will be able to
fit back into mainstream programming eventually. However, it
may well only be when enough people have changed their minds and
enough old-paradigm folks have died off. Once that happens,
Prolog (or some standardized replacement, probably with types
and OO features) will assume its place with Python, Ruby, ML,
Haskell and Perl as an excellent language for specialized
applications.
--Jamie. (nel mezzo del cammin di nostra vita)
andrews .uwo } Merge these two lines to obtain my e-mail address.
@csd .ca } (Unsolicited "bulk" e-mail costs everyone.)
Matthew Huntbach
> However, in the 1970s and 1980s there certainly was a
> feeling in the air that different styles of programming
> languages -- GOTO-imperative, structured-programming,
> functional, logic, and then OO -- were competing Kuhnian
> paradigms, and that one would win out. The fact that GOTO
> became virtually eliminated, and that many shops converted
> (however weakly) to OO, seemed to support this view.
I would say that OO *has* won out. It doesn't mean that OO is the only
style of programming used, but it is the style in which programming now is
generally taught to novices, it is the style predominantly used in industry
at least for new applications, and it is the style which anyone designing a
new programming language would use - e.g. I doubt the people responsible for
C-sharp[ had any particular ideological reasons to adopt any paradigm, but it was
unthinkable that they would have done anything but made it an OO language.
The reason for this is that OO fits in with the idea of programming as
tying together existing entities, which is increasingly what it is about. It
was not so apparent in the 1970s that programming would move that way.
Back then there was still a feeling that a program was something whcih took
data, did some calculations and fed back an answer - and you develped your
program from scratch. Modern programming, however, is much more about
interaction and using components. Prolog fits very badly into that.
> Logic programming was born at the heyday of this point of
> view. It was difficult at that time to say "we have a new style
> of programming language, and we think it would be good for some
> specialized applications", because the response from many people
> would have been "Not another programming language for
> specialized applications! We have too many as it is! We should
> be striving for ONE dominant language." Therefore Prolog was
> hyped -- not so much in printed articles as far as I can tell,
> but on the conference circuit -- as the exemplar of a new
> paradigm that would sweep away all other paradigms. This was
> especially true in the AI community, where Prolog was closely
> associated with the "neat" AI mindset (as opposed to the
> "scruffy" mindset).
No, I don't think logic programming was seen then as something for a niche
market. I think there was a genuine hope (rather than belief) that it would
come to dominate in the sense that the standard programming languages
ordinary people would be using about now would be strongly influenced by
Prolog.
There is, of course, and there was then, the nature v. nurture argument.
That was why the Prolog pioneers were particularly keen on getting children
to use their language. The idea was that if people were introduced to
programming in logic at an early age they would grow up thinking of
programming in this way, and hence produce better more logical programs.
I'm still interested enough in this argument to think it worth considering.
We know (there's yet another one in this newsgroup today) that novices find
Prolog "hard". Yet is it because it really is hard, or because they come to
Prolog after having been taught programming in imperative languages? If
young children were taught logic programming, would they find it natural? Or
would they too gravitate to more imperative styles of programming and find
them easier as soon as they had the chance?
As I've noted here before, for example, it seems that even novice
programmers who haven't had any previous experience with programming,
naturally move to iterative solutions to problems rather than recursive. One
of the selling points of Prolog was that you didn't have to think of
problems in terms of doing things, you just thought of them in terms of
declaring the solution logically. But for many pepople this seems to be
completely unnatural - right from the start they want to think of solving
the problem in terms of imperative steps, and even if you teach them Prolog
first, they think of Prolog in an imperatuve way rather than a logical way.
> There are still many people who take this point of view.
> Many therefore tend to view logic programming as a "failed
> paradigm", since it did not become dominant and the AI projects
> that it was closely associated with (e.g. 5th Generation) did
> not achieve any more stunning success than any other projects.
AI at the time was dominated by the idea of expert systems - programs into
which you fed data and they calculated and gave you an answer. Prolog fitted
into that reasonably well. But AI today is dominated by intelligent agents -
which means concurrency and interaction, and Prolog works very badly at that
level. I do think, however, that the belief that Prolog and logic
programming are the same thing has led people to write off logic programming
for reasons that have only to do with Prolog. I have seen, quite often,
concurrent logic programming being dismissed with arguments that were
actually completely irrelevant, because the people making those arguments
were thinking in terms of Prolog and didn't see through the surface
similarity to Prolog to see that their arguments actually did not apply to
this different form of logic programming.
> Meanwhile, the real Kuhnian paradigm that has been more or
> less overthrown is the very idea that programming languages are
> competing for absolute dominance. Many programmers now
> recognize that different languages and styles of languages are
> good for different things. Commercial programmers often use a
> mixture of C, Java and Perl for their tasks. Languages like
> Python and Ruby enjoy a small but enthusiastic following,
> unencumbered by any dreams of glory about "dominant languages".
> ML and Haskell are the languages of choice among many
> researchers, not just in universities.
I think you're overdoing this argument. I'm not sure than anyone much ever
really thought there would be one dominant language everyone would use.
> I think that logic programming languages will be able to
> fit back into mainstream programming eventually. However, it
> may well only be when enough people have changed their minds and
> enough old-paradigm folks have died off. Once that happens,
> Prolog (or some standardized replacement, probably with types
> and OO features) will assume its place with Python, Ruby, ML,
> Haskell and Perl as an excellent language for specialized
> applications.
Well, there we go - doesn't this indicate that OO has won out since you
suggest that it will need to gain OO features even to reach a niche market?
No, I don't think the reason for Prolog's lack of success is a few old
people who thought it would dominate the world. Actually I think the problem
is there isn't really a niche for Prolog. I find it hard to think of
anywhere where I'd use Prolog as my first choice language. I can think of
areas where Prolog might be suitable - but in almost all cases, something
else is a bit better. If I want to do declarative stuff, functional
languages are better. If I want to do scripting stuff, scripting languaegs
are better.
However, once you introduce concurrency into logic programming, things
change. The ability to incorporate unassigned variables within structures,
noted previously by someone as Prolog's main feature, becomes a much more
powerful thing than it is in sequential Prolog. The abandoning of Prolog's
central control mechanism with its global stack, means interaction is
handled with ease. I think then logic programming definitely wins out over
functional programming where, despite monads, interaction really isn't
handled well, and modern computing is all about interaction.
Matthew Huntbach
bal jeu@sympatico.deleteme.ca Alan Bal jeu
> change. The ability to incorporate unassigned variables within structures,
> noted previously by someone as Prolog's main feature, becomes a much more
> powerful thing than it is in sequential Prolog. The abandoning of Prolog's
> central control mechanism with its global stack, means interaction is
> handled with ease. I think then logic programming definitely wins out over
> functional programming where, despite monads, interaction really isn't
> handled well, and modern computing is all about interaction.
>
Other than the obvious fact that concurrency means the program can keep
working while waiting for input on some future computation, I don't see
this.
Matthew Huntbach
You can have several parts of the program working an communicating with each
other. You obviously can't have this in standard Prolog where one predicate
call has to execute to completion before the one to its right in the list
can start up.
Matthew Huntbach
bal jeu@sympatico.deleteme.ca Alan Bal jeu
interaction?
> > Other than the obvious fact that concurrency means the program can keep
> > working while waiting for input on some future computation, I don't see
> > this.
>
> You can have several parts of the program working an communicating with
each
> other. You obviously can't have this in standard Prolog where one
predicate
> call has to execute to completion before the one to its right in the list
> can start up.
>
> Matthew Huntbach
Do you mean communication via the common parameters they both received,
where one thread fills data and the other uses it? Would a
producer-consumer pattern be possible in concurrent logic where the consumer
blocks until the producer makes something? How does it work?
Matthew Huntbach
>> > Do tell more. How does concurrent logic programming deal with
>> > interaction? Other than the obvious fact that concurrency means the program can keep
>> > working while waiting for input on some future computation, I don't see
>> > this.
>> You can have several parts of the program working an communicating with
>> each other. You obviously can't have this in standard Prolog where one
>> predicate call has to execute to completion before the one to its right in
>> the list can start up.
> Do you mean communication via the common parameters they both received,
> where one thread fills data and the other uses it? Would a
> producer-consumer pattern be possible in concurrent logic where the consumer
> blocks until the producer makes something? How does it work?
Yes, I mean just that. That is exactly how the concurrent logic languages
work. They abandon Prolog's full unification so that a consumer waits until
a producer binds an unbound variable to pattern match with the head of a
clause. The reason they do not degenerate the paradigm to effectively first
order functional programming is that they maintain the logic variable, so it
is possible for the consumer to consume something containing unbound logic
variables and to become the producer of those variables, while the erstwhile
producer becomes the consumer - thus the interaction I was talking about.
For a good introduction, see my paper in IEEE Software November 1995 (vol
12, no 6), or for more detail, see my book no, 1630 in the Springer Lecture
Notes in Computer Science series (both co-authored with Graem Ringwood).
My take on this now is that it's a good operational model, but too low level
for practical programming, leading to verbose and hard-to-understand code.
Thus my current work is on developing a language in which some of the
standard programming patterns in concurrent logic programming are
crystallised into syntax of a richer language which compiles down to
concurrent logic code.
Matthew Huntbach
Fabien Todescato
> My take on this now is that it's a good operational model, but too low level
> for practical programming, leading to verbose and hard-to-understand code.
> Thus my current work is on developing a language in which some of the
> standard programming patterns in concurrent logic programming are
> crystallised into syntax of a richer language which compiles down to
> concurrent logic code.
What is your opinion about Oz then ?
Fabien
Matthew Huntbach
Oz does a similar sort of thing - its origins lie in adding syntactic sugar
to a concurrent logic language. In fact its base language keeps some of the
search which the committed choice concurrent logic languages I've been
talking about lose. However, I think this makes it a messier language, since
I doubt whether inbuilt search is particularly useful. It's made messier
still by Oz's introduction of mutable store as part of the underlying model.
I don't think that's necessary, the language I've been developing translated
to pure concurrent (but committed choice) logic programming. I also don't
particularly like the syntax which top-level Oz has, though I guess that's a
matter of taste. On the other hand, obviously Oz has had a lot of people
putting a lot of effort into building a useable product, whereas I'm just me
occasionally tweaking a few things in a language which exists only in a
rough state.
Matthew Huntbach
Matthew Huntbach
> Quoting Matthew Huntbach in comp.lang.prolog:
>>As I've noted here before, for example, it seems that even novice
>>programmers who haven't had any previous experience with programming,
>>naturally move to iterative solutions to problems rather than recursive. One
>>of the selling points of Prolog was that you didn't have to think of
>>problems in terms of doing things, you just thought of them in terms of
>>declaring the solution logically. But for many pepople this seems to be
>>completely unnatural - right from the start they want to think of solving
>>the problem in terms of imperative steps, and even if you teach them Prolog
>>first, they think of Prolog in an imperatuve way rather than a logical way.
> However, may I just suggest that people simply want to be in control? We
> don't want some darn machine to abstract things from us leaving us as
> simple followers?
Are we a "simple follower" of a car when we drive it without kowing preciely
what is happeing in the gears and motor underneath? No, I don't think so -
we can drive it far more effectively when we can concentrate on what we need
to know rather than be worried about the details of what goes on
undereneath. Good programming practice is about abstraction - we think of a
piece of code at the appropriate level for what we want to use that code
for, and not in terms of what might be happenin underneath in various
procedure calls. It's this ability to be able to use abstratcion that makes
a good programmer. I agree, however, that it's an ability many people seem
to lack, and this inability to use abstraction seems to be the reason why
programming is a notoriously "difficult" subject.
In the case of Prolog, however, I think depth-first search with backtracking
promises more than it delivers. The reality is that you can't use it much
without knowing exactly how it works, and you actually do have to think of
your Prolog program in quite a mechanical imperative way. In pratice I find
when I'm writing Prolog I rarely make use of it, and when I'm writing
concurrent logic programs (which don't have backtracking) I rarely miss it.
Matthew Huntbach