Roland Schilling writes:
> Yes, it does. Thanks a lot. Studying the rules for 'specification
> expressions' resulted in the understanding that I cannot solve my
> problem this way. What I really do not understand is why I'm not
> allowed to embed something like the trim command in a character
> function such that it returns the trimmed character string.
I'm not quite sure I understand the question. TRIM is PURE, so if
you had an application that needed it in a specification, then you
could use it (though len_tim generally seems more useful in
specifications).
I think you appear to be asking why you can't say something like
result = trim(string-expression)
and have the result take the length of the right-hand-side. If so,
that's because Fortran strings just don't work like that in any
context. You have to declare the length of a string in its
declaration. You can't just declare something to be a string that
changes its length according to what is assigned to it. This is
fundamental to the way Fortran strings are defined. Nothing special
about function results here. It would be quite anomalous to make
function results special in this regard.
If you are asking why Fortran strings are defined that way...thats a
much bigger question than just function results. Not one I have time
for.
If you want varying length strings, there is the ISO_VARYING_STRING
standard module (although it is the subject of at least some
controversy, but I'll not go into that). But basic Fortran strings
aren't like that.
> Yes, I know this, and I agree that this is another significant
> restriction. I can imagine why it is not allowed to do recursive
> I/O, as long as it is external I/O. But I cannot see why this
> restriction also applies to internal I/O. Hopefully these
> deficiencies will go away with F2K.
Yes. See my post from a few minutes ago on this.
--
Richard Maine
[log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|