add a0 format to language to print trimmed character variables

[Beliavsky]

I wish there were an "a0" format for character variables, analogous to
i0 for integers, which would not print trailing spaces in character
variables. For example,

character (len=5) :: words(4) = (/"one ","two ","three","four "/)
write (*,"(100(1x,a0))") words

would print

one two three four

The TRIM function is not elemental, so one cannot write

write (*,"(100(1x,a))") trim(words)

Currently I write

write (*,"(100(1x,a))") (trim(words(i)),i=1,size(words))

which is slightly awkward IMO.

[m***@athenavisual.com]

Post by Beliavsky
I wish there were an "a0" format for character variables, analogous to
i0 for integers, which would not print trailing spaces in character
variables. For example,
character (len=5) :: words(4) = (/"one ","two ","three","four "/)
write (*,"(100(1x,a0))") words
would print
one two three four
The TRIM function is not elemental, so one cannot write
write (*,"(100(1x,a))") trim(words)
Currently I write
write (*,"(100(1x,a))") (trim(words(i)),i=1,size(words))
which is slightly awkward IMO.

I am with you. Did you send your suggestion to Andy? Perhaps he can
implement it in g95

Michael

[Richard Maine]

Post by m***@athenavisual.com

Post by Beliavsky
I wish there were an "a0" format for character variables, analogous to
i0 for integers, which would not print trailing spaces in character
variables.

I am with you. Did you send your suggestion to Andy? Perhaps he can
implement it in g95

I don't see that as analogous. Or at any rate, I don't think it a robust
analogy.

The i0 for integers doesn't modify the value printed out. It just avoids
adding blank padding characters.

For the character case, you aren't talking about padding. Instead, you
are talking about modifying the value printed out, as the blanks are
part of the value.

Yes, they both result in fewer blanks, but I see them as conceptually
different.

In any case, I'd recommend against having g95 start adding random new
extensions, particularly ones with such small payoff. Avoiding an
implied DO loop doesn't seem like a big payoff to me. What would happen
if the standard later adopted some different meaning for an A0 edit
descriptor? I think that adding new extensions without spending
significant time considering the cost/benefit is a path towards a mess.

[glen herrmannsfeldt]

Richard Maine wrote:

(someone wrote)

Post by Richard Maine

Post by Beliavsky
I wish there were an "a0" format for character variables, analogous to
i0 for integers, which would not print trailing spaces in character
variables.

I don't see that as analogous. Or at any rate, I don't
think it a robust analogy.
The i0 for integers doesn't modify the value printed out. It just avoids
adding blank padding characters.
For the character case, you aren't talking about padding. Instead, you
are talking about modifying the value printed out, as the blanks are
part of the value.

But there is already an A descriptor that doesn't add padding, and
that is just A. Why isn't the no padding I descriptor just I?

Post by Richard Maine
Yes, they both result in fewer blanks, but I see them as conceptually
different.

I do agree that avoiding an implied-DO is a silly reason to add
such a feature. Still, since the no-pad form of A already exists,
I don't see that as needing A0. I also don't see a use for I,
other than that already taken by I0. It seems that the standard
is already inconsistent.

-- glen

[dpb]

Post by glen herrmannsfeldt
(someone wrote)

Post by Richard Maine

Post by Beliavsky
I wish there were an "a0" format for character variables, analogous to
i0 for integers, which would not print trailing spaces in character
variables.

I don't see that as analogous. Or at any rate, I don't
think it a robust analogy.
The i0 for integers doesn't modify the value printed out. It just avoids
adding blank padding characters.
For the character case, you aren't talking about padding. Instead, you
are talking about modifying the value printed out, as the blanks are
part of the value.

But there is already an A descriptor that doesn't add padding, and
that is just A. Why isn't the no padding I descriptor just I?

...
I don't think that's a standard interpretation of the A descriptor --
the implied width of field with a missing field width specifier is a
compiler-supplied default. For the A descriptor, the default is the
actual length of the specified i/o item.

[Gordon Sande]

Post by dpb

Post by glen herrmannsfeldt
(someone wrote)

Post by Richard Maine

Post by Beliavsky
I wish there were an "a0" format for character variables, analogous to
i0 for integers, which would not print trailing spaces in character
variables.

I don't see that as analogous. Or at any rate, I don't
think it a robust analogy.
The i0 for integers doesn't modify the value printed out. It just avoids
adding blank padding characters.
For the character case, you aren't talking about padding. Instead, you
are talking about modifying the value printed out, as the blanks are
part of the value.

But there is already an A descriptor that doesn't add padding, and
that is just A. Why isn't the no padding I descriptor just I?

...
I don't think that's a standard interpretation of the A descriptor --
the implied width of field with a missing field width specifier is a
compiler-supplied default. For the A descriptor, the default is the
actual length of the specified i/o item.

