Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Optikos <optikos@verizon.net>]

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