Re: Standard Library Interest?

["Robert I. Eachus" <rieachus@comcast.net>]

Stephen Leake wrote:

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

Agreed.  I don't think that "built-in" test is necessarily a good idea 
for all libraries, but I definitely like the idea of having a standalone 
test program that does the sanity checks and diagnostics.  Note that 
this can't be boolean pass or fail in many cases.

Which brings up another point.  For many packages a tuning program is 
just as important as a test procedure.  It doesn't need to be as 
elaborate as ATLAS for BLAS in many cases, but it is often needed.  For 
example, I have a lot of random-number generators that depend on 
computing X**2 mod N fast for particular values of N.  Of course, for 
most cases a type that is appropriate for storing X mod N, is not going 
to work for computing the square.  (If System.Max_Nonbinary_Modulus is 
big enough, no problem.  Otherwise workarounds are needed.)

I've written three or four workarounds, some that are fine if they compile:

type Big_Int is range -2**(2*My_Int'Size-1)..2**(2*My_Int'Size-1)-1;

Others depend on properties of the floating point types.  A program 
designed to test these workarounds that also does timings would
be a great help to people porting the 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.

Hmmm.  Let me flesh this out a bit.

1) There must be a Version function in the top level package.
2) There may be a Version function in lower level packages.
3) There may be Current_Version string in package specifications.
4) The Version function will normally return a string of the form 
x{.y{.z}} where x, y, and z are integers, optionally followed by a date.
5) The format of the date, if present, is not specified.  But the values 
shall be such that the String comparison operations ">", etc. return the 
right results.

That last sounds complicated, but all it means is that:

     "1.2.3 May 3, 2002" and "1.2.4 March 12, 2003" are perfectly fine, 
but an additional 1.2.4 version such as "1.2.4 April 1, 2003" might not 
be.  The developer of course may have lots of candidate 1.2.4 versions 
before he releases one.  But once he does, it is better if the next 
version has a new number.

Note that even though the Version function is in the package spec, the 
implementation will be in the body.  Which is fine, since the body 
version can change more frequently.  A rule that said that changing the 
package specification should change the first component of the version 
might be nice, but I hardly think it is necessary.

Now do we encourage the ARG to do the same with Ada, System and 
Interfaces, and if so what version strings should be returned. ;-)

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

Um, it is solved for distribution of software in RPM form.  But if I 
post a short program on comp.lang.ada and it depends on a particular 
revison or later of a library, it would be nice to include the one line 
check in the soure.  If the Version function were more carefully 
specified that check could be optimized away.  Hmmm.  Maybe we need two 
version functions, one that returns a string, and another that returns 
just an integer reflecting the spec version...

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

Aren't we already having these discussions?

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig