Allocatable Character variables and Intrinsic Proceedures

[Qolin]

Am I missing something?

Seems like most of the intrinsic procedures do not support allocable
character arguments. Eg. GET_COMMAND: arg 1 is "default character scalar".
Same for arg 2 of GET_COMMAND_ARGUMENT, and relevant args of
GET_ENVIRONMENT_VARIABLE and DATE_AND_TIME.

Same also for NAME= on INQUIRE.

Today I was trying to use an INQUIRE statement to resolve a local filename
(i.e. one with a relative path) into one with a complete path starting from
the root of the file system. Having no real idea how long the result would
need to be, I fully expected the INQUIRE to support me passing an allocable
character variable, and have it re-allocate the result to the correct
length. I was disappointed. I had to resort to this:

!----------------------------------------------------
subroutine uu(fname,fullname)

character(*), intent(in) :: fname ! local or relative file name
character(:), allocatable, intent(out) :: fullname ! fully qualified
filename
logical hasname

call new_unit(ii) ! gets a free LUN
allocate(character(4096)::fname)
open(ii,file=fname)
inquire(unit=ii, name=fname)
fname = trim(fname)
close(ii)

end
!-------------------------------------------------

Qolin at domain dot com
domain is qomputing

[Richard Maine]

Qolin <no...@nowhere.com> wrote:

> Am I missing something?
>
> Seems like most of the intrinsic procedures do not support allocable
> character arguments.

That's correct. (Well, as your workround illustrates, the actual
argument may be an allocated allocatable, but the intrinsic won't do the
allocation for you).

It would not have been plausible for the argument to be required to be
allocatable because that would have broken absolutely every existing
code that used the intrinsic (there being no previously existing code
with allocatable character length).

At least by the "normal" rules of generic disambiguation, you can't
disambiguate based on the allocatable attribute. Thus you have to choose
either allocatable or not, and that choice could only have gone with not
allocatable. But.....

Intrinsics don't necessarily have to follow the same disambiguation
rules. It occurs to me that an intrinsic could be defined to allow
either allocatable or non-allocatable actual. One would have to decide
what to do with a previously allocated allocatable actual. I could see
argments for either leaving its allocation as is or reallocating it;
that would have to be hashed out. But I don't off-hand see any reason it
couldn't be done. I'll grant the possibility that I'm overlooking a
complication.

Of course, I lament that allocatable character length seems to be one of
the last f2003 features to be implemented by compilers.
<my usual whine mode>
If the standard after f2003 had waited until there was a decent amount
of actual experience with using compilers that implemented f2003,
perhaps issues like this might have gotten more attention. Hard to get
much good feedback when people don't have experience to base the
feedback on.
</my usual whine mode>

--
Richard Maine
email: last name at domain . net
domain: summer-triangle

[Qolin]

> "Richard Maine" wrote in message
> news:1ladk1b.1vmrkhdc07h1mN%nos...@see.signature...

>
> Qolin <no...@nowhere.com> wrote:
>
> > Am I missing something?
> >
> > Seems like most of the intrinsic procedures do not support allocable
> > character arguments.
>
> That's correct. (Well, as your workround illustrates, the actual
> argument may be an allocated allocatable, but the intrinsic won't do the
> allocation for you).
>
> It would not have been plausible for the argument to be required to be
> allocatable because that would have broken absolutely every existing
> code that used the intrinsic (there being no previously existing code
> with allocatable character length).
>
> At least by the "normal" rules of generic disambiguation, you can't
> disambiguate based on the allocatable attribute. Thus you have to choose
> either allocatable or not, and that choice could only have gone with not
> allocatable. But.....
>
> Intrinsics don't necessarily have to follow the same disambiguation
> rules. It occurs to me that an intrinsic could be defined to allow
> either allocatable or non-allocatable actual.

Yes that's what I had initially assumed would be the case.

