Re: Standard Library Interest?

[Stephen Leake <Stephe.Leake@nasa.gov>]

Stefan Lucks <lucks@th.informatik.uni-mannheim.de> writes:

> I like the baby-step proposal. 
> 
> However, such a standard library would rather be a collection of different
> sublibraries (typically packages), and the interfaces would not always be
> consistent. That is unavoidable, 

Perhaps "really expensive", or "hard to achieve". It is _not_
"unavoidable". I hate all absolutes :).

> and most programmers could live with that. (Even e.g. the JAVA
> library is not always consistent, though its designers did seriously
> try ...)

Which is one reason I don't like the Java libraries. But a lot of
programmers do live with them. 

It would be a great selling point if the Ada library did _not_ have
that problem!

> One problem with any library is that you may be using different
> versions on different platforms. 

Why would that happen? The Gnu tools manage many platforms with no
version problems. Well, some poorly-supported platforms may take a
while to catch up to the latest version, but "gcc 2.8.1" means the
same thing on all platforms.

> Another problem is that if you fetch the library from some web site
> (which is assumed for the baby-step propoal), you may first want to
> check if it runs in your environment at all.

Yes, which is why all library packages must come with complete tests.
Again, the Gnu tools typically come with tests (well, the compiler
doesn't, but the others do). Yes, this is more work, but it is what
makes the library usable.

> One thing that might significantly improve the acceptance for such a
> collection of (sub-)libraries would be to support a *standartised*
> *interface* at least for
> 
>   1. a unit test for the package and

I find Aunit to be a good unit test framework (see
http://savannah.nongnu.org/projects/grace/ for a working example).
 
>   2. checking the current version number of package

We could require each top-level package to provide a Version function,
that returns a string. Also follow the Gnu convention of including
that string in the tar.gz file name for distributions.

> This would help people to actually integrate these library packages into
> their stuff, doing automatic unit and integration tests ...

yes. Note that SAL (http://www.toadmail.com/~ada_wizard/) does this.
So let's all just use SAL :).

> Also, this does not seem to hinder the integration of already existing
> libraries into the standard library:
> 
>   --  Dealing with the version number is trivial, anyway.
> 
>   --  Assuming the authors of the already existing library did implement 
>       unit tests for their library at all, writing one additional 
>       procedure for doing the full unit test can't be too difficult.

Well, switching from one unit test framework to another is painful.
For example, most of the SAL unit tests do _not_ use the Aunit
framework, because I discovered that late in the process. The
non-Aunit tests write output files, which are diffed (by the Makefile)
against known-good output files. It is a _major_ amount of work to
change those tests to Aunit style. But as long as the Makefile can
return a Pass/Fail status, it doesn't matter too much.

More important are things like standard names for common operations;
do we "Add" an element to a container, or "Insert" it? That's a major
problem for integrating existing code. SAL attempts to do this, but
doesn't fully succeed.

> Consider you *with'ed* the package "some.weird.package_name" from
> the standard library. Without having to look into either source code
> or other documentation, I'd like to compile and then run a unit test
> by calling:
> 
> 	some.weird.package_name.Full_Self_Test(0);

The unit test code does _not_ belong in the package itself. If it is,
it would be included in every delivered executable; major waste of
space. It should be in a child package.

But it's really not reasonable to define unit tests at this level.
Many unit tests require auxiliary packages, which should _not_ be
children (see SAL for examples). Providing a Makefile that runs the
tests and produces a pass/fail is much more reasonable.

> Checking the version number should be done similarly. You can't always
> prevent version skew, but can automatically detect potential
> problems.

Hmm. I guess you mean one package depends on specific versions of
other packages, and you want to check that at run-time (or better,
compile time). That problem is solved by tools like Redhat Package
Manager (rpm); it's a big problem, and we should not try to invent new
solutions. 

Just an example of the kinds of discussions an integrated library
committee will be having ...

-- 
-- Stephe