Re: Ann: SWI-Prolog 7.1.0

On 26/11/2013, at 10:53 PM, Jan Wielemaker wrote:

>> Something like this used to exist in Poplog and SigmaPROLOG,
>> where it was an artefact of representing compound terms as
>> (basically) [<atom>|<array>].  As I recall, it was an unmitigated
>> nuisance.
> 
> We'll see. It breaks nothing as long as you don't use them.

This is the kind of thing people used to say about PL/I.
It wasn't true then either, except in a rather Humpty-Dumpty-ish
sense of "YOU don't use them."

As soon as my code incorporates anyone else's code, all kinds of
hell can break loose.  My code can no longer rely on data generated
by *their* code making sense.

Making a distinction between f and f() made it very difficult to
port code between "Edinburgh" Prologs and SigmaPROLOG or Poplog.
Porting the DEC-10 Prolog library to Poplog was a much bigger
pain than it should have been.

Look, Jan, the next thing I say here may sound offensive.
I don't mean it to be.

The changes you are making to SWI Prolog make it more like
Javascript and less like a logic programming language.

Now from some of the things you said in the announcement, it sounds
to me as though you _intend_ SWI Prolog to me more like Javascript,
and I think you are much more concerned about making SWI Prolog
into a valuable tool for Web developers who aren't terribly
interested in logic programming as such than in "traditional"
users of Prolog.  With the exception of good support for strings
and psi-terms (proper LIFE-like psi-terms), I don't think any of
the changes discussed in this thread actually do that.  And good
support for strings and (proper LIFE-like) psi-terms is also good
for "traditional" users of Prolog, especially NLP.

I may seem to contradict myself here, because I don't like
functor/3 and (=..)/2 being broken.  Psi-terms are a big enough
benefit to justify that, and we have the LIFE documentation to
tell us how to deal with it.  But I don't see any indication of
LIFE being taken as a guide, and again this is compatible with
the changes being driven by the tastes of Web developers rather
than say NLP programmers.

I note that LIFE psi-terms do admit a compound term which I'll
write as f(...) which doesn't have any arguments _yet_ but also
doesn't definitely have _no_ arguments; psi-terms are
open to extension.  So that doesn't necessitate an f() -vs- f
distinction.