From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,859116256d0a7bc2 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.224.219.205 with SMTP id hv13mr1587205qab.5.1343789444764; Tue, 31 Jul 2012 19:50:44 -0700 (PDT) Path: a15ni14517852qag.0!nntp.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nrc-news.nrc.ca!goblin1!goblin3!goblin.stu.neva.ru!news-1.dfn.de!news.dfn.de!news.informatik.hu-berlin.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: basic question on nested packages Date: Sat, 28 Jul 2012 15:19:56 +0300 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 X-Trace: individual.net 9wLIe13iXUT48j8WwFzs6QVaohuri0kgIaZQGVhBEgLeGThf830ZP8y4tlj9CwUaxZ Cancel-Lock: sha1:Pl8NLP/TTAgfYUtS7r5haLJ5zWU= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: X-Received-Bytes: 4697 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: 2012-07-28T15:19:56+03:00 List-Id: 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 . @ .