Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!icdoc!doc.ic.ac.uk!ad
From: ad@doc.ic.ac.uk
Newsgroups: comp.lang.prolog
Subject: Can I talk about Parlog here?
Message-ID: <2540@gould.doc.ic.ac.uk>
Date: 21 Nov 90 15:40:33 GMT
Sender: news@doc.ic.ac.uk
Reply-To: ad@doc.ic.ac.uk ()
Organization: Logic Group, Dept. of Computing, Imperial College, London, UK.
Lines: 50


Jim Crammond, the implementor of the Parallel Parlog system,
has asked me to post the following mail message to the news.

I should point out that Jim is no longer a researcher in the
Parlog Group (we miss him), and so technical questions should
be sent to :

          parlog@doc.ic.ac.uk


    Andrew Davison



_____________________________________________________________
From: Jim Crammond
Date: Mon, 19 Nov 90 10:20:41 pst
Subject: Re: Can I talk about Parlog here?

> Ah, I've never used IC Parlog, and I'm not particularly interested in
> parallel parsing. What I AM interested in is why people choose to use
> logic programming systems (parallel or otherwise) that ever crash with a
> segmentation fault. This is not an error in your program, no matter how
> erroneous it is: this is an inexcusable error in the implementation. The
> only solution is to find an implementation written by responsible
> professionals.

Sorry, but as the "irresponsible" professional who wrote the Parallel Parlog
system I remain offended.  How can you possibly know what you're talking about
if you have never used the Parlog system and don't use/have interest in
parallel implementations?

Segmentation faults are in fact caught in the parallel parlog system but
I considered it too difficult to attempt to return the system into a
consistent state so that you return to the top level *given the limited
resources available to do this*. We are not simply dealing with one
processor's inconsistent state here but several and issue was non-trivial.
Thus I simply ensure that all processors cleanup and exit.

I would agree that the compiler was - and is - erroneous for not detecting
bad Parlog programs and rejecting them, which is possible to do; however
given limited resources this was not high enough on the priority list.

The parallel parlog system isn't a commercial piece of software (although
when used correctly it is more robust than some commercial systems I have
seen). When you develop a system as part of research you tend to have to
sacrifice some robustness/useability in favour more "publishable" things.

-Jim Crammond.