list of needed string utilities

[gronki]

Many will disagree, but I think Fortran strings (character(len = :), allocatable) are pretty dope for a low-level language. However, lack of standard utilities to handle them is pain. Adding a few utilities would be an extremely easy way to highly increase the value of the language.

I suggest the following format for proposals:

1. name of the utility
2. short description
3. does it exist in other languages
4. proposed example of usage

[gronki]

1. split
2. Given a separator, splits the string into some form of array.
3. Most languages have some form of that utility. Example in Python:

In [1]: "i am a sheep".split()                                                                  
Out[1]: ['i', 'am', 'a', 'sheep']

In [2]: "i am a big sheep".split('big')                                                         
Out[2]: ['i am a ', ' sheep']

4. There are other possible ways for it to work, just showing one:

character(len = 16) :: arr(10)
call split("i am a sheep", arr)
call split("i am a big sheep", arr, delim = "big")

[LKedward]

Being a Fortran programmer, I like my programs to parse user config files as case-insensitive where possible. So most of my programs have an upperStr routine included.

1. upperStr(...)/lowerStr(...)
2. Convert a character string all to upper/lower case
3. yes

character(len = 11) :: myString, myStringUpper
myString = "Hello World"
myStringUpper = upperStr(myString)

[rweed]

I think a new intrinsic module (ISO_FORTRAN_STRINGS) was proposed for F202x that included split along with some other new string routines (extract, insert, replace etc.)
Last time I looked on the J3 site it appears thought that only split has survived. I think this was proposed to bring some of the functionality in the old VARYING_STRINGS module into the mainline standard. I would be interested in hearing from the committee menbers on the status of this since its one of the few things I see proposed for F202x I would use immediately if available.

[marshallward]

A broader question may be whether Fortran should consider including a standard library. String manipulation would be a natural component of such a library.

[rweed]

See https://j3-fortran/org/doc/year/18/18-259r2.txt for the original proposal.

[rweed]

Oops. j3-fortran.org not j3-fortran/org

[FortranFan]

1. split

Readers may note Part 2 of the Fortran standard, "Varying length character strings" which is slated for deletion.

In response, there was a proposal by J3 to include certain intrinsic procedures to Part 1 of the Fortran standard: see US03 in that link.

However WG5 decided at the Tokyo meeting earlier this year to only consider SPLIT for Fortran 202X, here's where it stands at present: https://j3-fortran.org/doc/year/19/19-254r2.txt

[milancurcic]

A broader question may be whether Fortran should consider including a standard library. String manipulation would be a natural component of such a library.

Sorry, off-topic, but how is the current set of intrinsic procedures not a standard library? Sure, it's not called standard library in the standard, and it's available by default in the global namespace, but otherwise I can't tell the difference.

I use the term standard library throughout my book to refer to the set of intrinsic procedures and modules. This term is easier to understand to the broader audience.

[marshallward]

I would have said that a standard library could, for example, define a function that does not require an extension of the language itself, and could (in principle) be something that could be implemented in Fortran. In the case of string manipulations, it could help to delineate operations which are currently tedious vs impossible to implement.

But I definitely agree that this is potentially off-topic and I somewhat regret the comment. Apologies for the distraction.

[sblionel]

https://j3-fortran.org/doc/year/19/19-196r3.txt is the latest paper on this. There was some opposition to doing even this much. My own preference would have been to do more. The prevailing notion was that procedures that are straightforward to implement by users don't need to be intrinsics. I would like to see this revisited for 202Y.

On a semi-related note, see https://j3-fortran.org/doc/year/19/19-197r3.txt , which I worked on.

[gronki]

Thanks for the answer. It would be awesome if this could be revisited. The attitude that functions easy to implement should not be standardized is in my opinion absolutely detached from reality and outrageous. Keeping my fingers crossed for your (and others) efforts to push though improvements in Fortran string handling! sob., 23 lis 2019, 01:36 użytkownik Steve Lionel <notifications@github.com> napisał:

…

https://j3-fortran.org/doc/year/19/19-196r3.txt is the latest paper on this. There was some opposition to doing even this much. My own preference would have been to do more. The prevailing notion was that procedures that are straightforward to implement by users don't need to be intrinsics. I would like to see this revisited for 202Y. On a semi-related note, see https://j3-fortran.org/doc/year/19/19-197r3.txt , which I worked on. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#96?email_source=notifications&email_token=AC4NA3MNNH6C3AXEI3OYPWLQVB3G7A5CNFSM4JQQTFP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE7IBHA#issuecomment-557744284>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC4NA3KLHCPZ5ESQIH4LO3TQVB3G7ANCNFSM4JQQTFPQ> .

[FortranFan]

@sblionel wrote:

https://j3-fortran.org/doc/year/19/19-196r3.txt is the latest paper on this. ..

As I commented in #96 (comment), the current state of development of a new SPLIT intrinsic appears instead to be this.

[FortranFan]

@sblionel wrote:

.. There was some opposition to doing even this much. My own preference would have been to do more. The prevailing notion was that procedures that are straightforward to implement by users don't need to be intrinsics. I would like to see this revisited for 202Y.
..

Can't help but go OT: the basic need for a standard is for the widest group of practitioners to have

1. a standard name e.g., is a procedure to be named REMOVE or ERASE; SPLIT or STRTOK or TOKENIZE, etc.!?

2. a standard interface e.g., subroutine or a function; what is the list, order, naming, and type, kind, rank of method parameters?

3. standard documentation and dissemination of method characteristics.

for the most commonly needed instructions.

Considering so much of information to be processed in the arena of scientific and technical computing is also in the form of strings, the utilities for string manipulation are of foremost importance.

That such an elementary consideration got voted over yet again at Fortran meeting #219 places Fortran at such a disadvantage. The question remains: For Whom Fortran?

[jacobwilliams]

Wow, these SPLIT proposals are really... um... requiring of more time in the oven... So, it's going to return the tokens with a bunch of extra padding spaces? All because we can't have a decent string class? That is just terrible. And to get even this is requiring years of debate? Is this really the best we can hope for?

How can we liberate Fortran from the Fortran committee?

[sblionel]

You could join the committee, or at least submit some proposals that flesh out your ideas.

That SPLIT proposal was the work of a day or two, and went through some rather major changes, A big part of the problem is the inability to have an array of different-length strings, but one can deal with that by trimming. To do more would require a major feature we're not going to do this time around.