One guesses that the intent was to use A with TRIM of something.

The original request was to have TRIM applied to an array of
character variables produce an array in which each element could
have a different length. The place this would be of use would be
in an I/O list as otherwise an assignment would just get a new
fixed length back. I suppose one could also think of doing a
concatenation of the variable length pieces before doing the
assignment. This would build up full names from first and last names
without the confusion of all the first names being padded to a fixed
length. Perhaps it might be a nice example of FORALL doing something
that a regular array assignment does not have access to.

[dpb]

Post by dpb

Post by glen herrmannsfeldt
(someone wrote)

Post by Richard Maine

Post by Beliavsky
I wish there were an "a0" format for character variables, analogous to
i0 for integers, which would not print trailing spaces in character
variables.

I don't see that as analogous. Or at any rate, I don't
think it a robust analogy.
The i0 for integers doesn't modify the value printed out. It just avoids
adding blank padding characters.
For the character case, you aren't talking about padding. Instead, you
are talking about modifying the value printed out, as the blanks are
part of the value.

But there is already an A descriptor that doesn't add padding, and
that is just A. Why isn't the no padding I descriptor just I?

...
I don't think that's a standard interpretation of the A descriptor --
the implied width of field with a missing field width specifier is a
compiler-supplied default. For the A descriptor, the default is the
actual length of the specified i/o item.

Actually, I realize I misinterpreted the intent of what said so both
meaning the same.

[Clive Page]

Post by glen herrmannsfeldt

Post by Beliavsky
I wish there were an "a0" format for character variables, analogous to
i0 for integers, which would not print trailing spaces in character
variables.

I think that's an excellent suggestion - pity nobody thought of it in
time for F2003.

Post by glen herrmannsfeldt
But there is already an A descriptor that doesn't add padding, and
that is just A. Why isn't the no padding I descriptor just I?

I suppose for consistency with F0.d - perhaps it was thought that having
a plain F.d would look odd?

[Gary Scott]

Post by Clive Page

Post by glen herrmannsfeldt

Post by Beliavsky
I wish there were an "a0" format for character variables, analogous to
i0 for integers, which would not print trailing spaces in character
variables.

I think that's an excellent suggestion - pity nobody thought of it in
time for F2003.

In order to be analogous to I0 though wouldn't it need to trim both
leading and trailing spaces? I don't think that would be the usual
desire though, but maybe you could specify '0a0' to trim leading and
trailing spaces.

Post by Clive Page

Post by glen herrmannsfeldt
But there is already an A descriptor that doesn't add padding, and
that is just A. Why isn't the no padding I descriptor just I?

I suppose for consistency with F0.d - perhaps it was thought that having
a plain F.d would look odd?

--
Gary Scott
mailto:***@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

[Beliavsky]

Post by Gary Scott

Post by Clive Page

Post by Beliavsky
I wish there were an "a0" format for character variables, analogous to
i0 for integers, which would not print trailing spaces in character
variables.

I think that's an excellent suggestion - pity nobody thought of it in
time for F2003.

In order to be analogous to I0 though wouldn't it need to trim both
leading and trailing spaces? I don't think that would be the usual
desire though, but maybe you could specify '0a0' to trim leading and
trailing spaces.

ADJUSTL can be (and is) ELEMENTAL, unlike TRIM, because the LEN of the
RESULT is the same as that of the argument. Quoting the gfortran
documentation, "ADJUSTL(STR) will left adjust a string by removing
leading spaces. Spaces are inserted at the end of the string as
needed."

If a0 were in the language, one could just write

write (*,"(1000(1x,a0))") adjustl(char_vec)

to print an array of character variables with leading and trailing
spaces removed from character variables and one space inserted between
variables.

[Gary Scott]

Post by Beliavsky

Post by Gary Scott

Post by Clive Page

Post by Beliavsky
I wish there were an "a0" format for character variables, analogous to
i0 for integers, which would not print trailing spaces in character
variables.

I think that's an excellent suggestion - pity nobody thought of it in
time for F2003.

In order to be analogous to I0 though wouldn't it need to trim both
leading and trailing spaces? I don't think that would be the usual
desire though, but maybe you could specify '0a0' to trim leading and
trailing spaces.

ADJUSTL can be (and is) ELEMENTAL, unlike TRIM, because the LEN of the
RESULT is the same as that of the argument. Quoting the gfortran
documentation, "ADJUSTL(STR) will left adjust a string by removing
leading spaces. Spaces are inserted at the end of the string as
needed."
If a0 were in the language, one could just write
write (*,"(1000(1x,a0))") adjustl(char_vec)
to print an array of character variables with leading and trailing
spaces removed from character variables and one space inserted between
variables.

