@certik and anyone interested in this:
Please note I am not particularly hung up on the syntax per se, my interest is mostly consistent and ease-of-use for the practitioners which does mean a facility that is an integral part of the language that all conforming Fortran processors support.
But now, I do think there are 7 aspects that can make it much more pleasant for the practitioners and which can be considered toward a prototype implementation in LFortran.
On this, first take a look at the situation with the current standard and the derived type option:
module xxx
type :: string
! private?
character(len=:), allocatable :: s ! or perhaps s(:) and private or not
end type
..
end module
use xxx .. ! superfluous
type(string), allocatable :: parts(:) ! why type(string)? should be simply string
parts = [ string("valve"), string("compressor"), string("transducer") ]
! substring
print *, parts(3)%s(2:4)
end
So, as you will know, the derived type facility is the excuse by the standards committee to not work on an intrinsic STRING type. But their argument places the practitioners last and it is deeply flawed, a total disservice.
- it is difficult for the library developers who wishes to author such a type to decide on the attributes, especially the
RANK of the member underpinning the type i.e., s in the above example.
- as with 1, whether the member can be made
PRIVATE and yet successfully meet the use cases of the consumers including IO will be a big concern for the library developer(s) of such type,
- so with 2, a particularly vexxing problem is the must-have use case for practitioners which is substring accessor consistent with the current intrinsic
CHARACTER type e.g., parts(3)(2:4). There are only poor workarounds toward this with the current standard and that should be unacceptable for the practitioners, they need to be served better.
- Next is methods which operate on said type. A lot of the
APIs (interfaces) have been established both with the now-deleted Part 3 (ISO VARYING STRING) and also so many other languages that offer string types. However there are two questions: a) should be type-bound or not and b) what should be their names (e.g., erase or delete?). Issue a) becomes relevant with respect to USE statement and ONLY clause. An intrinsic type which is part of the standard, whatever the decision as long as it is easy-to-use for a Fortran coder, makes this is all straight-forward.
- Similarly with
type construction: library authors have limited options - the above snippet shows one possibility. But an intrinsic type in a standard can provide for a simpler one, perhaps an array of jagged strings - that will be cool.
- The need for
type( .. ) with such an simple but important type is entirely lame, users should simply be able to reference it as string (or some such).
- for such a basic type, all the administrative tasks with
MODULE management (MOD and library files) and toward their USE by the practitioners with a library solution is mindless. Making it intrinsic does away with all this, Meaning, the type must be available anywhere and everywhere just like CHARACTER
Sure, this all means some work on the standard document itself and also for the implementors. But those working on the standard as well as the implementors must be ready to serve the Fortran practitioners. Otherwise, they can get out of the way, let the world not bother them anymore, just as no one will anyone at Absoft and Lahey Fortran.
Nonetheless, should there a few people willing to prototype something in LFortran and be open to considering the above 7 aspects, I will be more than open to both funding with $$ the effort in LFortran as well as helping out the specs, design, testing, etc.