Re: Remarks on SWI 7

On 28/11/2013, at 12:10 AM, Jan Wielemaker wrote:
> This is (if I read the sorty correctly), an example of a fork that
> failed.

No.  ISE Eiffel and SmartEiffel were totally independent code bases.
It's more like the distinction between the XLC compiler and the GCC
compiler.
>> 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.

Yes and no.  To the extent that it's "yes", there are two reasons.

(a) Limitations and deficiencies in the standard.
    Back in 1985 I said at a logic programming conference that
    the BSI committee's aim to produce a "minimal" standard was
    a great big mistake, that it might satisfy implementors who
    didn't want to change much, but wouldn't offer much to users.

    There was and remains no ISO support for pretty much any
    kind of OS interface: no directories, no way to ask for the
    current time or the last change date of a file, to run an
    external program, &c.  While I was at RMIT I started a
    "POSIX binding for Prolog" project, but was given to understand
    that the ISO committee would have zero interest in looking at it,
    so abandoned it.

(2) Implementors who don't support what _is_ there in the standard.

To the extent that the answer is "no", there is actually a *huge*
amount of useful code that *can* be written in strict ISO Prolog.
There is an abundance of data structures (some from the imperative
literature, some from the functional data structures literature,
other stuff), which could be provided.  Nearly everything in
Yoav Shoam's book on AI programming in Prolog could be converted
to ISO Prolog.  Heck, it wouldn't take a huge effort to port the
dear old PRESS equation solver to ISO Prolog.  We could have a
C parser in a common library.  We could have a modernised PTTP.
IF we could rely on little things like read/1 and write/1 being
compatible...

> Many people took many initiatives,

I am one of them.
I think a total of about 3 people have expressed interest
in http://www.cs.otago.ac.nz/staffpriv/ok/pllib.htm.

> 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.

You might be surprised.  That's exactly the situation Scheme was in
-- although most implementations implemented *most* of the RnRS they
claimed to support -- and the end result of the SRFI process was
greatly improved portability for a wide range of data and algorithms.

You might be surprised.  That's exactly the situation Smalltalk is in.
16 years after the ANSI Smalltalk standard came out, I have
	Squeak
	Pharo
	Visual Age Smalltalk
	VisualWorks Smalltalk
	ST/X Smalltalk
	Dolphin Smalltalk
	Strongtalk
	a copy of Redline Smalltalk (in Java, not yet finished)
	a copy of a Smalltalk in Javascript someone did
	a dead copy of Ambrai Smalltalk (went out of business
	before the first full release, but the betas were _great_)
There is an adequate set of ANSI methods for opening a file
(except for covering encodings), which can be *trivially* implemented
on top of each vendor's own classes.  Sadly, most vendors never
bothered, so I have my own little compatibility library for each
Smalltalk I seriously use.

And guess what, there _is_ serious code being used in multiple
Smalltalks anyway.  There's the SUnit unit testing framework,
which inspired jUnit and the whole xUnit family.  There's the
Refactoring Browser.  There's the Chronology library.  There's
an OO data base or two.  There's the Seaside web framework.
And at least the standard designed a transport format for source
code which has been taken seriously.

While these Smalltalk implementors may not have taken the standard
as seriously as one might have wished, they have done one huge thing
to make all this possible.

They have not gone out of their way to break compatibility with
*themselves*.  Two major changes:

	- Smalltalk had blocks from very early on,
	  but they weren't proper closures.  Most Smalltalks
	  have, after a couple of years of experiment, changed
	  to proper closures.

	- Squeak has moved a lot of stuff out of the "core" into
	  easily installed libraries; others like VAST and VW
	  had gone that route years before.

> Think of Prolog as a family. Just like SQL. SQL has an ISO standard,

I have a full electronic copy of the SQL 2003 standard.
It's gigantic.

> 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).

That is definitely an exaggeration. (The sqlite test code for
NULL handling relies on the statements it uses for setting up
the test data being portable, for example.)

One issue here is that one bad apple can spoil the barrel.

SQLite, for example, doesn't have updatable views and doesn't
support most of ALTER TABLE.  And there have been problems
with the treatment of NULL, which have improved somewhat.

There is an issue with SQL that the big players have _enough_
market share to do very nicely and have no wish to lose customers
to anyone else.  (Our teachers are paid, and sometimes _not_ paid,
using a system which _can't_ be ported away from Oracle, not at
any price short of a total rewrite.  This is not a problem
_for Oracle_.)

> 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.

I was developing on a 32-bit system (still do, mostly), but designed
for 64-bit in the first place.
> 
>> 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.

Yeah, and the terrible thing is that apparently depressed and
pessimistic people are more realistic in their assessments.

> First of all, you are supposed to have a test suite these days.

Oh joy.  Every programmer his/her own expert system evaluator.

> If you rely on features of a certain implementation,

That's not the point at issue and you know it.
The question is relying on features OF THE STANDARD
which have *been* standard in Prolog for the last 35 years.

The burden of validation is on the people who introduce and
rely on a NON-standard feature which is NOT compatible with
35 years of books and tutorials.

If I want to look at feature validation of some Prolog system,
Ulrich has charts that tell me everything I need to know.

