Project Strings: improving strings support || Blog Post #1 || GSoC

Projects GSoC-2021
1

Hello everyone!,

This post is regarding GSoC project on improving strings support in Fortran.

The requirements of the project are such that the involvement of community will be fruitful for the overall acceptance of this string library as the “go-to” library for string operations in Fortran.
Thus, I invite you all to improve Fortran by leaving your opinions/feedbacks on the functionalities
that are being discussed on Fortran’s issues page.

Many functionalities will be discussed upon throughout the course of the project one by one and hence I will keep you posted with the current status and discussions of the project through blog posts like this on this discourse group.

If you have any functionality in your mind to propose or discuss, please feel free to tag me (@Aman-Godara).

currently in discussion:
1). intelligent slice functionality for strings #413

Short Description: Slice is an intelligent function which traverses the input string from start index to end index taking a stride of stride indexes to return a new string.

Please use the above given link to know more about the functionality, linked PRs (Pull Requests) and to join the discussion. There are many things which are still left to be discussed and improved.

Congratulations fellow interns!

6 Likes
2

This looks like a great idea. I’ve written slice functions like this in the past, and always felt like I was reinventing the wheel and that it should be in a standard library somewhere.

I just wish Fortran let you write functions which take Fortran style (a:b:c) slices as arguments, so that you could write e.g.

type(String) :: foo
foo = 'abcdef'
write(*,*) foo(2:6:2)

rather than

type(String) :: foo
foo = 'abcdef'
write(*,*) slice(foo,2,6,2)

But as that’s not possible, the function you’ve proposed looks great.

3

Well, it is possible to use array syntax on the characters if you switch the string to an array of characters. It is getting better, but it was much more reliable to transfer an array of characters to C instead of a string as well so I have used a function to switch a string to an array of characters and vice-versa for similar functionality. If you had reason to stick the data into a named variable anyway it works very nicely.
chars=switch(string)
write(,)chars(1:10:2)
and so on. But because the colon sequence only works with a named variable looking though some code
I see some odd statements like “switch[[string(i:i),i=1,20,2)]” but you can do some interesting things with VERIFY and PACK and SCAN with the mask that PACK allows to easily do things with an array like delete all non-alphanumeric characters that can be handy. So I like the idea of slice, but maybe you would like the idea of a function to switch a character array to a string or vice-versa too as an alternative.

1 Like
4

Keep in mind that you can “convert” a character variable to an array of single characters by argument association. For example:

cat test.f90
program test
character(*),parameter :: foo = “abcdef”
call sub(foo,1,6,2)
end program test

subroutine sub(bar,i,j,k)
character :: bar(*)
write ( * , * ) bar(i:j:k)
end subroutine sub

ftn test.f90
./a.out
ace

5

Both of these are good points. But I’d still really like it if it were possible to write derived types so that they used identical syntax to intrinsic types.

I like how in Python a derived type can be “Pythonic”, i.e. it follows the python style guide, and so you can often know exactly what the class does without needing to look at any documentation.

On the other hand, it is impossible to write a “Fortranic” derived type. There are several pieces of syntax (including array slicing, statements like open and allocate, array access more generally) which are ubiquitous when working with arrays and intrinsic types, but which cannot be used with derived types.