On Saturday, June 3, 2017 at 9:05:03 AM UTC-5, FortranFan wrote:
> And another point, an *important* one to consider is this: what Fortranners are calling out for, almost poor souls making desperate pleas, is mostly a *subset* of capabilities that the scientific/technical world have found useful, based on well over a couple of decades of experience with other languages (C++, Java, etc.) and it is utterly shameful, despicable almost, when the language cannot include such 'goodies' for the coder. Come on, who in this day and age would not like a built-in 'string' class in Fortran! And what science is there to put one together!? Why is it such a big deal for Fortran 202X when other languages managed to achieve it over 40 to 60 years ago!? Similar to 'string' facilities are a few other things - container classes such as lists, stacks, etc. (and convenient iterators with them) and some algorithms e.g., sorting - that many Fortranners can do with 'standard' ways of working.
>
> As I have indicated many times before on this forum and elsewhere, the importance of 'standardized' APIs cannot be stressed enough in this day and age, at least for many of the well-established, almost mundane, tasks that coders require regularly in their work. Nothing will distract and distress a coder more to find some operation being different in one place vs another for something as trivial and rudimentary as 'string' e.g., chars() operation in StringiFor (
https://github.com/szaghi/StringiFor) versus aniso_varying_string (
http://www.megms.com.au/aniso_varying_string.htm), no offense to the brilliant authors of these libraries :-)
>
> Fortranners are already considerate and compromising enough to seek a rather limited range of 'intrinsic' capabilities. It is high time the language served them well.
Fortran Fan and others.
Many of the issues discussed in this thread are the same ones covered in a
thread I started last year. Unfortunately Life as it has a nasty habit
of doing got it the way and I couldn't pursue it until now. I would like to
add the following points etc. to the discussion.
1. I totally agree with the opinions expressed about the lack of intrinsic support for things like lists, stacks etc. and sorting algorithms. Modern solution methods in areas such as Computational Fluid Dynamics and Computational Structural Mechanics use unstructured grid systems that do not map easily to arrays. Therefore things like lists, trees and hash tables etc are required for a variety of tasks like sorting/renumbering and finding nearest-neighbors. Yes there are plenty of third party packages that can do these tasks but many of them are encumbered by a license or copyright that makes it either impracticle or impossible to use in your code. It also means that you must distribute these packages with your code and require the reciever of the code to build those packages along with your code. As someone who was tasked to maintain some large simulation codes (usually written in C++) that used a large number of 3rd party packages, I can tell you that the biggest issue I had was with packages that required a particular version of a system library that was either older or newer than the one available on the system I was building on. This issue does not occur if more of the functionality needed for things like standard ADTs (lists etc) that anyone who has written anything more complex than "hello world" knows should be an intrinsic capability in the language.
2. A standard response from the compiler developers appears to be "it's too hard". To me this is just a "dog ate my homework" excuse for not reaching out to the the user community and finding what their ultimate customers really want and implementing those capabilities before implementing what they and their fellow developers think is "cool" or fits into THEIR vision of what Fortran should be.
Your doomed to fail from the start if you refuse to take on the difficult as well as the easy. In the words of a popular song from the WW II generation, "the difficult we'll do right now. The impossible will take a little while". I think that this "it's too hard" attitude is why 12 plus years after the F2003 standard was released we still only have a handfull of compilers that are compliant (and those still have bugs that make using some of the more useful new features from the standard unreliable). The situation with F2008 is even worse. There is no excuse for the IBMs, Intels, and Nvidia/Portland Groups of the world who all have net worths that exceed the sovereign wealth funds of many nation states on this planet to take more than a couple of years to generate a fully compilant (and mostly bug free) compiler.
3. Several people call for enhance Generic Programming support although I think what they really want is support for static polymorphisim (ie. an STL like library). My stance on this is that if more things (again like ADT's) were
made an intrinsic part of the language the need for an STL like capability goes away or is greatly diminished. I personally would like to see more emphasis placed on making Fortran MATLABs older but still smarter and faster brother. By this I mean intrinsic interfaces (and note I say interfaces and NOT implementation) to standard linear algebra routines. Give me a standard interface that would work for whatever package I chose to use (LAPACK, MKL, IMSL etc) so I wouldn't have to use preprocessors directives etc. to handle the various different interfaces for the same procedure
4. I'll close with a suggestion regarding an intrinsic list implementation and invite both the compiler developers and fellow users to comment and add their own ideas. My requirements for an intrisic list capability are as follows.
a. It should relieve the programmer from ever defining, manipulating or even being aware of the recursive pointers commonly used in the standard list implementations you see in your algorithms and data structures texts. In my experience, pointers are inherently evil and should be avoided at all cost. In my experience implementing lists in Fortran, its the recursive pointers that always bite you in the rear end.
b. The syntax should be just an extension of something that already exists in Fortran. Along this line, I think a combination of the existing TYPE statement with elements of the current string handling capability would provide the basis for a workable intrinsic list capablity that would be immediately recognizable and usable to users. Here is what I have in mind.
The TYPE statement (or alternatively a dedicated LIST statement) would be used to create either a simple list of intrinsic types (Integer, Real etc).
Examples
TYPE(Real64), LIST :: mylist
or just
LIST(Real64) :: mylist
Similarly, a list of derived types would be
Type mymapenode
Character(LEN=3) :: key
Integer :: keyindex
End Type
LIST(mymapnode) :: mylist
While I would be willing to just have a circular list since I find it the most useful, an alternative ACCESS or LINK parameter could be used to select between single link or circular (double) link
ie Type(Real64), LIST, LINK=Single :: mylist = NULL_LIST
c. prepending and appending to the list would follow the current string concatenation procedure
mylist = 1.0 ! would set initial node
mylist = mylist//3.0 would add 3.0 to the end
mylist = 4.0//mylist would prepend 4.0 at the front
d. Iterating through the list would be the same as interating through a string
(ie using the start:end syntax).
example extracting the first 3 items in a list just be
newlist = mylist(1:3)
c. A set of functions that are analogs to the string functions (INDEX, VERIFY,
SCAN etc) could be used to search lists for specific values. For the case of
a derived type node you would probably need something like a COMPONENT
to specify which component you want to search on. Also functions analogous
to TRIM, ADJUSTL, ADJUSTR etc would be needed to shrink the lists to recover
unused memory etc.
I think that this approach has advantages over an implementation that defines an intrinsic container and dedicated iterators because it builds on existing capabilities and concepts instead of just mimicing implementations in other languages. I would also hope (but realize its probably impracticle) that some
of the existing compiler code dedicated to strings could be refactored to handle strings because what is a string really but a list of characters.
Just my 2 cents.
RW