> One would have to decide
> what to do with a previously allocated allocatable actual. I could see
> argments for either leaving its allocation as is or reallocating it;
> that would have to be hashed out.

That could be defined per-procedure.

> But I don't off-hand see any reason it
> couldn't be done. I'll grant the possibility that I'm overlooking a
> complication.

...getting back to your earlier point, it would be Really Useful if
an intrinsic function existed that inquired if a given variable was
allocatable. Somewhat akin to the PRESENT() intrinsic.

[glen herrmannsfeldt]

Qolin <no...@nowhere.com> wrote:

>> "Richard Maine" wrote in message
>> news:1ladk1b.1vmrkhdc07h1mN%nos...@see.signature...

>> Qolin <no...@nowhere.com> wrote:

(snip)

>> > Seems like most of the intrinsic procedures do not support allocable
>> > character arguments.

>> That's correct. (Well, as your workround illustrates, the actual
>> argument may be an allocated allocatable, but the intrinsic won't do the
>> allocation for you).

>> It would not have been plausible for the argument to be required to be
>> allocatable because that would have broken absolutely every existing
>> code that used the intrinsic (there being no previously existing code
>> with allocatable character length).

Adding new optional arguments (and if the original is optional)
could get around that. It looks a little ugly, but should work.

(snip)

>> Intrinsics don't necessarily have to follow the same disambiguation
>> rules. It occurs to me that an intrinsic could be defined to allow
>> either allocatable or non-allocatable actual.

(snip)

> ...getting back to your earlier point, it would be Really Useful if
> an intrinsic function existed that inquired if a given variable was
> allocatable. Somewhat akin to the PRESENT() intrinsic.

I think that could be done if there was a special attribute for
the dummy argument. Maybe something like OPTIONALLY_ALLOCATABLE.
(Otherwise, it just reports the attributes of an existing variable.
I suppose that has some use, but most programs should know which
are allocatable.)

But they way to get around it is to have two optional arguments,
one ALLOCATABLE and the other not. Use the one supplied.

It would also be nice (I think this hasn't been added yet) to have
optional arguments that exist as local variables when not supplied.
That saves a lot of work dealing with optional arguments that have
a default value.

-- glen

[Richard Maine]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> Qolin <no...@nowhere.com> wrote:
>
> >> "Richard Maine" wrote in message
> >> news:1ladk1b.1vmrkhdc07h1mN%nos...@see.signature...
>
> >> Qolin <no...@nowhere.com> wrote:

> >> > Seems like most of the intrinsic procedures do not support allocable
> >> > character arguments.
>
> >> That's correct. (Well, as your workround illustrates, the actual
> >> argument may be an allocated allocatable, but the intrinsic won't do the
> >> allocation for you).
>
> >> It would not have been plausible for the argument to be required to be
> >> allocatable because that would have broken absolutely every existing
> >> code that used the intrinsic (there being no previously existing code
> >> with allocatable character length).
>
> Adding new optional arguments (and if the original is optional)
> could get around that. It looks a little ugly, but should work.

I'd swear we had that discusion before, though perhaps it's just my
memory confusing something simillar. In either case, I'm not inclined to
debate the point at length, so I doubt I will continue on at least that
line after this reply, but in short....

No. Yukk.

And that "yukk" is more than just for aesthetics. Sometimes aesthetics
are a clue about more important things, as I'd say was strongly the case
here.

The point is to make things "just work" fairly naturally. If it is an
optional argument, then people are going to have to

1. Remember that it matters at all,

and

2. Drag out a manual and look up the name of the optional argument.
Every. Single. Time.

No, you aren't going to come up with names that people will consistently
remember. And even more fundamentally, they won't remember that they
have to use a "funny" name for the purpose at all.

So people will get it wrong and their programs will be buggy.

No. No. No. No. No.

I'd think it better to leave things as they are than to do that. It
seems like an addition of negative value.

Not that I'm one you really have to convince anyway as I'm no longer on
the committee, but I assure you that you'd never get my vote on that one
if I were. It wouldn't be worth trying. Not gonna work. I sort of doubt
it would go anywhere in any case.

[robin....@gmail.com]

fname? It's not allocatable. Does nothing.
fullname?

> close(ii)
> end
> !-------------------------------------------------

That is not something that's not insurmountable.
However, if you want something better, try PL/I,
which has varying-length strings, and for which
do not need to be "allocatable".

[Ron Shepard]

In article <1ladk1b.1vmrkhdc07h1mN%nos...@see.signature>,

nos...@see.signature (Richard Maine) wrote:

> Of course, I lament that allocatable character length seems to be one of
> the last f2003 features to be implemented by compilers.
> <my usual whine mode>

It would have been nice if allocatable character variables could be
used on the left hand of assignments, in input statements, and as
actual arguments in what, at least to me, seems the straightforward
way. Of these, I think only the first feature was included in their
definition. I don't know for sure because, as you say, they are not
implemented yet in most compilers, and here it is 10 years later.

It really is a shame that there is no good way in fortran to read
either character variables or numeric arrays of unknown length and
just have things work in a simple way.

$.02 -Ron Shepard

[Ian Harvey]

On 2013-10-08 8:13 AM, Qolin wrote:
> Am I missing something?
>
> Seems like most of the intrinsic procedures do not support allocable
> character arguments. Eg. GET_COMMAND: arg 1 is "default character
> scalar". Same for arg 2 of GET_COMMAND_ARGUMENT, and relevant args of
> GET_ENVIRONMENT_VARIABLE and DATE_AND_TIME.

Note that you can use those procedures to query the significant length
of the argument ahead of getting the actual value, i.e.

INTEGER :: length
CHARACTER(:), ALLOCATABLE :: command
CALL GET_COMMAND(LENGTH=length)
ALLOCATE(CHARACTER(length) :: command)
CALL GET_COMMAND(COMMAND=command)

This pattern of query-length, allocate, query-value is pretty typical in
some domains.

It is then pretty straight forward to wrap the above (plus error
handling) in a procedure that does it all for you. You don't even have
to worry about writing specific procedures for each character kinds,
because the intrinsics only work for default character kind.

> Same also for NAME= on INQUIRE.

This one is a nuisance, because (as far as I know... correct me if I'm
wrong) there is no way of querying the significant length of the name.

I regard this, and other examples (IOMSG is one that springs to mind)
where you cannot be confident of retrieving all the information
available, as a language defect.

Inquire would be relatively easy to fix - just add another specifier.
IOMSG specifiers... less so, particularly as they have implications for
programmer provided UDDTIO procedures.

[Ian Harvey]

On 2013-10-08 12:42 PM, Ron Shepard wrote:
> In article <1ladk1b.1vmrkhdc07h1mN%nos...@see.signature>,
> nos...@see.signature (Richard Maine) wrote:
>
>> Of course, I lament that allocatable character length seems to be one of
>> the last f2003 features to be implemented by compilers.
>> <my usual whine mode>

It seems to have been more of a middle-of-the-pack feature, rather than
one-of-the-last.

> It would have been nice if allocatable character variables could be
> used on the left hand of assignments, in input statements, and as
> actual arguments in what, at least to me, seems the straightforward
> way. Of these, I think only the first feature was included in their
> definition. I don't know for sure because, as you say, they are not
> implemented yet in most compilers, and here it is 10 years later.

Note you can have allocatable deferred length dummy argments. Given the
constraints of backwards compatibility this seems like a reasonable
method of "using" them as arguments.

Perhaps I'm being unfair (I'm not a compiler developer), but vendors
with actively developed compilers that haven't yet got around to
supporting deferred length allocatable character need a bit of a kick up
the backside.

> It really is a shame that there is no good way in fortran to read
> either character variables or numeric arrays of unknown length and
> just have things work in a simple way.

