Implement strip and chomp as supplement to trim

[awvwgk]

Originally proposed by @zbeekman in #69 (comment):

Strip

• Remove leading and trailing whitespace characters (null, horizontal tab, line feed, vertical tab, form feed, carriage return, space.)
• Ruby: https://ruby-doc.org/core-2.6/String.html#method-i-strip

"    hello    ".strip   #=> "hello"
"\tgoodbye\r\n".strip   #=> "goodbye"
"\x00\t\n\v\f\r ".strip #=> ""
"hello".strip           #=> "hello"

• Fortran:

strip("\tgoodbye\r\n") ! "goodbye", where \t is a tab char, \n a new line etc.
strip("   hello     ") ! "hello"
strip("Hello")         ! "Hello"
!! Or maybe for a string class
s%strip() ! returns "hello" from "   hello   ", etc. as above

Chomp

• Return string with default or optionally specified trailing record separator(s) removed. Think write(*,*) vs write(*,*, ADVANCE="NO").
• Ruby: https://ruby-doc.org/core-2.6/String.html#method-i-chomp

"hello".chomp                #=> "hello"
"hello\n".chomp              #=> "hello"
"hello\r\n".chomp            #=> "hello"
"hello\n\r".chomp            #=> "hello\n"
"hello\r".chomp              #=> "hello"
"hello \n there".chomp       #=> "hello \n there"
"hello".chomp("llo")         #=> "he"
"hello\r\n\r\n".chomp('')    #=> "hello"
"hello\r\n\r\r\n".chomp('')  #=> "hello\r\n\r"
!! Or use a TBP on a string class with passed first argument

• Fortran:

chomp("hello")                   ! "hello"
chomp("hello\n")                 ! "hello"
chomp("hello\r\n")               ! "hello"
chomp("hello\n\r")               ! "hello\n"
chomp("hello\r")                 ! "hello"
chomp("hello \n there")          ! "hello \n there"
chomp("hello", sep="llo")        ! "he"
chomp("hello\r\n\r\n", sep="")   ! "hello"
chomp("hello\r\n\r\r\n", sep="") ! "hello\r\n\r"
!! Or use a TBP on a string class with passed first argument

Changes to the original proposal

chomp takes also a set which is provided as array of length one characters and the default chomp uses the whitespace set from stdlib_ascii rather than removing only newlines.

use stdlib_strings, only : chomp
implicit none
print'(a)', chomp("hello", set=["l", "o"])  ! "he"
end

[milancurcic]

chomp takes a set rather than a substring which is more in line with intrinsic functions like scan and verify

There are probably use cases for both. Could we design chomp to take one or the other?

print'(a)', chomp("hello", set="lo")  ! "he"
print'(a)', chomp("hello", substring="lo")  ! "hel"

But that unfortunately complicates the API--set and substring would need to be optional and we'd need to handle the cases of chomp with one or three dummy arguments. Probably not worth it and I think set instead of substring is a good choice. If there's user demand for the substring variant, we can implement a separate function.

[awvwgk]

But that unfortunately complicates the API--set and substring would need to be optional and we'd need to handle the cases of chomp with one or three dummy arguments. Probably not worth it and I think set instead of substring is a good choice. If there's user demand for the substring variant, we can implement a separate function.

We would have to force keyword arguments by some hacks, it's not impossible, but quite ugly in Fortran...

function chomp_set(string, force_kwargs, set)
  character(len=*), intent(in) :: string
  ! dummy type to force key-value argument, make sure signature is different from substring variant
  type :: force_kwargs_type
    class(*), private, allocatable :: set
  end type force_kwargs_type
  type(force_kwargs_type), intent(in), optional :: force_kwargs
  character(len=*), intent(in) :: set
end function
function chomp_substring(string, force_kwargs, substring)
  character(len=*), intent(in) :: string
  ! dummy type to force key-value argument, make sure signature is different from set variant
  type :: force_kwargs_type
    class(*), private, allocatable :: substring(:)
  end type force_kwargs_type
  type(force_kwargs_type), intent(in), optional :: force_kwargs
  character(len=*), intent(in) :: substring
end function

[ivan-pi]

I don't think that hack works. Since the "dummy" argument is optional in both cases, the interfaces are ambiguous.

[awvwgk]

I don't think that hack works. Since the "dummy" argument is optional in both cases, the interfaces are ambiguous.

Yeah, you're right, this interface doesn't work, that's why I put it up as puzzle at the discourse. Maybe there is a way to make it work in Fortran?

[awvwgk]

Thanks for feedback so far. With two approvals I will merge later this week unless there is more to discuss on this proposal.

[ivan-pi]

A few minor comments:

• Do we want examples in the spec for a type(string_type) variable or is this supposed to be self-explanatory?
• I found the name of the test driver string_trim a bit confusing given that the functions tested are called strip and chomp. My only alternative would be string_strip_chomp.
• I wasn't sure what was the purpose of testing the functions with and without the keyword argument, e.g:

        call check(chomp(string_type("hello"), "lo") == "hel")
        call check(chomp(string_type("hello"), substring="lo") == "hel")
  

• I noticed you arranged the functions in "opposite" order of how they interact, in other words functions never call functions above them. Is there some underlying reason for this?

But otherwise, I think it is good to go!

The functions are a great example of how versatile verify is. On the other hand the high ratio of boiler-plate code for interfaces vs actual code doing stuff is somewhat disheartening property of Fortran.

[awvwgk]

Do we want examples in the spec for a type(string_type) variable or is this supposed to be self-explanatory?

Using string_type in the example would lead to wrapping the literals in the constructor, which feels redundant. Generally, I would think about any string related function as if it supports string_type on an equal footing to intrinsic character variables.

I wasn't sure what was the purpose of testing the functions with and without the keyword argument, e.g:

Mainly to pin the API down in the test, thinking about this, there is no “test” to check whether the first argument can be accessed by string=. Renaming a dummy argument can be considered a breaking API change and I was looking for a way to catch those in the testing.

I noticed you arranged the functions in "opposite" order of how they interact, in other words functions never call functions above them. Is there some underlying reason for this?

Mainly the order I wrote them, no particular reason on ordering them this way.

On the other hand the high ratio of boiler-plate code for interfaces vs actual code doing stuff is somewhat disheartening property of Fortran.

It is indeed quite verbose, but the wrappers for the implementation are too different to create them from a fypp macro. Since the wrappers are quite similar in general we might come up with some common skeleton for all of them as the stdlib_strings module grows and use this instead as a fypp macro.

[ivan-pi]

Thanks for the answers.

With 3 approvals it is more than ready to be merged. 👍

[sgeard]

I'm not convinced this is the right approach. String handling is really the realm of scripting languages and I think that the way Tcl handles these issues is better.

Strip: why not trim, trimleft and trimright?

Chomp: in over 30 years of writing scripts (cross platform) I've never needed such a function and Tcl doesn't have one - and the examples just don't seem real. I'd like to understand what real problem is being solved with this function. The name is terrible as well - reminds me of Perl to which I seem to be allergic!
One thing Tcl does do is interpret \n as a newline in a platform independent way so when you read a file you always get '\n' irrespective of platform. Embedding platform-dependent line-endings in strings is poor practice - they are better handled in the i/o layer.