Certainly, but it is more verbose and potentially more inefficient.
Specifying '0a0', the compiler could simply skip over leading blanks
rather than physically moving the string left.
--
Gary Scott
mailto:***@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

[glen herrmannsfeldt]

Gary Scott wrote:
(snip)

Post by Gary Scott
In order to be analogous to I0 though wouldn't it need to trim both
leading and trailing spaces? I don't think that would be the usual
desire though, but maybe you could specify '0a0' to trim leading and
trailing spaces.

That is one that I don't think you can do. The repeat specifier
comes before the data edit descriptor. If you allowed 0 indicating
to trim leading blanks, how would you apply a repeat specifier to it?

Suffixes can be applied to descriptors, the most common being the
indication of the number of places after the decimal point in
descriptors for floating point values. It would look a little
strange, but it would seem possible to use that one.

Otherwise, as a way to get around an implied DO it still
seems a little excessive.

-- glen

[Pierre Asselin]

Post by glen herrmannsfeldt
That is one that I don't think you can do. The repeat specifier
comes before the data edit descriptor. If you allowed 0 indicating
to trim leading blanks, how would you apply a repeat specifier to it?

40(0A0)

[Gary Scott]

Post by glen herrmannsfeldt
(snip)

Post by Gary Scott
In order to be analogous to I0 though wouldn't it need to trim both
leading and trailing spaces? I don't think that would be the usual
desire though, but maybe you could specify '0a0' to trim leading and
trailing spaces.

That is one that I don't think you can do. The repeat specifier
comes before the data edit descriptor. If you allowed 0 indicating
to trim leading blanks, how would you apply a repeat specifier to it?

Perhaps then a special symbol: '\a\'

I didn't really like any that I tried, but this one I like because it
conflicts with that annoying c escape character that has crept into a
lot of compilers.

Post by glen herrmannsfeldt
Suffixes can be applied to descriptors, the most common being the
indication of the number of places after the decimal point in
descriptors for floating point values. It would look a little
strange, but it would seem possible to use that one.
Otherwise, as a way to get around an implied DO it still
seems a little excessive.
-- glen

--
Gary Scott
mailto:***@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

[Gary Scott]

Post by Gary Scott

Post by glen herrmannsfeldt
(snip)

Post by Gary Scott
In order to be analogous to I0 though wouldn't it need to trim both
leading and trailing spaces? I don't think that would be the usual
desire though, but maybe you could specify '0a0' to trim leading and
trailing spaces.

That is one that I don't think you can do. The repeat specifier
comes before the data edit descriptor. If you allowed 0 indicating
to trim leading blanks, how would you apply a repeat specifier to it?

Perhaps then a special symbol: '\a\'
I didn't really like any that I tried, but this one I like because it
conflicts with that annoying c escape character that has crept into a
lot of compilers.

I guess it (\) may not conflict in this context though.

Post by Gary Scott

Post by glen herrmannsfeldt
Suffixes can be applied to descriptors, the most common being the
indication of the number of places after the decimal point in
descriptors for floating point values. It would look a little
strange, but it would seem possible to use that one.
Otherwise, as a way to get around an implied DO it still
seems a little excessive.
-- glen

--
Gary Scott
mailto:***@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

[Clive Page]

Post by Gary Scott
In order to be analogous to I0 though wouldn't it need to trim both
leading and trailing spaces? I don't think that would be the usual
desire though, but maybe you could specify '0a0' to trim leading and
trailing spaces.

I don't there such a pressing need - I0 only removes leading spaces
(there are no trailing ones). A0 would only trim trailing spaces (can
use ADJUSTL in the unusual case of wanting to trim leading ones as
well).

I admit it would be a minor inconsistency in the language, but not
unlike the need to use 123_kind for an integer constant, but
kind_"string" for a character constant. People seem to cope with that.

[g***@lmco.com]

Post by Clive Page

Post by Gary Scott
In order to be analogous to I0 though wouldn't it need to trim both
leading and trailing spaces? I don't think that would be the usual
desire though, but maybe you could specify '0a0' to trim leading and
trailing spaces.

I don't there such a pressing need - I0 only removes leading spaces
(there are no trailing ones). A0 would only trim trailing spaces (can
use ADJUSTL in the unusual case of wanting to trim leading ones as
well).
I admit it would be a minor inconsistency in the language, but not
unlike the need to use 123_kind for an integer constant, but
kind_"string" for a character constant. People seem to cope with that.

If you're going to the trouble to introduce a trailing space trim
edit, I see no reason not to introduce a similar leading space trim
edit. I agree that it would be needed less frequently, but that's no
reason not to add it when it would be so easy to do so and provide a
more complete solution.

