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.66.80.166 with SMTP id s6mr517971pax.30.1343789445361; Tue, 31 Jul 2012 19:50:45 -0700 (PDT) Path: g9ni7594066pbo.0!nntp.google.com!npeer01.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!goblin2!goblin.stu.neva.ru!news.adamant.net!volia.net!news2.volia.net!feed-A.news.volia.net!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 16:34:52 +0300 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 X-Trace: individual.net kSjsibESVPS4ENDK8tx2HwB5id1BA5+wfQ8GtMIH6kQBp0v9eWq8L9ut3xQw3ND6kx Cancel-Lock: sha1:r/WMGuJy/MzSp/4pIZJ7cwGT4wg= 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: 4258 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: 2012-07-28T16:34:52+03:00 List-Id: 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 . @ .