Fortran - Strings with escape sequences.

Author

Strings with escape sequences.

Joe Krahn

2006-03-22, 7:03 pm

Sometimes it is useful to support escape codes for things like tab and
newline. Does Fortran allow for escape interpretation to be part of the
definition of string kind (excluding the defined quote escape)? That
could be a nice way to allow for C-style string expressions.

Joe

James Giles

2006-03-22, 10:00 pm

Joe Krahn wrote:
> Sometimes it is useful to support escape codes for things like tab and
> newline. Does Fortran allow for escape interpretation to be part of
> the definition of string kind (excluding the defined quote escape)?
> That could be a nice way to allow for C-style string expressions.

A better way would be to require "escape sequences" to be
completely ignored by the rules for literals, and provide
separately a prefix operator that processes escapes. That
way the functionality can be applied to strings whose origin
is other than just literals:

MyStr = "abc\t\n"
! the value of MyStr has 7 characters (2 of them '')
MyStr = .c."abc\t\n"
! the value has 5 characters, including a tab and newline
Read(*,*) MyStr
! the value is whatever was on the file
MyStr = .c.MyStr
! the value has now had escapes processed.

You could even have an alternative if you don't like C style
escapes. Suppose you like the form of escapes where the
control characters are formed by '^' followed by a letter.
You could have an operator that processes those and not
the C escapes.

Character literals should be just that: they should literally
mean what they look like.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Joe Krahn

2006-03-23, 4:07 am

James Giles wrote:
> Joe Krahn wrote:
>
>
>
> A better way would be to require "escape sequences" to be
> completely ignored by the rules for literals, and provide
> separately a prefix operator that processes escapes. That
> way the functionality can be applied to strings whose origin
> is other than just literals:
>
> MyStr = "abc\t\n"
> ! the value of MyStr has 7 characters (2 of them '')
> MyStr = .c."abc\t\n"
> ! the value has 5 characters, including a tab and newline
> Read(*,*) MyStr
> ! the value is whatever was on the file
> MyStr = .c.MyStr
> ! the value has now had escapes processed.
>
> You could even have an alternative if you don't like C style
> escapes. Suppose you like the form of escapes where the
> control characters are formed by '^' followed by a letter.
> You could have an operator that processes those and not
> the C escapes.
>
> Character literals should be just that: they should literally
> mean what they look like.
>
Yes, a much better idea. With user-defined unary operators, it can
already be done.

Thanks,
Joe

Brooks Moses

2006-03-26, 10:00 pm

Joe Krahn wrote:
> James Giles wrote:
[...][color=darkred]
>
> Yes, a much better idea. With user-defined unary operators, it can
> already be done.

Can it? Isn't this sort of like the infamous TRIM() example, where
there's the difficulty of returning a string of the correct length?

(And I've so completely blocked recollection of that example from my
memory that I don't recall whether it's just Fortran 77 that has the
problem and if there's a solution in Fortran 95, or what....)

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Dan Nagle

2006-03-26, 10:00 pm

Hello,

Brooks Moses wrote:
> Joe Krahn wrote:

<snip example>
[color=darkred]
>
> Can it? Isn't this sort of like the infamous TRIM() example, where
> there's the difficulty of returning a string of the correct length?

Trailing blanks have no affect on the _removal_ of escaped characters,
nor the sentinel used to mark the escape.

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

James Giles

2006-03-26, 10:00 pm

Brooks Moses wrote:
> Joe Krahn wrote:
....
>
> Can it? Isn't this sort of like the infamous TRIM() example, where
> there's the difficulty of returning a string of the correct length?
>
> (And I've so completely blocked recollection of that example from my
> memory that I don't recall whether it's just Fortran 77 that has the
> problem and if there's a solution in Fortran 95, or what....)

Well, the F95 solution to TRIM is:

module A_Trim
contains
function mytrim(x)
character(*) :: x
character(my_len_trim(x)) :: mytrim
mytrim = x
return
end function mytrim
pure function my_len_trim(x)
character(*), intent(in) :: x
integer my_len_trim
my_len_trim = verify(x,' ',back=.true.)
return
end function my_len_trim
end module A_Trim

With the advent of F2003 deferred length, the solution is
even easier since you won't have to essentially do the work
in an auxilliary function first (just to get the length) and then
again in the actual routine. To do escape sequence processing
using the above technique would require the auxilliary length
finding function to locate all valid escapes and count them,
then the actusl escapes would be found again in order to
replace them. Still, it can be done - it's just harder than
it ought to be.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

James Giles

2006-03-26, 10:00 pm

Dan Nagle wrote:
....
>
> Trailing blanks have no affect on the _removal_ of escaped characters,
> nor the sentinel used to mark the escape.

Quite so, but it wold still be nice not to add extra blanks to the
end of a string expression. You might later want to assign it
to one of those new variable length F2003 strings. Fortunately
it can actually be done.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Brooks Moses

2006-03-27, 4:00 am

James Giles wrote:
> Dan Nagle wrote:
> ...
>
> Quite so, but it wold still be nice not to add extra blanks to the
> end of a string expression. You might later want to assign it
> to one of those new variable length F2003 strings. Fortunately
> it can actually be done.

Actually, what I was thinking of was something like this, where the
problem occurs even without F2003 variable-length strings:

write(*,'A') mystring1 // .c.'\n' // mystring2

If that puts a trailing block at the end of the escaped string, then
it's going to put mystring2 in the "wrong" place.

Meanwhile, thanks for the comments (in your other post) on how to solve
this problem.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Dan Nagle

2006-03-27, 8:00 am

Hello,

Brooks Moses wrote:

<snip>

> write(*,'A') mystring1 // .c.'\n' // mystring2

write(*,'A') trim( mystring1) // '.c' // new_line(' ') // &
trim(mystring2)

HTH

To be completely correct, there's no guarantee that
the new line character is acceptable to a sequential format
write statement (is works for stream writes). But since
the processor most likely will use the same RTL for both,
this will most likely work.

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

James Giles

2006-03-27, 8:00 am

Dan Nagle wrote:
> Hello,
>
> Brooks Moses wrote:
>
> <snip>
>
>
> write(*,'A') trim( mystring1) // '.c' // new_line(' ') // &
> trim(mystring2)

I think he was actually referring to my proposed .c. prefix
operator. So, he wanted the contents of MYSTRING1
concatenated with the result of the .c. operator applied
to the argument '\n' and then concatenated to the contents
of MYSTRING2. The gist being that he didn't want the
..c. operator to introduce any additional spaces as part
of its operation. Your translation seems to assume that
the result is intended to actually contain the fragment '.c'
and that the variables (or named constants) MYSTRING1
and MYSTRING2 had insignificant blanks. Neither of
those is to be assumed from the example given.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Dan Nagle

2006-03-27, 8:00 am

James Giles wrote:

<snip>

> I think he was actually referring to my proposed .c. prefix
> operator.

You're right. Attribute it to pre-coffee usage of Mark I eyeballs.

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

Sponsored Links