It is pretty straight-forward to write the short procedures necessary to
do both. If you allow the string or numeric data to be wrapped in a
derived type (in my experience, with the string case a suitable type
will already exist in many programs to allow for arrays of strings of
varying length) then the "call" just becomes a normal looking READ
statement.

[Richard Maine]

Ian Harvey <ian_h...@bigpond.com> wrote:

> On 2013-10-08 8:13 AM, Qolin wrote:

> > Same also for NAME= on INQUIRE.
>
> This one is a nuisance, because (as far as I know... correct me if I'm
> wrong) there is no way of querying the significant length of the name.

And file names can have significant trailing blanks on some systems, so
TRIM doesn't necessarily give what you want. On the other hand, Fortran
can't handle file names with significant trailing blanks anyway. (The
standard says that trailing blanks are always trimmed in interpreting
file names. Usually, well make that almost always, that's what you want.
But if you happened to want significant trailing blanks in a file name,
you are out of luck in straight Fortran. I suppose you could use C
interop stuff.)

[glen herrmannsfeldt]

Richard Maine <nos...@see.signature> wrote:

(snip, someone wrote)

>> >> It would not have been plausible for the argument to be required to be
>> >> allocatable because that would have broken absolutely every existing
>> >> code that used the intrinsic (there being no previously existing code
>> >> with allocatable character length).

(then I wrote)

>> Adding new optional arguments (and if the original is optional)
>> could get around that. It looks a little ugly, but should work.

> I'd swear we had that discusion before, though perhaps it's just my
> memory confusing something simillar. In either case, I'm not inclined to
> debate the point at length, so I doubt I will continue on at least that
> line after this reply, but in short....

It does seem familiar.

> No. Yukk.

> And that "yukk" is more than just for aesthetics. Sometimes aesthetics
> are a clue about more important things, as I'd say was strongly the case
> here.

Well, in most cases constant length strings should be fine
for DATE_AND_TIME. (You can add a few extra characters and it will
work for 5 and 6 digit years, though I don't expect Fortran to
last that long.)

For GET_ENVIRONMENT_VARIABLE, it isn't so obvious. Some systems might
allow rediculously long values.

I am not sure I coudldn't find other yucky Fortran features, but I
do agree it ins't so nice looking.

> The point is to make things "just work" fairly naturally. If it is an
> optional argument, then people are going to have to

> 1. Remember that it matters at all,

> and

> 2. Drag out a manual and look up the name of the optional argument.
> Every. Single. Time.

For GET_ENVIRONMENT_VARIABLE, value, length, status, and trim_name
are all optional arguments. At least for me, I would probably get
out the manual (I have the PDF ready to look at) each time for
some number of times.

Do you know how TRIM_NAME works without looking it up?

> No, you aren't going to come up with names that people will
> consistently remember. And even more fundamentally, they won't
> remember that they have to use a "funny" name for the
> purpose at all.

> So people will get it wrong and their programs will be buggy.

> No. No. No. No. No.

> I'd think it better to leave things as they are than to do that. It
> seems like an addition of negative value.

Well, the other possibility is to add a new intrinsis function.
As a function return value, does its length naturally get used
in assignment, with allocate on assignment?

> Not that I'm one you really have to convince anyway as I'm no
> longer on the committee, but I assure you that you'd never get
> my vote on that one if I were. It wouldn't be worth trying.
> Not gonna work. I sort of doubt it would go anywhere in any case.

No comment on the OPTIONALLY_ALLOCATABLE dummy arguments and
the IS_ALLOCATABLE function to test them?

-- glen

[Ron Shepard]

In article <l2vrls$2v3$1...@dont-email.me>,

Ian Harvey <ian_h...@bigpond.com> wrote:

> > It really is a shame that there is no good way in fortran to read
> > either character variables or numeric arrays of unknown length and
> > just have things work in a simple way.
>
> It is pretty straight-forward to write the short procedures necessary to
> do both.

