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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.linkpendium.com!news.linkpendium.com!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 16 Aug 2019 14:11:03 -0500 Subject: Re: The answer to "Can Ada replace FORTRAN for numerical computation? Newsgroups: comp.lang.ada References: <3862f4a3-d3b2-4959-b6f4-08086738df2c@googlegroups.com> From: Norman Worth Date: Fri, 16 Aug 2019 13:11:02 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Message-ID: X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-Z1Kt4QBOC9V01p/pBVLRIHYFYKA/mLVhdwo4ZySO2i4L3C7sEOL5ltiHyizDaht1VScLE8KCCIKKRjo!OwRL+XyXfkpTfbXcX56bv0fpX33c4rISbsa5Hqa9NEys7lp6kvAc+kO5yj+4BKtIZ17XGycLd7M/ X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 9670 Xref: reader01.eternal-september.org comp.lang.ada:57068 Date: 2019-08-16T13:11:02-06:00 List-Id: Optikos wrote: > On Wednesday, August 7, 2019 at 1:35:33 AM UTC-5, Niklas Holsti wrote: >> On 19-08-05 20:15 , Optikos wrote: >>> On Monday, August 5, 2019 at 9:35:10 AM UTC-5, Shark8 wrote: >>>> On Saturday, August 3, 2019 at 6:30:36 AM UTC-6, Nasser M. Abbasi >>>> wrote: >>>>> There are also significant limitation to Ada as a language for >>>>> scientific computation, in particular with regard to dynamic >>>>> typing and storage allocation. >>>> >>>> I think this is referring to things like dynamically-sized arrays, >>>> rather than "X is an integer there, now it's a String!" when >>>> talking about dynamic-typing, as it's obvious that the latter would >>>> obliviate the aforementioned properties of finding conceptual >>>> errors. >>> >>> But there are 2 usages of considering something an integer for the >>> moment in a few lines of code. One is to floor-truncate a floating- >>> or fixed-point number to an integer; Ada supports syntax for this >>> semantic meaning. >> >> Yes of course. >> >>> But another is to consider a floating-point >>> representation as a machine-word to perform integer-based bit >>> twiddling to conform the representation of the floating-point number >>> to some machine requirements or machine representation that Ada's >>> syntax and semantics lacks; pre-1995 Ada (the subject matter of the >>> paper referenced) was abysmal at this commonplace use case in >>> Fortran, PL/I, and C. >> >> No, record types with representation clauses plus Unchecked_Conversion >> were fully able to handle this case, already in Ada 83. >> >>>> As to the storage-allocation, I suspect it is also referring to Ada >>>> arrays needing definite bounds in certain cases -- the ability to >>>> return properly-sized arrays from a function *should* be enough to >>>> ease this complaint *EXCEPT*, perhaps, when dealing with Very Large >>>> Arrays. >> >> They may also have been scared by the "Unchecked" in >> Unchecked_Deallocation. The identifier "free" is so much more friendly >> and safe-sounding... >> >>> Again, Ada has had a storage-pool wisdom at the heart of its storage >>> allocation strategies, but pre-1995 Ada staunchly lacked PL/I's and >>> Fortran's and C's ability to ecumenically reach out and >>> read/write/manipulate some other language's in-memory storage format, >>> as a I-got-you-covered system-programming duty. >> >> I doubt your statement. …, and you can do any format manipulations you >> want with Ada 83 as well as with Fortran or C. Please show a >> counter-example if you insist on this point. > > https://gcc.gnu.org/onlinedocs/gcc-4.8.1/gnat_ugn_unw/Representation-Clauses.html > > Before we dive into a counter-example in source code for various languages, let's start, as linked above, with the Ada community speaking for itself regarding Ada83's lackluster (i.e., lack of clear mandate regarding) representation clauses. Indeed, as mentioned in recent months on c.l.a., Janus/Ada to this day does not fully support some semantics of representation clauses, even after all these decades. A programming language is not what merely is on paper in its standard, especially when noncompliance with the content of the standard is overtly permitted by the (excessively-)permissive specification of the language in the standard. > > (And not all the tarnish of representation clauses was polished off by Ada95 either, according to the commentary linked above.) > >> There is nothing in Fortran or C that supports "other languages' formats" > > Again, a language is more than merely being a bag of features overtly stated via extant text in its standard or specification •document•. Indeed, Fortran, PL/I, and C are famous & popular (and should I say, notorious & infamous) for the breadth of their permissiveness regarding in-memory layout, and lack of staunch regulation of semantics in general. Hence, what is elided from being stated in the standard's extant text in order to ••enact the permissiveness•• is far more important on this inter-language use-case than any word, clause, sentence, or paragraph that overtly appears as text in the standard or specification of the loosey-goosey languages. > > Furthermore, your statement is clearly factually incorrect regarding Fortran 2003's overtly-specified feature-set for inter-oping with C •directly• without the need for a Fortran wrapper anymore, which was the technique that was extant at the time of the 1980 paper that started this whole thread. (These same low-level-layout system-programming techniques in Fortran were utilized by Prime Computer back in the day that they wrote whole operating systems in Fortran IV as a poor-man's system-programming language prior to switching to PL/P, which was their dialect of Multics PL/1.) For a summary of Fortran 2003's standardized intimate binding with C nowadays, please see slide 10 of: > https://ModelingGuru.nasa.gov/servlet/JiveServlet/previewBody/1361-102-6-1755/Introduction_F2003.pdf > > And of course we could dive into the Fortran standard documents themselves regarding their evermore-extensive inter-op with C: > https://gcc.gnu.org/wiki/GFortranStandards > Some ancient history. In olden times there were, by edict of the great lord IBM, two kinds of computers: one kind for scientific us, like the IBM 704, and one kind for business use, like the 702. (The fact that people paid little attention to the edict and used whatever worked is beside the point.) Most programming was done in machine language (octal code). Then assemblers and assembly language were developed, which greatly eased programming and increased both productivity and accuracy. But assembly language was still a specialized skill limited to an elite priesthood. Someone thought IBM could make more money if programming were still easier. A higher level language with machine translation to octal code was suggested. But the priesthood objected that they could write programs which would run as efficiently as possible, something that no machine translator could do. After all, speed and memory usage were critical for scientific work. Thus came about FORTRAN, which has as a design criterion that the code it produced be at least as efficient as the code produced by an expert assembly language programmer. At least through Fortran 77, efficiency was always the primary objective for the Fortran language and its compilers. Most compilers (not all) were pretty good at it, and Fortran gained a reputation as the number crunching language. Depending on the computer and the compiler, it may or may not have deserved it. This was not the case with Ada, which had much broader objectives. The main ideas of Ada were reliability and applicability to large systems. That has some costs. Even with internal checks turned off, Ada has always been a little slower than Fortran at number crunching. It hasn't been enough to make much difference, but its there. But Ada is generally more safer, more reliable, and arguably more versatile and easier to program, especially in large systems. As for the complaints listed, although Ada's strong typing requires more planning, most people look at it as an asset. As for creating dynamically sized arrays and returning them from procedures, Ada can do that, although it is more verbose and takes a bit more planning: with ada.text_io; use ada.text_io; procedure ar is type a is array(integer range <>) of integer; type ap is access a; P : ap; procedure da (i : in integer; j : in integer; p : out ap) is begin p := new a(1..i); p.all := (others => j); end; begin da (4, 10, P); put_line (P(4)'image); da (10, 4, P); put_line (P(10)'image); end; (Note that since Ada does not have a "free" verb, memory management is a bit more complicated, requiring "uncontrolled deallocation", which is type sensitive, to explicitly deallocate the memory for each instance of P. But Ada will take care of deallocation nicely when P goes out of scope at the end of the procedure.)