🚀 go-pugleaf

In article <1992Oct30.143638.2129@dcs.qmw.ac.uk> dc@dcs.qmw.ac.uk (Daniel Cohen) writes:
>I was a bit baffled to find entries like PARLOG and STRAND-88 in your
>excellent list. The STRAND-88 system, for example, is not written in
>Prolog (although large parts of the system are written in Strand, which
>is a logic programming language). More importantly, I would have to
>classify the system as a programming language implementation and not as
>an application; if STRAND-88 qualifies then surely so do all Prolog
>implementations (most of which will have at least some part written in
>Prolog).

Daniel, you didn't read the entry carefully enough! It says the
Strand88 PROGRAMMING SYSTEM. I agree with you totally that
implementations of logic programming languages written in other
languages should not be included in the list; indeed I pulled one out
that had crept in inadvertently just before posting the article. Below
is the description of this entry:

  The STRAND88 system is extended to permit multiple users to share a
  running Strand system. The very fine granularity of a CLP system;
  coupled with the stream based nature of user interactions through an
  X window interface; makes practical very flexible information systems
  which offer users considerable scope for sharing data. A
  demonstration of concurrent user updates to a shared spreadsheet and a
  shared PERT chart editor with inter-operability between the tools
  proves the point.

Should Strand88 be considered under the Prolog banner? That is
certainly a moot point as it doesn't even have full unification.
However we were careful to say in our original call "Prolog and
related languages" and I don't see any good point in being too
pedantic. I think the family relationship is clear.

The other case you mention - the Parlog system - is rather more
interesting, as it's mostly written in LPA Prolog, with 5% of the
system recorded as being written in Parlog. Thus it qualifies AS AN
APPLICATION OF PROLOG, not Parlog.


>While I applaud the objectives and results of the survey I suspect we'd
>be better off restricting it to applications other than those which
>are implementations of logic programming systems or subsystems. In
>particular, I suggest excluding:
>
>	logic programming language implementations and libraries;
>	CASE tools for logic programmers;
>	development systems for logic programming;
>	etc.
>
>I realise that these are all bona fide applications from the
>programmer's point of view, but consider the purpose of the database:
>it's to help convince sceptics that Prolog has a good track record in
>application development, not that it's a good language for writing
>other versions of the language in! If I were such a sceptic, flicking
>through the list to see what applications had been done in Prolog in my
>area of, say, armchair testing, my suspicions would be immediately
>aroused by the sight of such "applications" - it would heighten the
>perception that Prolog is the sort of language that's only used by
>people doing research into Prolog.

I see no problem with including many of the Prolog compilers
around which are primarily coded in Prolog. So far we haven't made a
point of including them and we did exclude them from the applications
conference. But they are some of the most intensively used Prolog
applications and as long as we take care to exclude those primarily
coded in C or some other language I intend to include them.

I agree with you about Prolog libraries and other source tools for
logic programmers.  But I think that to leave out ALL mention of the
reflexive use of Prolog would itself be misleading. To some extent it
is a matter of balance. If this was all there was in the database then
your sceptic would have a good point. As it is, I very much doubt it
will amount to more than 5% of the total.

However I would value other opinions. What about Prolog debugging or
program generation systems? What about learning and induction
programs? There are a number of marginal cases which I'm not sure about.

Chris Moss