Re: basic question on nested packages

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

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
> 
> The current Ada Lapack binding has the following 4 packages
> that maps to the above, and a package for IO, like this:
> 
> labase.ads  (provides only data types)
> 
> ladrv.ads (the drivers API's, WITH labase;)
> laaux.ads (the auxillary API's, WITH labase;)
> lacmp.ads (the computional API's, WITH labase;)
> 
> then an IO package
> labaseio.ads, labaseio.adb (WITH labase;) provides IO routines
> for the lapack Ada types.
> 
> So, a client Ada program that wants to use lapack's driver
> routine say SGESV() would do
> 
> -------------------
> with labase; use labase;
> with ladrv;
> ....
>     A    : labase.Fortran_Real_Matrix (1 .. 3, 1 .. 3);
>     ladrv.SGESV(...)
> ------------------------
> 
> What I think would be better is to have ONE lapack package and
> with the above packages as nested packages. So that a client
> program would do
> 
> -------------------
> with lapack;
> 
> ....
>     A    : lapack.Fortran_Real_Matrix (1 .. 3, 1 .. 3);
>     lapack.driver.SGESV(...)
> ------------------------
> 
> i.e. a client would only need to WITH one package, and
> access the other packages using a dot from that one base package.
> 
> 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?

If there is no risk of ambiguity, and a client program typically needs
to "with" both lapack and lapack.driver, it seems much simpler to me to
put all the stuff that a typical client will use directly in package
lapack, and not to divide it into some nested or child packages like
lapack.driver.

Note that the body of package lapack can still delegate the
implementation of an operation like SGESV to a child package (using a
renaming as body, for example), if the package body otherwise risks
becoming very large. On the other hand, this code is probably not
rapidly evolving, any more, so even a large body is unlikely to become a
maintenance problem.

I'm not a LAPACK user, so I don't know anything about its internal
architecture. If there are some internal items that are not used by
normal client applications, you can put them in child packages, e.g.
lapack.com, lapack.aux. An unusual client that needs to use that stuff
directly can "with" these child packages (unless they are declared
"private").

> I do not know much about Ada packaging and such, so wanted to ask
> the experts what they think. Woukd nested packages be the answer,
> or some other stucture? or should the API be left as is?

A hierarchy of child packages is definitely nicer than the old set of
four unrelated packages, IMO. But I would seriously consider using just
one package, at least just one "front" package that contains all the
things a normal client will use.

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