[mercury-users] Re: Sockets

[Richard A. O'Keefe]

	The thing I find most frustrating about the Prolog world is that
	every vendor does things differently and (for my money) incompletely.
	My language gets really mediaeval trying to port systemsy code from
	one Prolog platform to another.  Why of why didn't the standards
	committee sort all this out with a decent set of library spec's?
	
Because first the BSI committee and then the ISO committee spent most of
their time trying to make the language over again in their own interests.
I proposed the maxim 'non calcitrandus in dentes artifex' (the workman is
not to be kicked in the teeth) and that the committee adopt the C
committee's policy of not breaking existing working code if they could
avoid it, and that was _explicitly_ rejected.

Just one example:  I had a proposal for an 'environment' predicate that
I had set up at Quintus to ease porting between Quintus Prolog, LPA
Prolog, SICStus Prolog (0.7), NU Prolog, and Open Prolog, and between
different operating systems.  For example,

	environment(integer(overflow(X)))

->	X = truncate if integer overflow is treated modulo 2**N
	    (N can be discovered from another predicate)
	X = limit if 'saturating' arithmetic is used
	X = float if arithmetic switches over to floating point
	    mode when integer overflow occurs
	X = error if integer overflow raises an exception

	environment(file_type(source,Ext))

->	Ext = pl, or pro, or whatever your system prefers for the
	extension of a Prolog source file.
	    

The committee weren't interested, as far as I know never ever listed it
amongst their documents, and _certainly_ didn't provide anything even
close to it.  

More charitably, the committee rightly saw that a library needed to be
built on top of a module system, and decided to develop the module system
specification first.  If people spent years reinventing square wheels
with basic things like integer/1 (which at one time was specified to
abort if passed a variable!), you can easily imagine that designing and
agreeing a module system occupied enormous amounts of time and energy.

You will note that there is no standard package for TCP in C89, C9x,
C++ (yet to be determined), or Fortran 95.  Heck, none of these
languages even has a standard way to control an ANSI terminal.  (See a
recent thread in comp.std.c.)  There _is_ suitable stuff in Erlang/OTP;
it will be very interesting to see what if anything happens about
library modules if/when the current 'Standard Erlang' draft is put to
a committee for turning into a 'real' standard.