Post by Clive Page
--
Clive Page

[Clive Page]

Post by g***@lmco.com
If you're going to the trouble to introduce a trailing space trim
edit, I see no reason not to introduce a similar leading space trim
edit. I agree that it would be needed less frequently, but that's no
reason not to add it when it would be so easy to do so and provide a
more complete solution.

Well I suppose so. But, as "Beliavsky" pointed out, the problem is that
TRIM isn't an elemental function, whereas ADJUSTL is, so you can use it
with an array argument.

[Beliavsky]

Post by Richard Maine

Post by m***@athenavisual.com

Post by Beliavsky
I wish there were an "a0" format for character variables, analogous to
i0 for integers, which would not print trailing spaces in character
variables.

I am with you. Did you send your suggestion to Andy? Perhaps he can
implement it in g95

I don't see that as analogous. Or at any rate, I don't think it a robust
analogy.
The i0 for integers doesn't modify the value printed out. It just avoids
adding blank padding characters.
For the character case, you aren't talking about padding. Instead, you
are talking about modifying the value printed out, as the blanks are
part of the value.
Yes, they both result in fewer blanks, but I see them as conceptually
different.

Usually when I have a string with trailing blanks it is because
Fortran character variables have a fixed length, IMO an awkward
feature of the language. I think my proposal removes some of the
awkwardness . Many features have been added to Fortran edit
descriptors that are convenient but not absolutely necessary, for
example repeat edit descriptors (and the colon within them) or i0. I
am not sure that printf of C has analogs for all of these. I consider
the implied do loop an irregular feature of the language and try to
avoid using it. The feature is simple enough that I think it would be
used more than some of the other proposed features for Fortran 2008.

I would be wary of using the feature as hypothetical extension of g95
since I use the Intel and gfortran compilers as well.

[Walter Spector]

This post might be inappropriate. Click to display it.

[Dick Hendrickson]

Post by Walter Spector

Post by Beliavsky
...
Usually when I have a string with trailing blanks it is because
Fortran character variables have a fixed length, IMO an awkward
feature of the language. I think my proposal removes some of the
awkwardness...

Your idea, IMO, is a fine one. But it is worth noting is that in
F2003, Fortran character variables can have an 'allocatable' length.
Thus, the F2003 feature largely solves the Big Problem.
So I would rather advocate to my Fortran compiler vendors to get
moving on F2003 allocatable character string lengths, than introduce
yet another non-Standard edit descriptor that they then have to
support 'forever'.
Don't let me prevent you from suggesting it in the F2008 public
review though. I think it has some merit.
W.

I also would never even dream of trying to prevent anybody from
suggesting anything to anyone. But, as a practical matter, F2008
has a ton of new stuff and tight (internationally imposed) deadlines.
The odds of a new feature being accepted very late in the game are
rather small in my opinion. For good or bad, the public comment
period now seems to concentrate mostly on fixing errors and
inconsistencies and (occasionally) removing a feature that is
deemed to be unworkable or useless. A more practical thing would be to
build a consensus and work for F2013. Yes, that's a long time
from now. That's just all my personal opinion.

Dick Hendrickson

[John Harper]

Post by Beliavsky
Usually when I have a string with trailing blanks it is because
Fortran character variables have a fixed length, IMO an awkward
feature of the language.

Sometimes one wants the trailing blank, e.g.
PRINT "(A,I0)", ' n = ',n

-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail ***@vuw.ac.nz phone [phone] fax [phone]

[Beliavsky]

Post by Beliavsky
I wish there were an "a0" format for character variables, analogous to
i0 for integers, which would not print trailing spaces in character
variables.

In the absence of a0 one can write a function to join a 1-D array of
character variables, for example

module util_mod
implicit none
contains
function join(words,sep) result(str)
! trim and concatenate a vector of character variables,
! inserting sep between them
character (len=*), intent(in) :: words(:),sep
character (len=(size(words)-1)*len(sep) + sum(len_trim(words))) :: str
integer :: i,nw
nw = size(words)
str = ""
if (nw < 1) then
return
else
str = words(1)
end if
do i=2,nw
str = trim(str) // sep // words(i)
end do
end function join
end module util_mod
!
program xjoin
use util_mod, only: join
implicit none
character (len=5) :: words(2) = (/"two ","three"/)
write (*,"(1x,'words = ',a)") "'"//join(words," ")//"'"
end program xjoin

Compiling and running with g95, Lahey/Fujitsu, Compaq Visual Fortran,
and Intel Visual Fortran gives the output I expected,

words = 'two three'

Mingw Gfortran 20070406 inserts some extra characters, giving

words = 'two threeg9'

I have reported this at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31867

Salford/Silverfrost Ver. 5.01.0 crashes.