I have little experience with Swift so not very sure, but its webpage seems to suggest that it also has built-in array (with append) and dictionary types.
Indeed, I wonder if there is any mainstream language that do not support the above two in the “out-of-the-box” manner…? (i.e., minimum/core collection types in a way bundled with their language distributions)
Also, I guess making the most basic collection types (such as python list/dict or associative arrays in other languages) on the user side causes fragmentation similar to multi-dimensional array libraries in C++. This causes unnecessary conversion and checks when using multiple libraries.
Arrays in Swift are implemented using the language’s generics (i.e. they are not core-language features). In Swift, a declaration like
var arr: [Int32] = [1,2,3,4]
is merely syntactic sugar for the declaration of a generic array that is instantiated with the Int32 data type:
var arr: Array<Int32> = [1,2,3,4]
All other collection types are implemented similarly.
We already have very efficient arrays in Fortran for numerical use cases, and that’s great. What we are lacking are more flexible collection types like the aforementioned dynamically appendable arrays (“Vectors”), Dictionaries, etc. that are very useful for building higher level data structures, especially in object-oriented programming. All of these collection types can be build efficiently with traits and generics as it was done in Swift.
Yes, as I wrote in my post, on purpose we didn’t introduce any new syntax for now.
Yes, your suggestion is one way to do this.
Actually, LFortran does not create a function call internally, this is fully optimized. We only use a function call using a magic intrinsic _lfortran_get_item in the surface language (that you write in Fortran), so that we reuse existing Fortran syntax, but internally we represent this using native ASR nodes for dictionary operations and they are then fully optimized in the backend.
So let’s design good syntax for this. How should one create a dictionary constant — in Python one uses {} for this. Should we use it in Fortran also?
Another concern is about parallelism. For future, I think it will become very important that collection types support parallel calculations efficiently. For example, the Map type in Chapel seems to support parallel manipulations natively (but sorry if I am misunderstanding its features):
Building high-performance libraries for this kind of features seems to be a big burden on the user side (particularly for application programmers like me), and depending on third-party libraries again introduces additional issues (e.g., if it is a library essentially maintained by a single person, it could become abandoned at any time when he becomes busy or move to other jobs (or even just tired), leaving bugs unfixed.) In addition, the above issue of fragmentation remains. In my opinion, in addition to strong support of generics itself, it is critically important for modern Fortran to have the most basic collection types (e.g., at least 1D array list (with append) and dict) that can be used out-of-the-box.
A native <vector> like structure in the language would be useful, as this is essentially a reallocatable array, with potentially the same perfomances than the current arrays, with some additional flexibility.
And I almost forgot to say this… thanks very much for designing the syntax of generics for the next standards! @everythingfunctional@kkifonidis I am very much looking forward to using those new features in my codes also
I assume this is your attempt at humor so I’ll let it pass. You are missing the point. For a large widely used library like MPI, the current state of Fortran requires you to build a different version of MPI for each compiler your organization wishes to support if you want to use the mpi or mpi_08 modules. This is a waste of both time and resources. The same holds true for things like LAPACK90 interfaces etc. For organizations that make money selling libraries like NAG, I would think just being able to build one or two binary distributions that would work with other compilers would be welcomed. While the NAG compiler has some nice features (mostly its error and syntax detection capabilities) they are not enough to justify an approximately $160 a year expenditure when other opitions that do about the same job (gfortran and now llvm fortran) are available.
The idea of a common module file format comes up here regularly, but I don’t understand what good it would do. There is no standard ABI or runtime library, so a library compiled with one compiler can’t be called from code compiled by another compiler. Am I missing something?
Jane Sleightholme and I have a paper called ‘Diagnostic capability of Fortran compilers’ available from our web site. Fortranplus | Fortran information The Nag compiler has been one of the best diagnostic compilers for a long time. Our background was university computing services for may years, and we generally taught with the best diagnostic compilers we had access to. In the past these included CDC Fortran, DEC Fortran, Salford Fortran and Nag fortran. When we left the university sector we continued teaching with the Nag compiler. We recommend using the best tools you have access to.
If the code is limited to C interoperability features, then code compiled by one compiler can indeed be called by another compiler (or even code that is written in another language for that matter). A standard module file format would allow a programmer to use such a library without recompiling even the interfaces for each fortran compiler.
To give an example, that would include libraries such as BLAS and LAPACK to be accessed through a USE statement without recompiling with each target fortran compiler.
As you say, to go beyond that, to allow derived type arguments, allocatable arguments, pointer arguments, and other high-level fortran features would indeed require further standardization of of the ABI for those features.
You still have the problem of calls to the runtime library in the code generated by the other compiler. Maybe you could get programs to link by linking against both runtime libraries but there would still be problems with initialization and the runtimes conflicting over resources.
To be clear, a “module file” is of use only to a Fortran compiler’s front end. If you don’t have a .mod file for compiler X, and your Fortran compilation fails for lack of it, just INCLUDE "module_source.f90" ahead of your program unit source. No information in the .mod file is used at linktime or runtime. Nobody is going to miss it once the object files are cooked. @ashe pointed at the real trouble that awaits once you mix code compiled by one Fortran compiler with code from another. The empirical fact that this “usually works” if you keep it simple enough is a product of vendors making identical choices in their implementation. C interoperability feature codifies the “usually works” into “must work for these simple cases”. But even then, the two runtimes are not guaranteed to behave as expected when they both change global state. They are not even guaranteed not to have name collisions in their implementation, so linking is down to a throw of the dice.
The solution you seek lies elsewhere.
For the price of a night out for four people (from my own experience), I am happy with the value I get from a tool that makes my job easier every day. I am not employed by NAG.
For those who program frequently in C or C++, are there similar issues in these languages? Can a library be compiled with one C compiler and then used freely by a program compiled with another C compiler?
For C usually yes. For C++ sometimes, but I hit so many issues with mixing C++ compilers (even versions of the same compiler) that I personally think the answer is no, unless you stick to just C.
C has a de facto standard ABI, so mixing C compilers is usually possible. This is not so simple for C++ (there are some efforts in this direction, but not all compilers comply).
Well, you can in fact do this already with standard Fortran or very close. Here is a program that exercises the feature. If you want to be flexible (i.e. not use separate functions for every container), you can implement the function as a type-bound procedure.
Yes, this is why we would need the possibility to specify pointer, intent(in) attributes for the instance variable in type bound procedures. That way, the compiler would enforce, that the caller sets the target attribute outside. Unfortunately, Fortran does not offer that yet (for type bound procedures). I’ve created an according feature request/issue on J3-Fortran, but did not get any reactions so far.
