From keld@dkuug.dk Wed Jun 23 19:29:30 1993
Received: by dkuug.dk id AA07620
  (5.65c8/IDA-1.4.4j for sc22wg15); Wed, 23 Jun 1993 17:29:31 +0200
Message-Id: <199306231529.AA07620@dkuug.dk>
From: keld@dkuug.dk (Keld J|rn Simonsen)
Date: Wed, 23 Jun 1993 17:29:30 +0200
X-Charset: ASCII
X-Char-Esc: 29
Mime-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Mnemonic-Intro: 29
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: sc22wg15@dkuug.dk
Subject: LIS bindings

I wrote Paul Rabin to hear what discussion there was to the Danish
input paper on LIS, and how to proceeed.

Paul wrote back:

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

I agree that this is indicated by the format of N376.

> 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 have some ideas on how to remedy this:

1. you can have multiple entries in the LIS for the same kind
of functionality, eg there could be several entries for the exec()
function, each tailored for a binding for one or more programming
languages. The LIS could then use the same notation/names for
the equvalent paramteres - positioned differently in the calls.

2. the specific binding ala .16 could be included where there is not
a clear correspondence - the obvious correspondence would be the
majority of the cases, thus making the binding much shorter.

I prefer 1. as this leaves the binding very thin, and usable
as a quick reference manual.

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

Would the error values be different from programming language to
programming language? Would there be much commonality?

One thing I missed in .16/D2 was which parameters were return 
values, could that be included?

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

Actually I think the binding style DS proposed could be
done already now for a majority of the functions, although 
then some specifications would be of the style of .16/D3
and make the document unhomogeneous in style.

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

OK, I hereby have done that.

Keld