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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c4cb2c432feebd9d X-Google-Thread: 1094ba,c4cb2c432feebd9d X-Google-Thread: 101deb,15c6ed4b761968e6,start X-Google-Attributes: gid103376,gid1094ba,gid101deb,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!news3.google.com!news.glorb.com!newsfeeds.ihug.co.nz!ihug.co.nz!ken-transit.news.telstra.net!ken-in.news.telstra.net!news.telstra.net!news-server.bigpond.net.au!53ab2750!not-for-mail From: "robin" Newsgroups: comp.lang.ada,comp.lang.fortran,comp.lang.pl1 References: <0ugu4e.4i7.ln@hunter.axlog.fr> <%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net> Subject: Re: Ada vs Fortran for scientific applications X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <5H9dg.10256$S7.9566@news-server.bigpond.net.au> Date: Thu, 25 May 2006 03:40:49 GMT NNTP-Posting-Host: 144.134.49.43 X-Complaints-To: abuse@bigpond.net.au X-Trace: news-server.bigpond.net.au 1148528449 144.134.49.43 (Thu, 25 May 2006 13:40:49 EST) NNTP-Posting-Date: Thu, 25 May 2006 13:40:49 EST Organization: BigPond Internet Services Xref: g2news2.google.com comp.lang.ada:4439 comp.lang.fortran:10227 comp.lang.pl1:1688 Date: 2006-05-25T03:40:49+00:00 List-Id: "Dr. Adrian Wrigley" wrote in message news:pan.2006.05.24.17.53.03.81353@linuxchip.demon.co.uk.uk.uk... > On Wed, 24 May 2006 17:12:55 +0000, Dick Hendrickson wrote: > > Dr. Adrian Wrigley wrote: > >> On Wed, 24 May 2006 15:19:23 +0000, Dick Hendrickson wrote: > >> > >> > >>> > >>>robin wrote: > >>> > >>>>"Dick Hendrickson" wrote in message > >>>>news:PkHcg.90575$Fs1.7198@bgtnsc05-news.ops.worldnet.att.net... > >>>> > >>>>>Ada's is surely better. Knowing that a subscript has to be > >>>>>in range, because it's checked when a value is assigned to > >>>>>the subscript variable, has to be more efficient than what > >>>>>Fortran can do. In general, Fortran has to check the value > >>>>>of the subscripts on every array reference. > >>>> > >>>> > >>>>It can do this only if it is a compiler option. > >>>>It is not a feature the language. > >>> > >>>There's a ambiguous "it" in those sentences. ;) > >>> > >>>But, if "it" refers to Fortran, subscript bounds rules > >>>ARE a feature of the language. You are NEVER allowed to > >>>execute an out-of-bounds array reference in a Fortran > >>>program. > >> > >> ... > >> > >> So what does the standard say must happen if you attempt > >> such an access? Can a program fail unpredictably under > >> such (rather common!) circumstances - as routinely happens > >> in C and C++, sometimes at great cost? > > > > The Fortran standard says nothing at all about what must > > happen for most run-time errors. There is a requirement > > that a compiler be able to diagnose syntax-like errors at > > compile time. There is also a requirement that some > > (unspecified) I/O errors and some memory management errors > > be checked for at run time. The job will abort unless the > > program uses one of the error detection methods. But for > > things like subscript bounds errors, or subroutine argument > > mismatches, the standard doesn't impose anything on the > > compiler. > > ... > > > The other big problem with [old] Fortran programs was > > messing up the argument list in a procedure call. > > Separate compilation made this a lot easier to do. > > The Fortran 90 addition of MODULES essenially closes > > this hole. Most procedure interfaces now can be explicit > > and the compiler must check for calling consistency. > > It's harder to shoot yourself in the foot now, but > > people can still lie to the compiler. > > I think this is an area that Ada really shines. The standard > requires numerous checks for consistency at both compile > time and runtime. Versions of code that don't match properly > can't be linked together or can't be run together (as appropriate). > Using the language gives a feeling of integrity of coding, > with mistakes often being caught very early on. > > Unfortunately, the language features for integrity cannot > be added to an existing language without breaking old > code. That was not the case for Fortran. Old Fortran codes can still run, even though the language now provides the means for consistency checks. > This is because the integrity features are often a result > of prohibiting "dodgy" code, flawed syntax or misfeatures. > The history of the C family of languages illustrates this. > I'm not sure where modern Fortran sits in relation to > its forbears in terms of safety and security though. > It's noteworthy that Ada and Fortran are on convergent > paths (modules, user defined types, templates etc). > > With array subscripts, an exception must be raised if the > bounds are exceeded. As is the case with PL/I (given that the programmer has enabled that check). > The same with arithmetic operations. > (curiously, compiling Ada under gcc (GNAT), a compilation > switch is needed to be standards compliant - a mistake:(). > The checks can be switched on and off in the source code > as desired. As is the case with PL/I. > One of the benefits of the compile- and run-time checking > is that refactoring code becomes much easier because the > compiler will usually tell you about what parts haven't > been fixed up yet. Languages like C or Perl are at the > opposite end of the spectrum, I find. From what I read here, > Fortran is somewhere in between.