Re: basic question on nested packages

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 12-07-28 15:52 , Nasser M. Abbasi wrote:
> On 7/28/2012 7:19 AM, Niklas Holsti wrote:
>> On 12-07-28 06:22 , Nasser M. Abbasi wrote:
>>> I'd like to improve the structure of the Ada lapack binding
>>> to make it easier to use.
>>>
>>> The official Fortran lapack is structured as follows
>>>
>>>                                 lapack
>>>                                   +
>>>                                   |
>>>                  +----------------+-------------------+
>>>                  |                |                   |
>>>               driver routines    computational     auxiliary
>>>
> 
> ....
>>>
>>> Hence it will be, for the API's
>>>
>>>     lapack.driver.foo()
>>>     lapack.comp.foo()
>>>     lapack.aux.foo()
>>>     lapack.IO.foo()
> 
>>
>> I'm going to play devil's advocate and ask why you don't put it all in
>> one package, lapack.
>>
>> Is there any benefit to writing a call as "lapack.driver.SGESV" instead
>> of directly as "lapack.SGESV"? Is there some risk of ambiguity, with the
>> name SGESV defined with different meaning in the different packages?
>>
> 
> Main reason is just to keep things organized as in the Fortran tradition
> of the original lapack:
> 
> http://www.netlib.org/lapack/lug/node22.html
> 
> "
> The subroutines in LAPACK are classified as follows:
>     driver routines, ....
>     computational routines.....
>     auxiliary routines....
> "

Ok, but compare Ada.Text_IO: there are subprograms to input data, to
output data, and to open/close files. These can be considered to be of
different "classes", but the Ada authors did not define separate
packages for them, so that we would have, for example,
Ada.Text_IO.Inputs.Get_Line, Ada.Text_IO.Files.Open, and so on.
(Granted, child packages did not exist at the time time Text_IO was
defined, but still I would consider such a child-package system to be
overdesign.)

In other words, while this classification of LAPACK subroutines no doubt
makes it easier to understand and learn to use LAPACK, I still don't see
why it would be good to embody this logical classification as a package
hierarchy. If a user has already decided to use the SGESV subprogram, I
don't see any benefit in forcing the user to "with" lapack.driver in
addition to lapack, and to write lapack.driver.SGESV instead of the
shorter name lapack.SGESV.

It could be useful to put the non-driver subprograms in child packages,
to emphasize that users should prefer to use the driver-level
subprograms (as suggested in the link you gave). So I would put all the
types and driver subprograms in package lapack, and the "computational"
and "auxiliary" subprograms in lapack.comp and lapack.aux, respectively.
I'm not sure about the I/O subprograms, but if most clients need them, I
would put them directly in package lapack and not in a child package.
This has the advantage that the I/O subprograms become primitive
operations for the LAPACK types and are overridably inherited in derived
types.

All this is IMO, of course, and tastes will differ.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .