Re: Remarks on SWI 7

Richard O'Keefe:
>> 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 a lot of detail that needed to be resolved first.  Which
programming language was in such a bad shape (in terms of
implementations as of 1987) that even its very fundamental concept of
unification was not defined?

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

Write a document, keep an eye that implementors actually implement
this and maintain it over a while.  Really maintain it.  Then, there
is good reason to start ISO work on it.  So effectively **after**
systems adopted it.  The problem is that differences are on a much
lower level, and you will get all the repercussions, first hand,
otherwise.

Think of errors.  ISO is very clear on this, and has a rudimentary
"mode and type system" consisting of errors and types 7.12, 8.12 and a
format and method to describe built-ins.  However, it is very
frustrating that some implementors simply see this as something
"optional".  This often puts enough sand into the cogs that the entire
enigne comes to halt.

It is already difficult when there is agreement of many.  One reason
is this unprocedural nature of Prolog.  Think of length/2.  It is much
more complex than anything corresponding in command oriented
languages.  But the expectation is often that it cannot be more
difficult than in such languages.  It reality it corresponds to:
Define length, make_list, a for infinity loop, an iterator concept, a
diagnoser that is able to reason on "all terms" plus the errors.

That takes much more time.  Even the current description still is not
perfect for the procedural description.  (Procedurally, ...)

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

The number of individuals who have looked at this document is
significantly larger.  I still do get all kinds of comments on it
because pllib no longer reflects the current state.  It would
therefore help a lot if the document could be updated reflecting
Cor.1:2007 and Cor.2:2012.  An outdated document is sand, too.

It should also consider a "module/package" structure - that is simply
fix a module name for regrouping.  And do not assume much more than
that.

And also ISO/IEC JTC1 SC22 WG17 did consider it via the following
documents, which refer to pllib in detail:

N224: http://www.complang.tuwien.ac.at/ulrich/iso-prolog/evaluable_functors
N225: http://www.complang.tuwien.ac.at/ulrich/iso-prolog/built-in_predicates

These documents and others were used to decide what to put into Cor.2.

http://www.complang.tuwien.ac.at/ulrich/iso-prolog/#Cor.2

Your document is even "archived":

http://www.complang.tuwien.ac.at/ulrich/iso-prolog/#pllib