Yes, I know. In fact, I posted some code here a while back to do
exactly that for integer arrays. But, it requires that you read the
data from the i/o library buffers into a linked list, then allocate
the output array, and copy it again from the linked list into the
output array. It would be much better if that middle step could be
eliminated.

$.02 -Ron Shepard

[Ian Harvey]

That's one possible implementation - "requires" is too strong.

An underlying runtime library is going to do something like that anyway.

Writing the procedure "once" is a bit of a nuisance, but it does given
you control over the process used, allowing the tradeoffs between things
like the number and size of allocations and the amount of data copying
to be made. My gripe is more that the generic programming gaps in the
language make that "once" less useful than it otherwise might be.

[Ian Harvey]

On 2013-10-08 2:31 PM, glen herrmannsfeldt wrote:
...

> No comment on the OPTIONALLY_ALLOCATABLE dummy arguments and
> the IS_ALLOCATABLE function to test them?

Nooooooooooooooooooooo.

[Richard Maine]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> For GET_ENVIRONMENT_VARIABLE, value, length, status, and trim_name
> are all optional arguments. At least for me, I would probably get
> out the manual (I have the PDF ready to look at) each time for
> some number of times.
>
> Do you know how TRIM_NAME works without looking it up?

I wasn't completely sure, but I checked and my guess was right. However,
and I think it a really important point rather than some nit, trim_name
is an arcane feature that almost nobody will never need to use. It is
there so that that arcane case can be handled when you really want it to
be. You can look it up in those arcane cases. (For those who might not
bother to look it up, trim_name is for the case where traling blanks in
an environment variable name are actually significant, which isn't going
to happen much.)

