🚀 go-pugleaf

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.