Which is exactly why we opened up the discussion for this change, to 
not fall into these kinds of problems :-)

And as I said in another mail (I was off the internet for a while, so 
all my replies came through in one batch...), any other proposal (like 
the prototypical one) is welcome.

On Wednesday, Sep 17, 2003, at 07:51 Europe/Zurich, Richard A. O'Keefe 
wrote:

> Roel Wuyts <wuyts at iam.unibe.ch> wrote:
> 	PS: I also do quite some Prolog work. And there, as in Smalltalks, it
> 	annoys me that my code is not portable between different
> 	implementations/vendors...
> 	
> There you are speaking to someone who has experienced the same 
> frustration
> and was the first to do anything about it, and is continuing to try to 
> do
> something about it.  (The SWI Prolog twiki has a link to the "community
> standard" twiki for the library.)  There are some real oddities there.
> For example, the BSI Prolog committee was started by someone who 
> claimed
> to have asked all the Prolog groups in the UK whether they were 
> interested
> in a standard and set it up himself when no-one said yes.  Except he 
> never
> asked anyone at Edinburgh, and never asked on the Prolog Digest, and 
> wasn't
> aware of the "API standard" I'd circulated on the Prolog Digest and 
> issued
> as a technical report.  Then there was the committee member who ran a
> company that produced a "Prolog" which, despite its merits, was not, 
> was
> never meant to be, and couldn't be, Edinburgh-compatible, yet very 
> nearly
> managed to talk the BSI committee into accepting its data structures 
> as the
> abstract data structures for BSI Prolog (which was supposed to be 
> based on
> Edinburgh Prolog).  Then there was the time when the ISO committee 
> decided
> to change some of the most basic operations in the language in a way 
> that
> would break every existing program.  And the poor guy who wrote a book
> based on the then current draft of the standard, only to find the 
> following
> year that it was now dramatically different, so that his book 
> described a
> language which had never existed and never did exist.
>
> And what was the basic underlying problem?  Why, a refusal to concede 
> that
> users had any rights in the matter:  the language belonged to the 
> committee,
> not to anyone who happened to have a body of code written in the 
> language,
> and if the committee decided on an incompatible change to the syntax 
> (which
> they did, several still remain) then that was just to xxxxing bad for 
> the
> lusers.
>
> It's precisely that "we'll change the language any way we like and 
> anyone
> who complains is just an obscurantist luser standing in the way of 
> progress"
> attitude which seems to be at issue here.
>
> The way the BSI and ISO committees kept on hacking at the language did
> _not_ in fact result in great progress being made.  To this day we 
> still
> don't have environment/1, which I proposed, having used it to good
> effect in porting programs between several different Prolog dialects.
> (There's an inferior substitute, prolog_flag, which muddles up
> properties of the implementation which can't change and user-assigned
> properties which can, and it still doesn't have all the things
> environment/1 had.)  To this day we don't have an equivalent of Common
> Lisp pathnames, despite me proposing it and offering the Quintus 
> version
> as a model (not a constraint).  To this day, the Prolog standard 
> doesn't
> include any form of coroutining, so it was obsolete the day it was
> issued (and I really can't port the coroutining code I'd written 
> between
> the different Prologs available to me that have it, so I don't write
> that stuff any more).  To this day, we don't even have the most
> elementary foreign function interface in the standard, although there
> was for a time a de facto one.  All of these things were obvious needs
> back in 1986.
>
> And so it goes.  Stability at the basic language level for Prolog would
> *not* have been a barrier to progress.  On the contrary, putzing around
> with the language was something the ISO committee did *instead* of 
> progress.
>
> Not every change, not even every well-intentioned change, is progress.
> Changes must be examined on their merits, not accepted uncritically
> just because they are offered in good faith to address a real problem.
>
>
Roel Wuyts                                                   Software 
Composition Group
roel.wuyts at iam.unibe.ch                       University of Bern, 
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org