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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b386f2cc2e9ff212 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-11-02 13:15:54 PST Newsgroups: comp.lang.ada Path: bga.com!news.sprintlink.net!howland.reston.ans.net!agate!overload.lbl.gov!lll-winken.llnl.gov!noc.near.net!inmet!spock!stt From: stt@spock.camb.inmet.com (Tucker Taft) Subject: Re: Interfaces.Ada Message-ID: Sender: news@inmet.camb.inmet.com Organization: Intermetrics, Inc. References: <39602v$3rl@felix.seas.gwu.edu> <396agd$9bt@network.ucsd.edu> Date: Wed, 2 Nov 1994 06:24:06 GMT Date: 1994-11-02T06:24:06+00:00 List-Id: In article <396agd$9bt@network.ucsd.edu>, Matt Kennel wrote: >Michael Feldman (mfeldman@seas.gwu.edu) wrote: >: >will work)? I am using Sun Sparc. Thank you. > >: I think Robert Dewar has commented on the best way (currently) to >: interface Fortran programs to GNAT. Interfaces.Fortran, and especially >: the data structures interface - which will provide column-mapped >: multi-dimensional arrays, etc. simply has not been implemented yet. > >I've always wondered about one thing: > > When people make new langauges why do they implement the C storage > layout for multi-dimensional arrays instead of that of Fortran? E.g. > as it seems, Ada9x, Modula-3. Note that Ada doesn't "implement the C storage layout" for arrays. Ada 83 doesn't specify the order. However, implementors naturally have chosen the layout implied by the way that array aggregates are written, where the second index varies fastest as you move through memory. For example, in the following array aggregate: ((1,2,3), (4,5,6), (7,8,9)) One would naturally expect the second dimension to vary fastest, by just looking at the syntax for the aggregate. But to reiterate, there is nothing in Ada 83 that requires a particular layout. In Ada 9X, the Convention pragma may be used to specify Fortran-style array layout. Also, it is a bit funny to call the non-Fortran order the "C storage layout" for multi-dimensional arrays. C was certainly not the first language to vary the last dimension fastest. Algol 60 used the non-Fortran order (or at least suggested it in the same sense that Ada's array aggregate notation suggests it). So it has a long history, though clearly not as relevant a history as Fortran's choice to modern numerics. It is also of course possible to simply reverse the indices when defining and using a multidimensional array in an implementation that has the non-Fortran order, so it doesn't seem like an insurmountable barrier in any case. > Given that most matrix algorithms are in Fortran why be backwards? (and > ones in C usually use some sort of non-compatible dope-vector thing anyway > because C doesn't have variable matrix sizes.) Calling the non-Fortran order "backwards" reminds me of the typical non-Britisher comment about the "backwards" nature of the British drive-on-the-left rule ;-). > Why not make the default just like Fortran? I don't think one way is > particularly more "natural" than the other so now that Fortran chose one > convention why not stay with it? The array aggregate notation suggests that the non-Fortran order is somewhat more natural in Ada. > The only thing I can figure out is that it is a childish attitude > like "bleah fortran sucks so we'll be different". I don't believe this > is true so what is the real reason? Is it that compelling? It didn't come out of any desire to be different. I believe it was simply that Ada comes more from the Algol school of languages than the Fortran school of languages. >: Mike Feldman > >-- >-Matt Kennel mbk@inls1.ucsd.edu >-Institute for Nonlinear Science, University of California, San Diego >-*** AD: Archive for nonlinear dynamics papers & programs: FTP to >-*** lyapunov.ucsd.edu, username "anonymous". -Tucker Taft stt@inmet.com Intermetrics, Inc. Cambridge, MA 02138