On the other hand, Qolin was talking about cases that are going to come
up all the time, and increasing over time. (Yes, I know I just implied
that it will start with always and then get more common, but I think
I'll leave it that way). Allocatable length character strings ought to
end up getting used darn near everywhere because they mostly act like
people intuitively expect character strings to act. Qolin was basicaly
pointing out exceptions to that "mostly".

> Well, the other possibility is to add a new intrinsis function.

That's got pretty much the same issue of remembering to use the right
one... and more so if there might be more than one argument of character
type. I don't see it as something that does very well at looking
forward.

I much better like the idea I mentioned of having it "just work". No
special attention required by the user. Unless you see some actual
reason why that can't be made to work, I see no point in comming up with
arcane hacks like essentially making two arguments or two intrinsics. If
it's just because you think a "clean" solution that involves a new
feature would be a harder sell than a hacked up one that uses only
existing features, I guess I just disagree. Might well be that none of
these would sell, but I'd think a clean solution would have better odds.
(It sure would with me).

> As a function return value, does its length naturally get used
> in assignment, with allocate on assignment?

I'll give the same answer I have given other people for other questions
relating to function returns and assignment in a much broader context:

If you have to put the words "function" and "assignment" in the same
question, then you are probably thinking of it all wrong. Functions have
pretty much nothing to do with assignment. Look at the definition of
assignment; you won't see anything about functions in it. And look at
the definition of a function reference; you won't see anything about
assignment in that.

Function references get used in expressions. Sometimes it is a trivial
expression consisting of the function reference as its only primary. But
it is still an expression. So you evaluate the expression using whatever
rules for expression evaluation apply. This has *NOTHING* to do with
whether or not the expression is used in an assignment. Yes, by the way,
an expression that consists of only a single primary has the same type
and type parameters as that primary.

Expressions get used in assignment statements (and other places).
Allocate-on-assignment has nothing to do with what might be inside of
the expression. It either happens or doesn't depending on the properties
of the variable and the expression result.

If you couldn't follow that, the short-form answer is "yes". But if you
need that short form, I'll continue to have to give you a fish every
meal. The real answer is to not think of functions and assignment as
having much to do with each other.

And, back to Qolin's question, this does imply that it is not an issue
for function returns - only for arguments.

> No comment on the OPTIONALLY_ALLOCATABLE dummy arguments and
> the IS_ALLOCATABLE function to test them?

Not really, because I didn't have much to say about them one way or
another without more thought than I had put into it. I sometimes (too
often) put my foot in my mouth by speaking up without thinking enough
first. But I do at least try to cut down on it.

Having thought about those questions at least a little more, though
certainly not yet enough, I'd say that they do seem like plausible
ideas. I had been thinking particularly about intrinsics. You don't need
things like that for intrinsics because you don't have to write the code
for intrinsics in Fortran. Intrinsics can sometimes do things that
user-written subroutines cannot.

But such an attribute and function might allow user-written procedures
to be written to act in the same kind of way.

I'm not sure there is as much need for it in user-written procedures.
The standard intrinsics have to cater to diverse environments, including
code written in different styles and different times. I'm not sure that
applies quite as much to user-written procedures. So that makes me
unsure of the priority of such a feature. But I can at least picture it
as plausible.

[glen herrmannsfeldt]

Richard Maine <nos...@see.signature> wrote:

(snip of previous discussion on allocating length of character
arguments to intrinsic functions)

(snip, I wrote)

>> As a function return value, does its length naturally get used
>> in assignment, with allocate on assignment?

> I'll give the same answer I have given other people for other questions
> relating to function returns and assignment in a much broader context:

> If you have to put the words "function" and "assignment" in the same
> question, then you are probably thinking of it all wrong. Functions have
> pretty much nothing to do with assignment. Look at the definition of
> assignment; you won't see anything about functions in it. And look at
> the definition of a function reference; you won't see anything about
> assignment in that.

> Function references get used in expressions. Sometimes it is a trivial
> expression consisting of the function reference as its only primary. But
> it is still an expression. So you evaluate the expression using whatever
> rules for expression evaluation apply. This has *NOTHING* to do with
> whether or not the expression is used in an assignment. Yes, by the way,
> an expression that consists of only a single primary has the same type
> and type parameters as that primary.

Yes I realize that, but having never used allocate character length
on assignment at all, I wasn't so sure about it.

> Expressions get used in assignment statements (and other places).
> Allocate-on-assignment has nothing to do with what might be inside of
> the expression. It either happens or doesn't depending on the
> properties of the variable and the expression result.

Yes, so it also has to work for expressions including such
functions.

> If you couldn't follow that, the short-form answer is "yes". But if you
> need that short form, I'll continue to have to give you a fish every
> meal. The real answer is to not think of functions and assignment as
> having much to do with each other.

Actually, after using Octave and Matlab for a little while, I
am starting to get used to it not being that way. Octave and
Matlab functions can find out how many variables the value is
assigned to. That is, optional return values.

p=polyfit(x,y,n)
[p,s]=polyfit(x,y,n)
[p,s,mu]=polyfit(x,y,n)

For polynomial fit of (x,y) points, where x and y are arrays,
and n is the degree of the desired polynomial to fit.
s and mu are optional return (intent(out)) values.

I think if you use it in an expression, only the first value
is returned, but I haven't tried that yet.

(snip)

-- glen

[Thomas Koenig]

Ian Harvey <ian_h...@bigpond.com> schrieb:

> Perhaps I'm being unfair (I'm not a compiler developer), but vendors
> with actively developed compilers that haven't yet got around to
> supporting deferred length allocatable character need a bit of a kick up
> the backside.

Nope, they need patches for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48923 .

Since you have strong opinions on the matter, and since you seem to have
as much background a compiler writer as I have (hint: I'm a chemical
engineer), don't let me stop you.

[robert....@oracle.com]

On Monday, October 7, 2013 7:59:24 PM UTC-7, Richard Maine wrote:

