Re: Remarks on SWI 7

On 11/27/2013 09:26 AM, Richard A. O'Keefe wrote:
>
> On 27/11/2013, at 9:28 AM, Feliks Kluzniak wrote:
>
>>
>> Now SWI-Prolog seems to be becoming a new language.  It might be a 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 that it might soon evolve to a point where it is no longer Prolog: that �traditional� flag is likely to become more and more of a burden, and command less and less attention (even Jan�s very considerable talents and energy are necessarily limited).
>
> By the way, let me offer a parallel.
>
> Some years ago I got interested in Eiffel.
> At that time there was an innovative free implementation from INRI
> called SmallEiffel, later renamed to SmartEiffel.
> The inventor of the language made some changes to the language,
> and the implementors of SmartEiffel made some different changes
> to the language, and eventually the author of the main
> multi-implementation library for Eiffel gave up porting to
> SmartEiffel.  A couple of years later SmartEiffel was dead.
> There is an attempt to revive it, but Liberty Eiffel is not
> yet in a state where I can use it, and when I _did_ need to use
> Eiffel this year, it was the one from the ISE company I used,
> which is free as in beer for personal use.

This is (if I read the sorty correctly), an example of a fork that
failed. These things happen. Knowing what to do if what used to be a
single implementation forks is mostly guessing. The old one may die
(e.g., gcc when egcc came out; didn't affect C users, but did affect
people concerned with the internals for example because they use gcc to
compile for their highly specialised CPU). Often the fork dies and
sometimes they co-exist (Emacs/XEmacs).

This is irrelevant to Prolog, which already has many implementations
that are more different from each other than Emacs and XEmacs.

> A thing I was passionate about for years but eventually got
> quite depressed about was multi-implementation libraries for
> Prolog.  I have enormous admiration for Paulo Moula, still in
> there slogging.  The more bikeshedding differences (like []
> vs '[]') are introduced, the harder it gets to write and port
> such things, and the worse off everyone is.
>
> The point of a standard isn't to be the *best possible* language,
> but to let people *share their work*.

That would be great. Just, it is unrealistic as has been pointed out
before so many times. Many people took many initiatives, but it just
doesn't work out. You cannot have a living language with 20
implementations, many of which have all their own niche and resulting
(changing) requirements. It is useful to share some core as good as
feasible, but this cannot be as restrictive and conservative as the
Prolog ISO standard.

Think of Prolog as a family. Just like SQL. SQL has an ISO standard, but
except for "select * from mytable", no SQL statement is portable (I
tried writing a test suite for SWI-Prolog's ODBC interface with various
backends). Just like Prolog: only member/2 can be implemented portably.
There are nice SQL portability frameworks. Just like Logtalk :-)

> Just recently one of my colleagues was ranting to me about
> a change to the C++ STL library, where ostrstream was
> deprecated in favour of ostringstream, which is _almost_ the
> same, in order to help the more hard-of-thinking C++ programmers.
> He has perfectly good working code which his compiler just
> recently started nagging him to change.  He'll probably end up
> writing his own replacement so that he can be *sure* it will
> hang around, which is not the best way for the world to use
> his time.

I don't know about that one, so I cannot comment.

> When I ported my Smalltalk to OpenBSD it nagged me about
> perfectly safe uses of strcpy() and sprintf(); to shut it
> up I had to waste a couple of days rewriting *working* code
> for no net benefit except to cope with a gratuitous porting
> difficulty.

I know. I was hit by the same. I don't regret this. Yes, some of the
usages of sprintf() and especially strcpy() were completely safe. Some
others were not. In particular sprintf() calls have suffered from a too
small buffer when systems moved from 32-bit to 64-bit.

> One important thing about the [] \== '[]' change is that
> for any particular chunk of Prolog code, there is no tool
> that will let you *tell* whether it is broken by the
> change, short of *thorough* inspection and re-testing.
> Even if the code *isn't* affected, there's a high cost in
> not *knowing* whether it is affected.  And no benefit at
> the other end, because once you start writing code for a
> system that distinguishes, will your code work in a
> system that conforms to the standard?  (Hint: _don't_
> work in the new system and then port back; you have to
> _keep_ testing more or less simultaneously in both, and
> you have to keep in mind _all the time_ that [] might or
> might _not_ be different from '[]'.)

That is very pessimistic. First of all, you are supposed to have a test
suite these days. If you rely on features of a certain implementation,
you better add a test case for it, or some assertion-check that
validates things are fine. The very few things going wrong with [] \==
'[]' forces you to think clearly about your data structure. The bug
won't re-appear after the cleanup. The only cases I've found were one
foreign interface issue and 4 cases where [] was used as an
`out-of-bound' value (i.e, indicating that the value is not a regular
identifier and must be handled differently), but (incorrectly) still
involved in atom operations such as atom_concat/3.

> I liked SmartEiffel, and I thought its changes were _better_
> than those in what became ECMA Eiffel, but I hated being
> trapped in the ghetto of SmartEiffel, and
> I never want to be in such a trap again.

Any Prolog implementation is already such a trap. There are very few (is
there any?) examples of languages with multiple implementations that are
100% compatible. Even in the lucky case that the language has a rich
enough core that is standardised and this standard is faithfully being
implemented by multiple vendors, programs on one often do not run
unmodified on another because of different performance characteristics.

	Cheers --- Jan
_______________________________________________
SWI-Prolog mailing list
[email protected]
https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog