From rabin@osf.org Wed Jun 23 06:22:58 1993
Received: from postman.osf.org by dkuug.dk with SMTP id AA05262
  (5.65c8/IDA-1.4.4j for <SC22WG15@DKUUG.DK>); Wed, 23 Jun 1993 16:22:52 +0200
Received: from bubba.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA19832; Wed, 23 Jun 93 10:23:00 -0400
Received: by bubba.osf.org (5.65/4.7) id AA27263; Wed, 23 Jun 93 10:22:58 -0400
Date: Wed, 23 Jun 93 10:22:58 -0400
From: rabin@osf.org
Message-Id: <9306231422.AA27263@bubba.osf.org>
To: keld@dkuug.dk
Subject: Re:  POSIX LIS
Cc: SC22WG15@dkuug.dk, rabin@osf.org
X-Charset: ASCII
X-Char-Esc: 29

Keld,

The discussion of LIS at the WG15 meeting in Heidelberg was focussed entirely
on the US report that IEEE PASC is considering dropping its requirement that
an LIS be produced for each POSIX standard (1003.1 and its amendments).  Your
contribution was assigned the number WG15 N376, but there was no substantive
discussion of it.  There was, however, a request for Member Body input on
possible alternate LIS methods (action item 9305-45), and perhaps your
contribution could be considered within that discussion at the next WG15
meeting.

My own opinion is that, while it would be very good to have such a concise
binding, there are some problems with the approach that you suggest.  In
your proposal, the binding for a function is simply the function syntax
itself.  This means that there must be a clear one-to-one correspondence
between the language-independent operations and the functions for the
C binding (and also all other bindings), and for each operation there must
be a clear one-to-one correspondence between the parameters of the 
language-independent operation and the arguments of the C (etc) function,
and of the datatypes, and the mappings of values must be clear and obvious
in each case.  This has the effect of constraining the LIS to be the same
as the C binding, and hence also all other bindings the same as the C
binding.

One goal of the existing POSIX LIS work was to remove those features of
9945-1 that are only appropriate for the C language, such as overloaded
functions and parameters, and to allow the possibility for binding to a
language with strong typing.  This has the effect of making the
correspondences between the LIS and the binding no longer one-to-one or
clear and obvious, and for this reason we have the need for new names
for the LIS features (operations, datatypes, parameters, etc.), and for
explicit correspondence tables between the LIS features and the binding
features.  In some cases these correspondence tables are trivial.  But
in other cases they are not.

I agree that the current draft of 1003.16 (the "not thin enough" C binding
to 1003.1(LIS)) still includes some redundant specification which should
be removed, especially in the Returns sections.  But it is not possible 
to remove everything, since, for instance, different functions use different
values to indicate errors, and this must be specified.  If you have
identified redundant text in 1003.16/D3 that you think can be removed,
please send me detailed comments, and I will use the information to
prepare the next draft (if it is decided that there should be a next draft,
of course!).

There is no e-mail list that currently has discussion of these topics.  Why
not use the WG15 reflector?  I hope that WG15 members will have some
interest in this subject.  

	-Paul