> And file names can have significant trailing blanks on some systems, so
> TRIM doesn't necessarily give what you want. On the other hand, Fortran
> can't handle file names with significant trailing blanks anyway. (The
> standard says that trailing blanks are always trimmed in interpreting
> file names. Usually, well make that almost always, that's what you want.
> But if you happened to want significant trailing blanks in a file name,
> you are out of luck in straight Fortran. I suppose you could use C
> interop stuff.)

The mapping of file names to files is. of course, processor dependent, but on UNIX and UNIX-like systems, an easy way handle file names with trailing blanks is to put a NUL character after the blanks. The Fortran processor will not trim the blanks because of the NUL character, and the open system call will not consider characters after the NUL character.

Bob Corbett

[robin....@gmail.com]

On Wednesday, October 9, 2013 9:44:52 AM UTC+11, robert....@oracle.com wrote:
> On Monday, October 7, 2013 7:59:24 PM UTC-7, Richard Maine wrote: > And file names can have significant trailing blanks on some systems, so > TRIM doesn't necessarily give what you want. On the other hand, Fortran > can't handle file names with significant trailing blanks anyway. (The > standard says that trailing blanks are always trimmed in interpreting > file names. Usually, well make that almost always, that's what you want. > But if you happened to want significant trailing blanks in a file name, > you are out of luck in straight Fortran. I suppose you could use C > interop stuff.) The mapping of file names to files is. of course, processor dependent, but on UNIX and UNIX-like systems, an easy way handle file names with trailing blanks is to put a NUL character after the blanks. The Fortran processor will not trim the blanks because of the NUL character, and the open system call will not consider characters after the NUL character.

No need to put funny characters (or any other character) to indicate
the end of a string in PL/I. Even if a string has trainling blanks,
when it is assigned to a VARYING string variable, the blanks are retained,
and the current length is the number of characters that were assigned.

[Ian Harvey]

On 2013-10-09 7:22 AM, Thomas Koenig wrote:
> Ian Harvey <ian_h...@bigpond.com> schrieb:
>
>> Perhaps I'm being unfair (I'm not a compiler developer), but vendors
>> with actively developed compilers that haven't yet got around to
>> supporting deferred length allocatable character need a bit of a kick up
>> the backside.
>
> Nope, they need patches for
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48923 .

I wasn't really considering the "our "product" can be used for free"
mobs as "vendors" per se - given that they don't really "vend" anything
- the comment was more directed at the commercial compiler domain, where
a little bit of competitive tension in feature set is to the benefit of
commercial compiler users.

> Since you have strong opinions on the matter, and since you seem to have
> as much background a compiler writer as I have (hint: I'm a chemical
> engineer), don't let me stop you.

Well, "strong" is a bit too strong - note the "Perhaps". When I wrote
that I thought any slighted vendors could have perhaps have a valid
comeback that Fortran 2003 was such a gob-smacking big addition to the
language that it would be delusional to expect things to move faster.
Then again, some of those changes were floating around as TR's for a
while before the full standard came out, and it is getting close to ten
years now, and deferred length character is pretty awesome... etc.

[William Clodius]

Ian Harvey <ian_h...@bigpond.com> wrote:

> On 2013-10-08 12:42 PM, Ron Shepard wrote:
> > In article <1ladk1b.1vmrkhdc07h1mN%nos...@see.signature>,
> > nos...@see.signature (Richard Maine) wrote:
> >
> >> Of course, I lament that allocatable character length seems to be one of
> >> the last f2003 features to be implemented by compilers.
> >> <my usual whine mode>
>
> It seems to have been more of a middle-of-the-pack feature, rather than
> one-of-the-last.
>
> > It would have been nice if allocatable character variables could be
> > used on the left hand of assignments, in input statements, and as
> > actual arguments in what, at least to me, seems the straightforward
> > way. Of these, I think only the first feature was included in their
> > definition. I don't know for sure because, as you say, they are not
> > implemented yet in most compilers, and here it is 10 years later.
>
> Note you can have allocatable deferred length dummy argments. Given the
> constraints of backwards compatibility this seems like a reasonable
> method of "using" them as arguments.
>
> Perhaps I'm being unfair (I'm not a compiler developer), but vendors
> with actively developed compilers that haven't yet got around to
> supporting deferred length allocatable character need a bit of a kick up
> the backside.

