Re: Remarks on SWI 7

Hi Feliks,

On 11/26/2013 09:28 PM, Feliks Kluzniak wrote:

> Now SWI-Prolog seems to be becoming a new language.  It might be a

No. What I'm trying to do is to make the system evolve to the needs of
todays infrastructure and programmers. I'm not the only one concerned
about the state of affairs around Prolog. I think the clearest example
is Neng-Fa Zhou, taking the initiative for Picat. He also invited me and
even put considerable effort trying to convincing to jump on the Picat
wagon. I have refused. I like some of the aspects of Picat. I dislike
some others. I mostly dislike the fact that it moves away so far from
Prolog that it simply throws away everything. Prolog programs do not run
on Picat, period.

I want a gradual migration path that opens new doors while breaking as
little as possible. The introduction of strings and synchronising its
syntax with the rest of the world is quite radical. It breaks quite a
bit of code. It may demand some effort to get your program running again
or set the Prolog flag double_quotes back to `codes'. All the rest just
avoids some limitations and quirks that I and others have found
annoying. As we have seen, practically none of this is unprecedented,
which is already one clear indication that others have thought this was
necessary.

The ISO process has provided us with a consistent and well defined core
language that is fairly well adopted nowadays. That is a great
achievement. In the process however, many useful things were removed
from the language. In other parts, the compromise is really ugly. Text
representation and modules come to mind. As it stands, changing anything
to the ISO standard that is a bit more involved than adding a new
arithmetic function or a predicate almost all systems already have is a
no-go.

SWI-Prolog will keep running ISO compatible programs largely faithfully.
That is the case now, and likely the case forever. Some things are not
ISO compliant. For example, "A is 4/2, integer(A)" succeeds with A = 2.
Also atom_codes(A, [a,b]) succeeds with A = ab. SWI-Prolog (and most
other Prolog systems) also has many extensions that are not compatible
with other systems.

As it stands, Prolog compatibility is a joke. Practical programming
requires much more than what ISO has standardised. Paulo has succeeded
in creating Logtalk and make it run on about 10 Prolog implementations
(used to be double, but at some moment in time he concluded he should
put minimal demands on Prolog systems to support them). Logtalk allows
for writing programs with a rich `module system' (in a very broad
interpretation of that word) that are pretty portable if you stay within
ISO+Logtalk+Logtalk-libraries. Nevertheless, Paulo will tell you that
portability to other Prolog systems is not the main reason for people to
use Logtalk.

If you write programs in SWI-Prolog, you can escape to YAP. That is
quite likely to remain the case. I've just seen the first output of
YAP's quasi quotation implementation :-) YAP also has the block operators
({}, and []).  YAP is quite likely to get all/most of the rest as well.
If you want to go to a system with a proprietary licence, you can
escape to SICStus.  Here, you can basically rely on a common core
that consists of Quintus and ISO derived features, as well as some
constraing handling.

> better one, for all I know.  There might even be a need for it,
> though the evidence seems scanty so far.  But I am very much afraid

It depends to whom you listen. I have learned that opinions expressed on
this list are not a very good representation of the opinions of
SWI-Prolog users in general. Many turned their back on the academic
discussions here and use stackoverflow.com to get answers for their
daily needs.

	Cheers --- Jan