Look, for my Smalltalk system, I have built up a fairly
detailed chart of what is in

	The Single Unix Specification, version 3.
	The Single Unix Specification, version 4.
	Mac OS X (10.{5,6,7,8}).
	Linux
	Solaris (10,OpenSolaris,11)
	HP-UX 11i
	OpenBSD 5.3

which I am extending to cover Cygwin and AIX.  I don't use
any "POSIX" feature unless I know it's available on all systems,
or have alternatives for systems that lack it, or label it
clearly as specific to some systems.  I have had to retire
some classes because they relied on features that were in the
standards but were in practice missing from systems that had
them in their manuals.

This is a multi-year effort.

One thing makes it worth while.  Except for Mac OS X, all
the operating systems are moving *closer* to POSIX-compliance.
OpenBSD, for example, made *huge* strides over the last couple
of years.  Each system has a lot of stuff that's not in POSIX,
and that's fine.

But there are cases where some XXXX implementor has decided
that they know best.  Here's an example.

Having generated a C source file, the next step is to compile it.
There's not a lot of variation in what I want, except for
32-bit vs 64-bit.  The POSIX standard has a function, confstr(),
for getting system-specific "configuration" strings, and a standard
set of things you can ask for, including the compiler and linker
flags needed for 32-bit or 64-bit building.  So I _should_ be able
to write

	c99 -c `getconf POSIX_V6_ILP32_OFFBIG_CFLAGS` a.out.c
	...
	c99 -o a.out `getconf POSIX_V6_ILP32_OFFBIG_LDFLAGS` \
	   a.out.o ... \
	   `getconf POSIX_V6_ILP32_OFFBIG_LIBS`

(It's not quite that simple.  My script might have to fiddle around
to figure out whether to use _V6_ or _V7_ or possibly even XBS5
instead of POSIX.  But it's not _that_ hard to sort out.)

I mean, the ability to write a portable script like this is
precisely the kind of thing the getconf(1) command and the confstr(3)
function backing it are *for*.

But then along come the BSD people and say, right there in the
manual page for confstr(), that confstr() is obsolete and you should
use sysctl instead.  Except that the information I need isn't *in*
sysctl!

The wilful incompatibility of a small group has made my development
task *much* harder, without giving me any benefit.  (Yes, I know
there is a lot of stuff in sysctl.  But what of it is of interest
to me I have to get another way anyway because most POSIX systems
don't _have_ sysctl.)

> 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.

RED HERRING!

RED HERRING!

RED HERRING!

The last time I wrote any Fortran code for a specific implementation
was in 1978.  Since then I have written to the standard.  SIGPLAN has
a Fortran magazine which regularly reports on the compatibility of
the main Fortran implementations.  The R system uses a fair bit of
Fortran, and you know what?  It works.  Yes, each system has
extensions, and yes, systems are always playing catch-up with standards
and so never quite agree on what's implemented and what isn't.
But all the time the systems are moving *closer* to the current standard
and each other, ***NOT*** further away.

"These systems have not yet perfectly converged therefore it is fine
for my to deliberately diverge where there _had_ been convergence"
is neither sound logic nor calculated to make friends.

I dare say there are no two C compilers that are exactly alike, yet I
have a great deal of C code that moves between Sun C, GCC, clang, and
pcc without noticing any difference.  (My copy of the intel C compiler
wasn't properly installed and I believe the licence has expired, but
when I _was_ able to use it, my code ported to that with no trouble.)
There are bits of C99 that the various compilers still do not fully
implement, and they are not the same bits, but the bits they *DO*
agree on THEY DO NOT MAKE INCOMPATIBLE CHANGES TO.

The thing about both ISE Eiffel and SmartEiffel was that they *both*
made major backwards-incompatible changes.  For example, the type of
the literal 1 changed from INTEGER to INTEGER_8 in SmartEiffel.
The rules for forming operator tokens changed!  There were even
changes to where you needed parentheses!  For each change, there were
reasons.

Consider Haskell and Clean.

Clean has a single implementation.
The change from Clean 1.3 to Clean 2.0 didn't just involve a new
compiler, it involved major language changes, to the point where
absolutely _none_ of my old code worked.  They didn't even have
a compatibility mode.  When they stopped supporting the platforms
I used, by that time I had stopped caring.

Haskell?  I have I think four Haskell98 implementations.  I used to
test my code in all of them.  These days, there are GHC, UHC, JHC,
and I think a couple of others.  There are plenty of language
extensions, especially in GHC.  But you have to ask for the extensions
explicitly.  If you work from a Haskell98 textbook, despite the
failure of the current Haskell compilers to agree 100%, your code
*will* work, with just one exception, which people were warned about
years before compilers stopped supporting it (and GHC still has an
extension for it).  If you work from a Haskll 2010 textbook, and
from the vast portable libraries, your code *will* work.  We don't
need 100% compatibility for ANY language in order to develop a
substantial body of shared code.

All we need is *stable* compatibility on a common core that is
big *enough*.  And then we get a virtuous circle: a stable
language encourages the production of libraries; the existence
of libraries encourages the adoption of the language; the
existence of users encourages the development of new compilers
with different strengths.  So we have compilers that target
high performance parallel native code, and we have compilers
that target Javascript, and we have useful amounts of code that
work under both.



> 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