> <snip>
The big problem is that allocatable character lenth (ACL) has much of
the semantics of a significant sublet of parameterized derived types
(PDT). This makes it desirable for the vendors to map the structure for
ACL onto that of PDTs. If they implement ACL first, they may have to
reduo a substantial part of their effort once they implement PDTs, but
ACL by itself is easier to implement than PDTs in total, and it wouldn't
surprise me to find that the kind value aspects of PDTs are harder to
implemnt than the length aspects, and it certainly seems to have lower
demand among users.

[Richard Maine]

William Clodius <wclo...@earthlink.net> wrote:

> The big problem is that allocatable character lenth (ACL) has much of
> the semantics of a significant sublet of parameterized derived types
> (PDT). This makes it desirable for the vendors to map the structure for
> ACL onto that of PDTs. If they implement ACL first, they may have to
> reduo a substantial part of their effort once they implement PDTs, but
> ACL by itself is easier to implement than PDTs in total, and it wouldn't
> surprise me to find that the kind value aspects of PDTs are harder to
> implemnt than the length aspects, and it certainly seems to have lower
> demand among users.

This also provides an example of one of my regular gripes - that lists
of individual features selected from the standard are insufficient to
program based on. The standard is more than just a list of features.
Furthermore, there is no definitive guide to exactly what is part of any
particular feature.

The particular application here is that vendors have been known to
categorize allocatable character length as part of the PDT feature.
While that might make sense in terms of implementation strategy as you
explain, it leads to miscommunication because character is not, in fact,
a derived type. I've seen interchanges like

User: Why doesn't this code work?
Vendor: Because we don't support PDTs.
User: Huh? But this code doesn't involve any PDTs.

[Tobias Burnus]

Ian Harvey wrote:
> On 2013-10-09 7:22 AM, Thomas Koenig wrote:
>> Ian Harvey <ian_h...@bigpond.com> schrieb:
>>> Perhaps I'm being unfair (I'm not a compiler developer), but vendors
>>> with actively developed compilers that haven't yet got around to
>>> supporting deferred length allocatable character need a bit of a kick up
>>> the backside.
>>
>> Nope, they need patches for
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48923 .

I would rather link to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976
– and an incomplete patch also exists (see comment 9).

To solve that properly, we agreed that it can be best done when the new
array descriptor is ready, but that will surely take a while. [For
various reasons, gfortran needs a new internal representation of
assumed-shape/rank and deferred-shape arrays ("array descriptor", "dope
vector"). The new one will be compatible with TS29113 and a partial
implementation exists in the Fortran-dev branch.]

>> Since you have strong opinions on the matter, and since you seem to have
>> as much background a compiler writer as I have (hint: I'm a chemical
>> engineer), don't let me stop you.
>
> Well, "strong" is a bit too strong - note the "Perhaps".

Still, contributions to gfortran are highly welcome. If you know a
student, you would be interested to work on gfortran: In about half a
year, the next Google Summer of Code provides a means to do. But of
course anyone is welcome to join in as volunteer! As Thomas mentioned:
You do not need to be a specialist. Contributing to a compiler front-end
is not particularly difficult.

In addition, we are looking for someone to work on the coarray
communication library. That task doesn't require any compiler knowledge
and could be done in any language – even Fortran with some C binding.
(If one uses MPI for the actual communication, doing it in Fortran is
even simpler as MPI implementations ship with Fortran bindings. By
contrast, doing a POSIX threads implementation would require more C
bindings – or writing parts [or everything] in C. The idea is that one
can swap between different communication libraries, tailored for the
needs and systems [shared memory, existing MPI, directly using
Infiniband/Gemini, etc.])

Tobias