CALL for attention and discussion: recent paper comparing an equation solver implementation in Fortran vs C++ vs Python

[FortranFan]

Fortran enthusiasts may have seen and/or be interested in the findings and observations in a recent open literature publication by Arabas, et al. at the Institute of Geophysics at the University of Warsaw. Here's the link to this paper: http://arxiv.org/abs/1301.1334

It is very interesting to read Arabas et al. find "that C++11/Blitz++, Python/NumPy and Fortran 2008 provide comparable functionalities in terms of matching the blackboard abstractions within the program code. Taking into account solely the part of code representing particular formulæ (e.g. listings C.21, P.17, F.20 and equation 4) all three languages allow to match (or surpass) LATEX in its brevity of formula translation syntax. All three languages were shown to be capable of providing mechanisms to compactly represent such abstractions as: * loop-free array arithmetics; * definitions of functions returning array-valued expressions; * permutations of array indices allowing dimensionindependent definitions of unctions (see e.g. listings C.12 and C.13, P.10 and P.11, F.11 and F.12); * fractional indexing of arrays corresponding to employment of a staggered grid."

The authors make pointed comments about some of the limitations they faced with Fortran, "Three issues specific to Fortran that resulted in employment of a more repetitive or cumbersome syntax than in C++ or Python were observed: * Fortran does not feature a mechanism allowing to reuse a single piece of code (algorithm) with different data types (compare e.g. listings C.6, P.5 and F.4) such as templates in C++ and the so-called duck typing in Python; * Fortran does not allow function calls to appear on the left hand side of assignment (see e.g. how the ptr pointers were used as a workaround in the cyclic_fill_halos method in listing F.8); * Fortran lacks support for arrays of arrays (cf. Sect. 2.2)."

In addition, Fortran users won't be surprised to read the following, but would do well to make a note of it: "Fortran is a domain-specific language while Python and C++ are general-purpose languages with disproportionately larger users' communities. The OOP features of Fortran have not gained wide popularity among users. Fortran is no longer routinely taught at the universities [28], in contrast to C++ and Python. An example of decreasing popularity of Fortran in academia is the discontinuation of Fortran printed editions of the "Numerical Recipes" series of Press et al."

The paper points out a few other shortcomings in working with Fortran: " The built-in standard libraries of Python and C++ are richer than those of Fortran and offer versatile data types, collections of algorithms and facilities for interaction with host operating system. In the authors' experience, the small popularity of OOP techniques among Fortran users is reflected in the library designs (including the Fortran's built-in library routines). What makes correct use of external libraries more difficult with Fortran is the lack of standard exception handling mechanism, a feature long and much requested by the numerical community"

But the least surprising finding for die-hard Fortran coders will be, "The performance evaluation revealed that: * the Fortran set-up offered shortest execution times,"

What are your take-aways from this study? I request you all to post your comments.

[Beliavsky]

A previous thread on this topic

https://groups.google.com/forum/#!searchin/comp.lang.fortran/arabas/comp.lang.fortran/JAVkJG7dH10/KRjoaawceDEJ
Object-oriented numerics in C++, Python and modern Fortran: a case study comparison

drew one comment.

[FortranFan]

Sorry I missed the previous thread.

But hmmm.. surprised there was only one comment there - I was hoping for a healthy dissection of the authors' opinions (clearly skewed by their pre-existing preference for C++ and perhaps Python).

Of their 3 main complaints, only the one about templates feels genuine; the second complaint, I believe, is covered by Fortran 2008 and the third is probably due to a lack of full awareness of array capabilities in Fortran.

But I was also hoping for a constructive dialogue and introspection by the various Fortran enthusiasts on this forum on opinions expressed in the paper that might lead to some seeds that will eventually help Fortran grow to an even higher level, say in the future standards.

Finally, I was interested in someone analyzing figures 3, 4, and 5 in the paper and

1. Check whether the gfortran results make sense: with the other language combinations, unit results seem to improve as the problem size gets bigger (good scalability). But it is somewhat opposite with gfortran.

2. If the gfortran results do make sense, can they explain why that is the case? Or if not, venture a guess as to where and how the authors may have gone wrong?

Thanks,

[Ian Harvey]

On 2014-04-10 3:10 AM, FortranFan wrote:
...

> The authors make pointed comments about some of the limitations they
> faced with Fortran, "Three issues specific to Fortran that resulted
> in employment of a more repetitive or cumbersome syntax than in C++
> or Python were observed:


> * Fortran does not feature a mechanism allowing to reuse a single

> piece of code (algorithm) with different;

Sort of true, and sort of not true. There are reasonably well known
"tricks" that you can play with INCLUDE and implicit typing that allow
you to use a single piece of source code with different types. But it
is a bit of a hack and it I strongly think better support for "generic
programming" should be added to future revisions of the language.

If and when this feature is added to the language I hope that the
experience from C++ and other languages is taken into account - C++'s
template mechanism operates at a level that is marginally above dumb
token substitution. When things go wrong the programmer then tends to
get a morass of dumb error messages (mentioned in the paper). There
have been subsequent attempts by the C++ community to fix this at a
language level - I've lost track of where they are with that.

Consequently I hope that the Fortran approach comes in at a higher
level. Please make generic programming much more than just text
substitution.

> * Fortran does not allow function calls to appear on the left hand
> side of assignment

Not true - this was added to the language in Fortran 2008. But sort of
true, in that compiler support is very limited.

> * Fortran lacks support for arrays of arrays (cf. Sect. 2.2)."

It lacks built-in support for these - but as the authors have done, you
can easily enough define the type that achieves arrays of arrays, *and
then some*. When you look at the design in total (which requires full
F2003), I think it makes more sense.

At times this, and the resulting verbosity, has annoyed me, but I think
initially it is best dealt with using the generic programming alluded to
above. I have a half baked idea for some sort of "forwarding" system
for types that could help alleviate this too, plus offer other capability.

There is also an element of needing to adapt your coding style to suit
the idioms of the language here.

Related to this (because it is part of the broader language design) - if
they used (or were able to use) derived types with length type
parameters I think their code would be simplified somewhat. There are a
few things that are a little bit hacky that could probably be dispensed
with (e.g. use of allocatable attribute such that a dummy array argument
picks up the bounds of the actual argument), storing a length in
addition to the implicitly stored length of allocatable components, the
need to explicitly write a constructor for some types).

> "Fortran is a domain-specific language while Python and C++ are
> general-purpose languages with disproportionately larger users'
> communities."

True, though why "*dis* poprortionately"? The user base proportions
seem about right to me.

> The OOP features of Fortran have not gained wide popularity among
> users.

Without hard data to support my case, bar observation of forums and
newsgroups like this, I don't think this is a reasonable statement, or
requires qualification. Compiler support for this feature is still
relatively fresh - a mere five years ago I don't think it would have
been possible for these features to practically be used. Existing code
bases are also often subject to coding standards based on the available
language capability at the time the code base was commenced and there is
considerable inertia associated with revision of those coding standards.

Where compiler support and coding standards allow, I think these
features are reasonably popular.

The absence of editor syntax highlighting for some editors is one of the
reasons that the authors made this assertion. I think that not
particularly relevant (plus there are other editors in popular use out
there that do support the relevant highlighting).

> Fortran is no longer routinely taught at the universities [28],
> in contrast to C++ and Python. An example of decreasing popularity
> of Fortran in academia is the discontinuation of Fortran printed
> editions of the "Numerical Recipes" series of Press et al."

I think some of those observations are more a consequence of the domain
specific nature and potential user base size, or reflect real but now
historical decreases in the popularity of the language.

I suspect, again without hard data, the revisions to the language, in
F2003 in particular, have resulted in an increase in the popularity of
the language, in absolute terms.

> The built-in standard libraries of Python and C++ are
> richer than those of Fortran and offer versatile data types,
> collections of algorithms and facilities for interaction with host
> operating system.

The first part is true enough. The "interaction with host operating
system" part is a bit silly - it is a bit hard to imagine a practical
language (or language plus basic library) that didn't provide facilities
for interaction with the host operating system. By all means argue
about the scope of that interaction, but in terms of true standards, the
facilities provided with F2008 aren't that far removed from those
provided with C++.

> In the authors' experience, the small popularity of
> OOP techniques among Fortran users is reflected in the library
> designs (including the Fortran's built-in library routines).

Correlation is not cause. The designs of the "built in library"
(intrinsic procedures) and user libraries simply reflect the capability
of the language (and compilers for the latter) at the time the intrinsic
or user library thing was added.

"New" libraries written for the current standards and current compiler
capability use new language features.

> What makes correct use of external libraries more difficult with Fortran
> is the lack of standard exception handling mechanism, a feature long
> and much requested by the numerical community

Really? As a former C++ programmer, this surprises me - exceptions
aren't something I particularly miss. I think they have their uses in
the context of that language, but even then, there's much debate about
when and how exceptions should be used.

You need to adapt your coding style to suit Fortran, but that adaptation
isn't exactly extreme or unnatural.

C doesn't have a standard exception handling mechanism, but that doesn't
appear to have constrained the range of libraries available for or
written in that language. As of F2003, those libraries are practically
easy enough to use from standard Fortran too. Given the experience of
that language, I think the rationale in the quoted sentence is rather
dubious.

Some capability for handling numerical "exceptions" has been added to
the language - with the IEEE stuff.

That said, I would like to see more general purpose libraries written
for Fortran. I think some aspects of the language do hinder the writing
of those libraries - here I will plug the generic programming angle
again. I think it is a mistake to try and load too much stuff into the
intrinsic procedure side of things.

I see some familiar names in the Acknowledgements!

I had a quick look at the code. It makes user of pointer result
functions (and pointers in general) which makes me a bit nervous, but
I'd have to spend more time understanding how they work things in order
to comment further. Perhaps not material, but there are a few arguments
could do with the INTENT attribute, a few functions could be marked
PURE, I think there might be the occasional stray POINTER attribute and
naming free form source with a .f extension is a bit odd).

[Wolfgang Kilian]

To be fair, they didn't test languages but language implementations.
gfortran did perform very well in this test, but it is not the only
implementation.

I do agree with Ian's comments regarding generic programming support.
Since parameterized derived types are already there, why not extend this
facility and make it really useful -- similar to the approach pursued in
modern functional languages.

-- Wolfgang

--
E-mail: firstnameini...@domain.de
Domain: yahoo

[Phillip Helbig---undress to reply]

In article <li4r2b$5no$1...@dont-email.me>, Ian Harvey

<ian_h...@bigpond.com> writes:

> > * Fortran does not allow function calls to appear on the left hand
> > side of assignment
>
> Not true - this was added to the language in Fortran 2008. But sort of
> true, in that compiler support is very limited.

Can you give an example of this, illustrating its utility?

[Jos Bergervoet]

On 4/9/2014 7:10 PM, FortranFan wrote:
...

> It is very interesting to read Arabas et al. find "that

> C++11/Blitz++, Python/NumPy and Fortran 2008 provide ..
.. [snip]
> .. all three languages allow to match (or surpass) LATEX

> in its brevity of formula translation syntax.

OK, then I think I'll stop using LaTeX now for
numerical computations!

> ...

> "The performance evaluation revealed that: * the
> Fortran set-up offered shortest execution times,"

But if I use Fortran for text processing, does it
support proportional fonts?

--
Jos

[Ian Harvey]

MODULE m
IMPLICIT NONE
REAL, TARGET :: array(3)
CONTAINS
! Some sort of silly indexing.
FUNCTION ref(name)
CHARACTER(*), INTENT(IN) :: name
REAL, POINTER :: ref
!***
SELECT CASE (name)
CASE ('cat') : ref => array(1)
CASE ('dog') : ref => array(2)
CASE DEFAULT : ref => array(3)
END SELECT
END FUNCTION ref
END MODULE m

PROGRAM p
! F2015 proposal with much vendor resistance.
! OPTION JUST_FIX_ALL_MY_UNINTENTIONAL_BUGS_PLEASE
USE m
IMPLICIT NONE
!****
! F2008 (as of corrigendum 3) allows a variable to be
! a /function-reference/ with a data pointer result. That
! means it can be used on the left hand side of an
! assignment statement.
ref('cat') = 1.0
! It can also be used in an /input-item-list/.
READ (*,*) ref('dog')
! It can also be associated with an intent(out) argument.
CALL define(ref('zebra'))
PRINT *, array
CONTAINS
SUBROUTINE define(arg)
REAL, INTENT(OUT) :: arg
arg = 3.0
END SUBROUTINE define
END PROGRAM p

[Jos Bergervoet]

On 4/10/2014 10:26 AM, Ian Harvey wrote:
..

> PROGRAM p
> ! F2015 proposal with much vendor resistance.
> ! OPTION JUST_FIX_ALL_MY_UNINTENTIONAL_BUGS_PLEASE
> USE m
> IMPLICIT NONE
> !****
> ! F2008 (as of corrigendum 3) allows a variable to be
> ! a /function-reference/ with a data pointer result. That

Why does the comment on top say "F2015 proposal"
if it is in F2008 (as of corrigendum 3)?

--
Jos

[Ian Harvey]

My understanding is that the option to fix all unintentional programmer
bugs failed to make the cut for F2008.

[Jos Bergervoet]

Yes, the vendors could not agree on the syntax! It
will now be implemented as:

option :: auto_fix_bugs = .true. ! In f8002, as of corrigendum 3

--
Jos

[FortranFan]

On Thursday, April 10, 2014 3:53:23 AM UTC-4, Phillip Helbig---undress to reply wrote:

> In article Ian Harvey writes:
>
>
>
> > > * Fortran does not allow function calls to appear on the left hand
>
> > > side of assignment
>
> >
>
> > Not true - this was added to the language in Fortran 2008. But sort of
>
> > true, in that compiler support is very limited.
>
>
>
> Can you give an example of this, illustrating its utility?

In addition to Ian's reply, see this thread on this forum at https://groups.google.com/forum/#!topic/comp.lang.fortran/8Q8_j31M5BE. Michael Metcalf provides another example here which is also in Metcalf et al., "Modern Fortran Explained". In it, they say such a feature is useful for "so-called accessor functions, instrumented access, etc.".

Basically such a features will also make possible to implement the "syntactic sugar" of "properties" in OOP constructs in Fortran.

One place where I'd consider using such a capability would be tagging unit-of-measure information to some data. After all, a big use of Fortran is in scientific, engineering, and technological applications which invariably have quantities that are meaningless unless their unit-of-measure information is known. So say I've a class foo which has temperature as one of its fields. With this new Fortran 2008 feature, I hope to be able to do:

type(foo) :: bar
..
bar%T("K") = 273.15_wp
..
!.. later I want T in Fahrenheit unit for reporting
result = bar%T("F")
..

Such a capabilitiy makes use of POINTER functions and I know Richard Maine has warned about this on many, many occasions on this forum. So we'll have to see if such "syntactic sugar" is worth it. But the compilers have to make this available first; I believe only Cray compiler has it at present.

[FortranFan]

Thanks, Ian, for your detailed analysis - I find it very helpful.

Do you have any comments on figures 3, 4, and 5 in the paper? Do the performance results make sense to you, especially how C++ and Python show significant improvement as problem size increases whereas gfortran goes the other way, albeit with a smaller, absolute rate of change?

[Arjen Markus]

On Thursday, April 10, 2014 2:55:41 PM UTC+2, FortranFan wrote:

> One place where I'd consider using such a capability would be tagging unit-of-measure information to some data. After all, a big use of Fortran is in scientific, engineering, and technological applications which invariably have quantities that are meaningless unless their unit-of-measure information is known. So say I've a class foo which has temperature as one of its fields. With this new Fortran 2008 feature, I hope to be able to do:
>
>
>
> type(foo) :: bar
>
> ..
>
> bar%T("K") = 273.15_wp
>
> ..
>
> !.. later I want T in Fahrenheit unit for reporting
>
> result = bar%T("F")
>

You can achieve this in a much easier way already within Fortran 90. See for instance: http://sleet.aos.wisc.edu/~gpetty/wp/?page_id=684

(There has been a more extensive discussion on the LinkedIn Fortran group, some one or two years ago about features that make this possible. Things are not all that trivial if you want to go beyond the basics.)

Regards,

Arjen

[FortranFan]

Arjen,

We're talking two separate things: the link you provide discusses the general issue of dimensional analysis of quantities and how to go about implementing them: a good Linear Algebra application with some arithmetic. In my case, I already have a very robust and extensive library that does this; for me, it is a solved problem but a separate aspect altogether.

I was referring to a simple, practical use case of the new Fortran 2008 feature. If I want to use the same moniker, say T, in both the left-hand side and right-hand side of assignments in code, there is no easy way to do this currently without this new feature. The use of the same moniker is "syntactic sugar" and it makes it very easy for consumers of one's OOP class. You may know Microsoft .NET developers use it all the time (e.g., "indexer" classes in C#).

[Wolfgang Kilian]

On 04/10/2014 03:51 PM, FortranFan wrote:
> On Thursday, April 10, 2014 9:29:15 AM UTC-4, Arjen Markus wrote:
>> On Thursday, April 10, 2014 2:55:41 PM UTC+2, FortranFan wrote:
>>
>>
>>
>>> One place where I'd consider using such a capability would be tagging unit-of-measure information to some data. After all, a big use of Fortran is in scientific, engineering, and technological applications which invariably have quantities that are meaningless unless their unit-of-measure information is known. So say I've a class foo which has temperature as one of its fields. With this new Fortran 2008 feature, I hope to be able to do:
>>

[...]

>
> We're talking two separate things: the link you provide discusses the general issue of dimensional analysis of quantities and how to go about implementing them: a good Linear Algebra application with some arithmetic. In my case, I already have a very robust and extensive library that does this; for me, it is a solved problem but a separate aspect altogether.
>
> I was referring to a simple, practical use case of the new Fortran 2008 feature. If I want to use the same moniker, say T, in both the left-hand side and right-hand side of assignments in code, there is no easy way to do this currently without this new feature. The use of the same moniker is "syntactic sugar" and it makes it very easy for consumers of one's OOP class. You may know Microsoft .NET developers use it all the time (e.g., "indexer" classes in C#).

The short version is that in the context of data hiding, with F2008 you
don't need to write separate 'setter' and 'getter' methods for some
subobject that should be exposed, a single 'accessor' method is now
sufficient.

[Arjen Markus]

Right, my mistake - I was focusing on the details of your example (comes from being a physicist I suppose who is sometimes confronted with rather curious practices vis-a-vis units - think of empirical formulae with numbers that have vague dimensions).

I do kind-of like this F2008 feature, but I was thinking more along the lines of associative arrays/dictionaries and the like.

Regards,

Arjen

[Dick Hendrickson]

My recollection is that the problem isn't so much with the function
notation, but the fact that function references can also be "spelled" as
either
this .op_name. that
or
.op_name. that
and there was(is?) a parsing ambiguity someplace. I can't remember
where, but I think it was in I/O statements. Bob Corbett might remember
the details; I think he found (at least) one of the problems.

There were a few interps about this for 2008; some possibly still active.

Dick Hendrickson

[Jos Bergervoet]

On 4/10/2014 2:55 PM, FortranFan wrote:
...

> type(foo) :: bar
> ..
> bar%T("K") = 273.15_wp
> ..
> !.. later I want T in Fahrenheit unit for reporting
> result = bar%T("F")
> ..
> Such a capabilitiy makes use of POINTER functions and

I know Richard Maine has warned about this on many, many

occasions on this forum.

Weren't his warnings more against pointer variables? I
think conceptually they are not the same. In Algol68 a
pointer variable would be:
Ref Ref Int
whereas the left-hand side of an assignment only needs:
Ref Int
and of course the rhs will be content with
Int

In Fortran these would be, respectively:
integer, pointer
integer
integer, parameter

In practice, the difference is of course that the user
can re-associate a pointer with a different address and
a variable has a fixed address (and a constant is a
mathematical archetype with no address needed).

In the case at hand, the user of:

bar%T("K") = 273.15_wp

should *not* be able to re-associate this with a new
memory location, but merely to store a value in it (at
the already existing memory location). I'm not sure
whether F2008 has this indeed worked out in that way,
but if so, then the user cannot do the bad things(TM)
that usually are done (routinely) with pointers.

Another matter is that in the implementation of this
accessor function there might be explicit use of
pointers, so we have to assume that part is written
by a skilled programmer (but we have to assume that
form many critical routines anyway).

Now back to the F2008 implementation: is the user of
the accessor function allowed to do things like
bar%T("K") => another_loc
or is than nicely forbidden?

--
Jos

[Richard Maine]

Jos Bergervoet <jos.ber...@xs4all.nl> wrote:

> On 4/10/2014 2:55 PM, FortranFan wrote:

> > Such a capabilitiy makes use of POINTER functions and
>
> I know Richard Maine has warned about this on many, many
> occasions on this forum.
>
> Weren't his warnings more against pointer variables?

Nope. Well, I've warned about pointer variables, but much more mildly.

It is easy to make errors with pointer variables. For many uses,
allocatables serve the need with much less opportunity for user error.
Allocatables seem to have more opportunity for compiler errors, perhaps
because compilers get stuck with some of the trickier bits instead of
making the user do them. But compilers have gotten better in that area.
Still, there are plenty of contexts where allocatables do not fit the
need at all and pointer variables are by far the best fit.

It is functions returning pointers that I have most stringently warned
about. One might be well justified in saying that I have ranted about
them rather than just warned. My comments about pointer variables don't
go past the warning level.

I have several times said that I wish the language did not even allow
functions that return pointers. I consider them to be *VERY* error
prone, far more so than just pointer variables. And I don't see that
they add any useful functionality to compensate for their error-prone
nature. Heck, postings here that were intended to show "good" uses have
managed to illustrate some of the errors, in particular the error of
using

p = pointer_function(stuff)

instead of

p => pointer_function(stuff)

I'll grant that things like the f2008 features mentioned in this thread
do add at least some useful functionality to compensate - far more so
than up through f2003.

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

[glen herrmannsfeldt]

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

(snip)

> It is easy to make errors with pointer variables. For many uses,
> allocatables serve the need with much less opportunity for user error.

List and tree processing are commonly done with pointers, and
having functions that return them can be convenient.

But having arrays of pointers could also be convenient, so I suppose
functions returning structure containing pointers would probably
be about as useful.

(snip on allocatables)

> It is functions returning pointers that I have most stringently warned
> about. One might be well justified in saying that I have ranted about
> them rather than just warned. My comments about pointer variables don't
> go past the warning level.

> I have several times said that I wish the language did not even allow
> functions that return pointers. I consider them to be *VERY* error
> prone, far more so than just pointer variables. And I don't see that
> they add any useful functionality to compensate for their error-prone
> nature. Heck, postings here that were intended to show "good" uses have
> managed to illustrate some of the errors, in particular the error of
> using

> p = pointer_function(stuff)

> instead of

> p => pointer_function(stuff)

Seems likely that C and Java programmers would do that.

It is a little confusing in C, but in Java objects are always
processed as references. Methods can return references to objects,
which will be described as returning the object. It only takes
a little getting used to, and then everything is consistent.

I still haven't tried any Object-Oriented Fortran programming, but
I expect that one will get used to functions returning pointers
to objects. (Once one remembers the => every time.)

> I'll grant that things like the f2008 features mentioned in this thread
> do add at least some useful functionality to compensate - far more so
> than up through f2003.

-- glen

[FortranFan]

On Thursday, April 10, 2014 12:42:22 PM UTC-4, Richard Maine wrote:
> Jos Bergervoet wrote:
>
> >..

> >
> > Weren't his warnings more against pointer variables?

> > ..

>
>
> Nope. Well, I've warned about pointer variables, but much more mildly.
>

> ...

>
> It is functions returning pointers that I have most stringently warned
> about.
>

> ...

Note the functionality in question is indeed achieved by a function that returns a pointer. Please note John Reid explains this in his ISO/IEC JTC1/SC22/WG5 N1828 publication titled "The New Features of Fortran 2008" (dated May 2010) as follows:

6.5 Pointer functions
A reference to a pointer function is treated as a variable and is permitted in any variable definition context. For example, this function might calculate where to store values depending on a key:

function storage(key) result(loc)
integer, intent(in) :: key
real, pointer :: loc
loc => ...
end function

which would allow a value to be set thus:

storage(5)=0.5

[glen herrmannsfeldt]

FortranFan <pare...@gmail.com> wrote:

(snip)

> Note the functionality in question is indeed achieved by a
> function that returns a pointer. Please note John Reid
> explains this in his ISO/IEC JTC1/SC22/WG5 N1828 publication
> titled "The New Features of Fortran 2008" (dated May 2010)
> as follows:

(snip)

> function storage(key) result(loc)
> integer, intent(in) :: key
> real, pointer :: loc
> loc => ...
> end function

> which would allow a value to be set thus:

> storage(5)=0.5

Well, you can have functions on the left of the equal sign in
Fortran 77, for example inside subscripts. Again, they indicate
where (in an array) a value should go.

On the other hand, you could write a function (or subroutine) to
store the value in the right place:

call store(5, 0.5)

Otherwise, the closest thing to actual functions on the left is
the PL/I pseudo-variable:

SUBSTR(X,3,4)="abcd";

assigns the string to the appropriate character(s) in X.

Or:

DCL I FIXED COMPLEX BIN(31,0) INITIAL(0);

DO IMAG(I)=1 TO 100;
PUT SKIP LIST(I, SIN(I));
END;

This uses both the IMAG built-in function and IMAG pseudo-variable.

Some might instead do:

DO I=1I BY 1I WHILE(ABS(I)<=100);
PUT SKIP LIST(I, SIN(I));
END;

(You can't use TO when the test expression is complex.)
I presume no plans to allow complex variables in Fortran DO loops.

-- glen

[Jos Bergervoet]

On 4/10/2014 6:42 PM, Richard Maine wrote:
> Jos Bergervoet<jos.ber...@xs4all.nl> wrote:
...

>> Weren't his warnings more against pointer variables?
>
> Nope. Well, I've warned about pointer variables, but much more mildly.
>
> It is easy to make errors with pointer variables. For many uses,
> allocatables serve the need with much less opportunity for user error.

I fully agree. So if pointer variables are not used,
what else could go wrong here?

> It is functions returning pointers that I have most stringently warned
> about. One might be well justified in saying that I have ranted about
> them rather than just warned. My comments about pointer variables don't
> go past the warning level.

Thanks for clarifying your position again. But still I don't
see why this necessarily applies here, to:

"function calls to appear on the left hand side of assignment"

because *that* was the functionality that OP's paper required!

> I have several times said that I wish the language did not even allow
> functions that return pointers.

But for lhs of assignment you *do not need* a pointer variable!
The only thing you need is that it acts as a variable.

Apparently Fortran failed to see that between a constant
and a pointer there is the ordinary variable:

1) The normal function result in Fortran behaves as an object
declared with the "parameter" attribute (a constant).
2) What we need here is is a function result behaving like
something *without* the parameter attribute (a variable).
3) What we *do not need* is going one step further and having
the function result behave like a pointer!

> ... in particular the error of using
>
> p = pointer_function(stuff)

What error?! This is exactly the use that OP's paper (and
Ian Harvey in his reply likewise) would want to make of the
accessor function. Of course you shouldn't call it "pointer"!

x = accessor_function(stuff) ! already works
accessor_function(stuff) = y ! acts as a "variable"

You see? Only variables used. Also the function result
should be a variable (your naming it "pointer_function"
seems to reveal the wrong way of Fortran's solution!)

> instead of
> p => pointer_function(stuff)

Ouch! What would that have to do with it?! Here we clearly
have a *pointer variable* p, that causes the danger. People
should not use them, allocatables are safer as we agreed!
Having this p would allow the user

p => any_ordinary_variable ! So why is this OK?
p => accessor_function(stuff) ! and why ranting here?!

both could leave dangling references. Just don't use
pointers!

> I'll grant that things like the f2008 features mentioned in this thread
> do add at least some useful functionality to compensate - far more so
> than up through f2003.

Accessor functions simply are a requirement that many
people will make of a language. It should *not* allow

accessor_function(stuff) => some_target

so in that respect these functions are *not* dangerous
like pointers. You haven't given any proof otherwise!

--
Jos

[Richard Maine]

Jos Bergervoet <jos.ber...@xs4all.nl> wrote:

> On 4/10/2014 6:42 PM, Richard Maine wrote:

> > It is functions returning pointers that I have most stringently warned
> > about. One might be well justified in saying that I have ranted about
> > them rather than just warned. My comments about pointer variables don't
> > go past the warning level.
>
> Thanks for clarifying your position again. But still I don't
> see why this necessarily applies here, to:
> "function calls to appear on the left hand side of assignment"
> because *that* was the functionality that OP's paper required!

You elided the part where I said:

>> I'll grant that things like the f2008 features mentioned in this
>> thread do add at least some useful functionality to compensate - far
>> more so than up through f2003.

It was things like pointer functions used as accessors that I was
talking about as f2008 features there.

> > I have several times said that I wish the language did not even allow
> > functions that return pointers.
>
> But for lhs of assignment you *do not need* a pointer variable!
> The only thing you need is that it acts as a variable.

Guess I'm not following what you are saying about there.

> Apparently Fortran failed to see that between a constant
> and a pointer there is the ordinary variable:

In Fortran a pointer *IS* a variable. I have been known to suggest that
Fortran pointers might have been more accurately described as aliases.

> 1) The normal function result in Fortran behaves as an object
> declared with the "parameter" attribute (a constant).
> 2) What we need here is is a function result behaving like
> something *without* the parameter attribute (a variable).
> 3) What we *do not need* is going one step further and having
> the function result behave like a pointer!

I think you are going a bit far with the analogies. Parameter implies a
lot more than is relevant here. And, as noted above, a pointer *IS* a
variable. Fortran pointers are completely different from C ones in this
regard.

> > ... in particular the error of using
> >
> > p = pointer_function(stuff)
>
> What error?!

There error that this is making in almost every instance where this
actually appears in code today. Yes, it is a legal statement (given
appropriate context). No, it is almost never what the writer intended.
I'm aware that a writer could legally intend such a thing; that's not
the point at all. But in my observation of actual practice almost all
instances of this form that are written are intended to be pointer
assignment. The resulting code runs (maybe), but doesn't do anything
particularly close to what was intended. Or worse, it happens to give
good results in a test run, but garabage when run for real.

> > p => pointer_function(stuff)
>
> Ouch! What would that have to do with it?! Here we clearly
> have a *pointer variable* p, that causes the danger. People
> should not use them, allocatables are safer as we agreed!

Um. No, it doesn't sound like we agreed.

I agreed only that allocatables are safer *WHERE THEY APPLY*. There are
plenty of cases where allocatables do not come close to applying well.
As Glen mentioned, basic data structures like lists and trees are like
that. Yes, people write pointer functions for them regularly. And those
pointer functions are intended to be used in pointer assignments like
that. But people acidentally write = instead of "=>" and then their code
fails. If you don't think people ought to write code like that, then we
agree on that part. But they *DO* write it. And it is often buggy.

I have no problem at all with people using pointers for structures like
that. That's what I use. I just think they shouldn't use functions that
return those pointers. I think subroutines should be used instead.

[Jos Bergervoet]

On 4/10/2014 8:43 PM, FortranFan wrote:
> On Thursday, April 10, 2014 12:42:22 PM UTC-4, Richard Maine wrote:
...
>> It is functions returning pointers that I have most stringently warned
>> about.
...
> Note the functionality in question is indeed achieved by
> a function that returns a pointer.

Are you sure?

> Please note John Reid explains this in his ISO/IEC
> JTC1/SC22/WG5 N1828 publication titled "The New Features
> of Fortran 2008" (dated May 2010) as follows:
>
> 6.5 Pointer functions
> A reference to a pointer function is treated as a variable

There! It is a variable. The term "pointer function"
seems to be just a misnomer then. "Accessor function"
would have been just as good and would not have led
to this confusion. If the result is "treated as a
variable" then let's assume that it looks, swims, and
quacks like a variable, so don't call it a pointer then!

The situation is quite similar to ordinary functions:
a reference to them is treated like a constant. Even
though *inside* the function the result is not a
constant, but a variable. But at the moment the
function *returns* its result, this result is degraded
from variable to constant!

Likewise, at the moment this "pointer function" returns
its result, this is degraded from pointer to ordinary
variable. And I might hope that Richard has nothing
against ordinary variables..

--
Jos

[Jos Bergervoet]

On 4/11/2014 12:16 AM, Richard Maine wrote:
> Jos Bergervoet<jos.ber...@xs4all.nl> wrote:
>> On 4/10/2014 6:42 PM, Richard Maine wrote:

..

>>> I have several times said that I wish the language did not even allow
>>> functions that return pointers.
>>
>> But for lhs of assignment you *do not need* a pointer variable!
>> The only thing you need is that it acts as a variable.
>
> Guess I'm not following what you are saying about there.

Answered in the other post
<53471979$0$2961$e4fe...@news2.news.xs4all.nl>
after FortranFan, who mentioned John Reid's explanation.
Acting as a variable or as a pointer is the essential
point here indeed!

>> Apparently Fortran failed to see that between a constant
>> and a pointer there is the ordinary variable:
>
> In Fortran a pointer *IS* a variable. I have been known to suggest that
> Fortran pointers might have been more accurately described as aliases.

They have one more level of indirection than a variable.
A constant pointer is a variable, but a changing one is
a variable variable! (Like the Ref Int and the Ref Ref Int
in Algol68. It's old theory now, but still valid.)

...

>> 1) The normal function result in Fortran behaves as an object
>> declared with the "parameter" attribute (a constant).
>> 2) What we need here is is a function result behaving like
>> something *without* the parameter attribute (a variable).
>> 3) What we *do not need* is going one step further and having
>> the function result behave like a pointer!
>
> I think you are going a bit far with the analogies. Parameter implies a
> lot more than is relevant here.

Let's forget the irrelevant things for the moment!

> And, as noted above, a pointer *IS* a variable.

No, there are several things you can do with a pointer
that can not be done with a variable, so the two concepts
are not identical. What *would* be almost identical is a
variable and a constant pointer. Something like:
real :: x, y, z
real, pointer, parameter :: p => y ! if this existed
*Now* the same kind of assignments can be made with p
that can be made with the ordinary variables, but no
extra ones are allowed!

> Fortran pointers are completely different from C ones in this
> regard.

Yes, instead they are like Algol68 "Ref Ref Basetype".

>>> ... in particular the error of using
>>>
>>> p = pointer_function(stuff)
>>
>> What error?!
>
> There error that this is making in almost every instance where this
> actually appears in code today. Yes, it is a legal statement (given
> appropriate context). No, it is almost never what the writer intended.

Ehh.. what is intended then??! The accessor function
acts just like an array element: you can use its value
*and* you can write another value into it. What is
bothering you about it? (And please stop calling it a
pointer_function!) What is wrong with

real :: a(0:9)
p = a(2)

and why would it *not* do what the writer intended?
The accessor function does the same and I think users
would expect exactly that: behavior as if you work
with an array element.

> I'm aware that a writer could legally intend such a thing;

It is not clear! What is "such a thing" supposed to be?
(And why couldn't the same happen for an array element?)

--
Jos

[Richard Maine]

Jos Bergervoet <jos.ber...@xs4all.nl> wrote:

> On 4/10/2014 8:43 PM, FortranFan wrote:

> > 6.5 Pointer functions
> > A reference to a pointer function is treated as a variable
>
> There! It is a variable. The term "pointer function"
> seems to be just a misnomer then. "Accessor function"
> would have been just as good and would not have led
> to this confusion. If the result is "treated as a
> variable" then let's assume that it looks, swims, and
> quacks like a variable, so don't call it a pointer then!

See my other post. You seem to be under some impression that a pointer
in Fortran is not a variable. It is. More precisely, it is a variable
with the pointer attribute.

If you don't like that terminology, well... perhaps I can understand
that dislike. I don't particularly like Fortran's pointer terminology
either, though the aspects of it that I dislike might not be the same
ones that you do. (I'd have called them something like aliases instead
of pointers).

Nonetheless, that *IS* the terminology used by Fortran and has been
since pointers were introduced to the standard in f90. That aspect is
not new to the f2008 features mentioned. Dislike it as you might, but I
don't think you have much chance of tearing out the whole descriptive
mechanism of pointers in Fortran and redoing it.

If you try such a wholesale redescription of them, you would end up with
syntax that doesn't match the new description. Not that Fortran doesn't
already have enough cases of that. For example, the EXTERNAL attribute
does not declare something to be external; I really dislike that one.
And the PARAMETER atribute doesn't technically declare something to be a
parameter; it declares it to be a named constant. And although the
PUBLIC attribute does declare something to be public, the PRIVATE
attribute does not declare something to be private; that last one is
really tricky and was the subject of some messy interpretations and
compiler fixes.

[FortranFan]

On Thursday, April 10, 2014 6:21:46 PM UTC-4, Jos Bergervoet wrote:
> On 4/10/2014 8:43 PM, FortranFan wrote:
>
> > On Thursday, April 10, 2014 12:42:22 PM UTC-4, Richard Maine wrote:
>
> ...
>
> >> It is functions returning pointers that I have most stringently warned
>
> >> about.
>
> ...
>
> > Note the functionality in question is indeed achieved by
>
> > a function that returns a pointer.
>
>
>
> Are you sure?
>
>
>
> > Please note John Reid explains this in his ISO/IEC
>
> > JTC1/SC22/WG5 N1828 publication titled "The New Features
>
> > of Fortran 2008" (dated May 2010) as follows:
>
> >
>
> > 6.5 Pointer functions
>
> > A reference to a pointer function is treated as a variable
>
>
>
> There! It is a variable. The term "pointer function"
>
> seems to be just a misnomer then. "Accessor function"
>
> would have been just as good and would not have led
>
> to this confusion. If the result is "treated as a
>
> variable" then let's assume that it looks, swims, and
>
> quacks like a variable, so don't call it a pointer then!
>
>

Take another look at how a developer would implement this in the example given by Reid:

function storage(key) result(loc)
integer, intent(in) :: key

real, pointer :: loc !.. <-- See how the result value has to declared

loc => ...
end function

No misnomers here; "real, pointer :: loc" makes storage what the title of section 6.5 in Ried's document implies i.e., a real pointer function.


>
> ...

>
>
>
> Likewise, at the moment this "pointer function" returns
>
> its result, this is degraded from pointer to ordinary
>
> variable. And I might hope that Richard has nothing
>
> against ordinary variables..
>
>

I think the standard is silent on this aspect. That might be how most compilers would implement this feature, but I don't think that's a guarantee. Sure I'll hope the compilers of interest to me does something similar i.e., no side effects but given Richard Maine's advice, I'll keep a close eye on how the code behaves if and when I get to use this feature.

[Richard Maine]

Jos Bergervoet <jos.ber...@xs4all.nl> wrote:

> On 4/11/2014 12:16 AM, Richard Maine wrote:

> > In Fortran a pointer *IS* a variable. I have been known to suggest that
> > Fortran pointers might have been more accurately described as aliases.
>
> They have one more level of indirection than a variable.

No. I'm sorry. It does not. Maybe you are thinking about C or some other
language. I repeat that in the Fortran standard, a pointer *IS* a
variable. I don't really feel like dragging out all the citations. I
won't argue the point any more either.

> >>> ... in particular the error of using
> >>>
> >>> p = pointer_function(stuff)
> >>
> >> What error?!
> >
> > There error that this is making in almost every instance where this
> > actually appears in code today. Yes, it is a legal statement (given
> > appropriate context). No, it is almost never what the writer intended.
>
> Ehh.. what is intended then??! The accessor function
> acts just like an array element: you can use its value
> *and* you can write another value into it. What is
> bothering you about it? (And please stop calling it a
> pointer_function!)

No, I won't stop calling it a pointer function because that's what it
is. To be slightly more precise, it is a pointer function result, or
perhaps more precisely a function result with the pointer attribute. The
term "accessor" does not appear in the Fortran standard, at least up to
f2003. I just grepped the f2003 source to make sure. Perhaps you are
talking about the new functionality introduced in f2008; I am *NOT*. I
am talking only about pointer functions as introduced in f90 and as used
in quite a lot of existing code. I already mentioned that I considered
some of the f2008 functionality to be somewhat better rationale for
pointer functions than was evident in earlier standards.

If you haven't seen all the Fortran code using pointer functions that
has been *ACTUALLY WRITTEN* and has in fact not done what the writer
intended, then I guess I'm just not in the mood to go dig some out. In
fact, I'm finding myself not in a mood to continue this conversation at
all. I am more than half suspicious that we are talking completely past
each other. In any case, it seems to have devolved into "is so"/"is
not". I recognize that I'm guilty of my half of that. Ideally, I'd dig
out citations from the Fortran standard and real examples of buggy code.
But I'm just not feeling like taking the time to do that, so the next
best thing is probably for me to just shut up.

[Jos Bergervoet]

On 4/11/2014 12:53 AM, Richard Maine wrote:
> Jos Bergervoet<jos.ber...@xs4all.nl> wrote:
>> On 4/10/2014 8:43 PM, FortranFan wrote:
>
>>> 6.5 Pointer functions
>>> A reference to a pointer function is treated as a variable
>>
>> There! It is a variable. The term "pointer function"
>> seems to be just a misnomer then. "Accessor function"
>> would have been just as good and would not have led
>> to this confusion. If the result is "treated as a
>> variable" then let's assume that it looks, swims, and
>> quacks like a variable, so don't call it a pointer then!
>
> See my other post. You seem to be under some impression that a pointer
> in Fortran is not a variable.

I just say that the two concepts are not identical (as
any compiler will hopefully tell you if you mix them up)

> It is. More precisely, it is a variable
> with the pointer attribute.

That's only terminology. It's a pointer to a variable, and
when needed (depending on context) Fortran *automatically
dereferences* it to a variable. But in other contexts you
can do things with it that you cannot do with a variable.

> If you don't like that terminology, well... perhaps I can understand
> that dislike.

It's no problem if the standard uses badly chosen terms
(like "pointer function"). What matters here is that
the pointer function does *not* return a pointer, just
like the normal function does *not* return a variable.

When the result is returned by a function its status
is changed one step (from pointer to variable, or from
variable to constant). That is simply how Fortran works,
if I read in the cited N1828 publication: "A reference
to a pointer function is treated as a variable". And
this behavior is exactly as it should be, in my view.

And it means that you cannot complain about functions
returning a pointer *since they don't!* The result is
treated as a variable (without the pointer attribute,
that is! That is what this N1828 publication means, if
I understand it correctly..)

...

> Nonetheless, that *IS* the terminology used by Fortran and has been
> since pointers were introduced to the standard in f90.

Yes I know, but if (as we now agree!) it is only the
terminology that might bother us, then you can stop
worrying about the pointer functions, because despite
their name they do not return pointers. Their result is
treated as something *without* the pointer attribute.

--
Jos

[Ian Harvey]

On 2014-04-10 10:55 PM, FortranFan wrote:
...
>

> type(foo) :: bar
> ..
> bar%T("K") = 273.15_wp
> ..
> !.. later I want T in Fahrenheit unit for reporting
> result = bar%T("F")
> ..

Have you actually tried to put a practical implementation of this
together? As far as I can tell (from trying to put together a method of
manually substringing a bit storage object - I might have posted it here
a few months back) it isn't pretty.

Complications arise because of the way pointer association works in
Fortran. For example - above the bar object doesn't have the target
attribute. That means if the pointer result from the function reference
references a non-pointer component of bar (which is presumably the sort
of thing that you might want to do), it becomes undefined when the
function returns.

If you want a robust solution I think you need to have the foo type
manage its actual data via a pointer component and also manage via a
pointer component a proxy object. A pointer to the proxy object is what
is actually returned from the function reference. That proxy object
stores a(nother) pointer to the data managed by the bar object along
with the arguments provided to the function reference. Defined
assignment involving the proxy object and whatever appears on the right
hand side of the assignment then actually carries out the mechanics of
the intended overall assignment.

The lifetime of the objects pointed to by bar (the data and the proxy
object) can be tied to the lifetime of bar itself, using a finalizer.

Complications will arise with this approach with the proxy object if
there might be a need to have more than a single extant proxy active at
the same time.

Perhaps I have overlooked an alternative, simpler approach (and note my
requirement for robustness also complicates things - life is simpler if
the programmer guarantees that bar always has the target attribute - but
you can't force that requirement for a passed object), but at the moment
the complexity (and perhaps optimization pessimism that comes with
pointers and targets aplenty) that is necessary for implementation opens
so many cans of worms that you could feed enough fish for several ...
fish markets.

[Richard Maine]

Jos Bergervoet <jos.ber...@xs4all.nl> wrote:

> Yes I know, but if (as we now agree!) it is only the
> terminology that might bother us, then you can stop
> worrying about the pointer functions, because despite
> their name they do not return pointers. Their result is
> treated as something *without* the pointer attribute.

I said I'd shut up, but just this one more time...... :-(

The bit about pointer functions being treated like variables is *NEW* to
f2008 and applies *ONLY* to the new contexts introduced in f2008 (such
as actual arguments or the LHS of assignment statements).

Pointer functions have been with us since f90 and in all the contexts
allowed prior to f2008, the result is most certainly not treated as
something without the pointer attribute.

If you think that pointer functions results are always treated as
something without the pointer attribute, you might try the following
(somewhat silly) code in your favorite compiler and explain why it
works. (I just checked to make sure I didn't have a typo or other silly
error; glad it worked first time as I don't have a compiler on this
machine, so it was a little awkward to edit it here and then copy it to
my wife's to compile/run there.)

program main
integer, pointer :: p, q
allocate(q)
q = 69
p => f(42)
q => p
write (*,*) associated(q), q
stop
contains
function f(x)
integer, intent(in) :: x
integer, pointer :: f
allocate(f)
f = x
return
end function f
end program main

See my other comments about how you appear to be talking about those new
uses introdiced in f2008, while I am not.

[FortranFan]

On Thursday, April 10, 2014 7:24:01 PM UTC-4, Jos Bergervoet wrote:
> On 4/11/2014 12:53 AM, Richard Maine wrote:
>

Thank you Jos and Richard for the energetic discussion. Jos' final point, "result is treated as something *without* the pointer attribute", gives me some confidence that this feature, when implemented in the compilers I use, will give the "syntactic sugar" I'm looking for. That is, the consumers of my code, who are very much used to C#/Visual Basic syntax in Microsoft's .NET, will take to it naturally and be pleased with it.

Coming back to the Arabas et al. (2013) paper, is there some consensus that this is what the authors may have meant and if they had a full-feature Fortran 2008 compiler, the complaint wouldn't have made it in?

Regards,

[Gary Scott]

On 4/10/2014 7:06 PM, FortranFan wrote:
> On Thursday, April 10, 2014 7:24:01 PM UTC-4, Jos Bergervoet wrote:

snip

> Thank you Jos and Richard for the energetic discussion. Jos' final point, "result is treated as something *without* the pointer attribute", gives me some confidence that this feature, when implemented in the compilers I use, will give the "syntactic sugar" I'm looking for. That is, the consumers of my code, who are very much used to C#/Visual Basic syntax in Microsoft's .NET, will take to it naturally and be pleased with it.
>
> Coming back to the Arabas et al. (2013) paper, is there some consensus that this is what the authors may have meant and if they had a full-feature Fortran 2008 compiler, the complaint wouldn't have made it in?

Some other complaint would have been substituted, you can pretty much
guarantee when it comes to these types of language comparisons.

>
> Regards,
>

[Richard Maine]

Or for a slightly less silly example, which also makes the pointerness
more evident (and I guess I'm on a roll with code working the first time
today)

program main
type list_node_type
type(list_node_type), pointer :: next
integer :: datum
end type
type(list_node_type), pointer :: list
nullify(list)
list => prepend(list, 42)
list => prepend(list, 69)
list => prepend(list, 21)
write (*,*) list%datum, list%next%datum, list%next%next%datum
stop
contains
function prepend(l, x)
type(list_node_type), pointer :: l
integer, intent(in) :: x
type(list_node_type), pointer :: prepend
allocate(prepend)
prepend%datum = x
prepend%next => l
return
end function prepend
end program main

For extra fun, try changing the 3 cases of "list =>" to "list =".
G95 gave me a bus error for that one. Ok, so there's an example of
erroneous code, though that's cheating a bit, since I wrote and I made
the error intentionally.

It ought to actually be possible to do this kind of thing with
allocatable instead of pointer provided you have an f2008 compiler to
allow recursive allocatable structures. But performance will get pretty
bad as the list gets long because you'll probably be reallocating and
copying the entire list with each node addition.

I don't even have an f2003 compiler, much less an f2008 one, so I didn't
even try.

[William Clodius]

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

> Jos Bergervoet <jos.ber...@xs4all.nl> wrote:
>
> > On 4/11/2014 12:16 AM, Richard Maine wrote:
>
> > > In Fortran a pointer *IS* a variable. I have been known to suggest that
> > > Fortran pointers might have been more accurately described as aliases.
> >
> > They have one more level of indirection than a variable.
>
> No. I'm sorry. It does not. Maybe you are thinking about C or some other
> language. I repeat that in the Fortran standard, a pointer *IS* a
> variable. I don't really feel like dragging out all the citations. I
> won't argue the point any more either.

> <snip>

Minor quibble. In both C and Fortran pointers are variables, but their
default and alternate useages are reversed. In C, by default the value
accepted and returned by the pointer variable is (essentially) the
address of an entity, but provides an alterant syntax to retrieve and
assign values appropriate to the memory associated with that address. In
Fortran, by default the value accepted and returned by the pointer
variable is that appropriate for the memory associated with the pointer,
while the alternat syntax allows the memory region associated with that
pointer. Fortran's pointers have more flexibility than C's so that in
some contexts they need more "content" than a simple address.

[Jos Bergervoet]

On 4/11/2014 1:02 AM, FortranFan wrote:
> On Thursday, April 10, 2014 6:21:46 PM UTC-4, Jos Bergervoet wrote:

..

> Take another look at how a developer would implement this in the example given by Reid:
> function storage(key) result(loc)
> integer, intent(in) :: key
> real, pointer :: loc !..<-- See how the result value has to declared
> loc => ...
> end function
>
> No misnomers here; "real, pointer :: loc" makes storage what

the title of section 6.5 in Ried's document implies i.e.,

a real pointer function.

It's not returned as a pointer. The misnomer is that
the terminology does not describe the functions behavior
when it is used. (And in addition leads to a lot of
confusion and speculatio).

>> Likewise, at the moment this "pointer function" returns
>> its result, this is degraded from pointer to ordinary
>> variable. And I might hope that Richard has nothing
>> against ordinary variables..
>
> I think the standard is silent on this aspect.

That's not possible, I think. Souldn't the standard make
clear whether the following things are allowed?

deallocate( access_func(stuff) ) ! should be forbidden
or
real, pointer :: r_ptr
r_ptr = access_func(stuff) ! also forbidden

Those are things you cannot do if access_func acts like an
ordinary variable (without pointer attribute).

My experience is that starting with the f90 standard, the
Fortran language developers behaved pretty clever when it
came to choosing the right language element with the right
behavior. I'm convinced they will do this right!

...

> Sure I'll hope the compilers of interest to me does
> something similar i.e., no side effects but given Richard
> Maine's advice, I'll keep a close eye on how the code
> behaves if and when I get to use this feature.

Yes, like the other useful features (e.g. allocatable) it
may require some time before it is all straightened out.

--
Jos

[Jos Bergervoet]

On 4/11/2014 8:35 AM, Jos Bergervoet wrote:
...

> or
> real, pointer :: r_ptr
> r_ptr = access_func(stuff) ! also forbidden

Sorry, that isn't a good example. I'll be more explicit:

subroutine sub(ptr)
real, pointer :: ptr
...
end

call sub( access_func(stuff) ) ! should be forbidden

deallocate( access_func(stuff) ) ! should be forbidden

> Those are things you cannot do if access_func acts like an
> ordinary variable (without pointer attribute).

Now I'm waiting for the first compiler that implements it!

--
Jos

[FortranFan]

On Thursday, April 10, 2014 7:41:36 PM UTC-4, Ian Harvey wrote:
> On 2014-04-10 10:55 PM, FortranFan wrote:
>
> ...
>
> >
>
> > type(foo) :: bar
>
> > ..
>
> > bar%T("K") = 273.15_wp
>
> > ..
>
> > !.. later I want T in Fahrenheit unit for reporting
>
> > result = bar%T("F")
>
> > ..
>
>
>
> Have you actually tried to put a practical implementation of this
>
> together? As far as I can tell (from trying to put together a method of
>
> manually substringing a bit storage object - I might have posted it here
>
> a few months back) it isn't pretty.
>
>
>
> Complications arise because of the way pointer association works in
>
> Fortran. For example - above the bar object doesn't have the target
>
> attribute. That means if the pointer result from the function reference
>
> references a non-pointer component of bar (which is presumably the sort
>
> of thing that you might want to do), it becomes undefined when the
>
> function returns.
>
>

Since none of the compilers I use implement the new Fortran 2008 feature, I've not given this much thought. But when it does become eventually available, my expectation was being able to do something very simple-minded along the following lines:

module m
implicit none
..
type, public : foo
private
..
real, target :: m_T !.. or real, pointer :: m_T
..
contains
private
..
procedure, pass(this), public :: T
..
final :: clean
end type foo
..
contains

function T (UomLabel) result(locT)
character(len=*), intent(in) :: UomLabel
real, pointer :: LocT
!.. Process depending on unit-of-measure label
! "K" for temperature in Kelvin
! "C" for temperature in deg C
! and "F" and "R" for Fahrenheit and Rankine respectively
... ! do the processing

loc_T => this%m_T

..
return

end function T
...
end module m

program p
use mykinds, only : wp, ..
use m, only : foo, ...
..
type(foo :: bar

..
bar%T("K") = 273.15_wp
..

result = bar%T("F")

...
stop
end program p

Perhaps I'm completely missing the point and having pipe dreams, but I hope it will be as simple as this.

I wish those who were members on the Fortran 2008 standard development would be active on this forum and can provide insight into a) who wanted such a feature, b) why did it make it in and what were their use cases, c) what are the caveats and limitations and applications that a developer needs to keep in mind around such a capability.

I'm curious because a lot of things don't make it into the standard given any number of reasons and here's a real gold nugget (at least for me!) that somehow made it in, but there isn't much discussion about it in the standard, there is only a brief mention in Metcalf et al.'s book., and it is not gaining much traction with the compilers.

[Richard Maine]

FortranFan <pare...@gmail.com> wrote:
[about function pointers used in the new contexts allowed in f2008]

> I wish those who were members on the Fortran 2008 standard development
> would be active on this forum and can provide insight into a) who wanted
> such a feature, b) why did it make it in and what were their use cases, c)
> what are the caveats and limitations and applications that a developer
> needs to keep in mind around such a capability.

I haven't sat down to count, but a good fraction of the committee
members are active here. It isn't a very big committee these days. (And
I recall one member saying that he stayed off of usenet because he
didn't like dealing with the abuse and flames, but a close co-worker of
his is active here, so I'd count that as practically like one more
member being here).

But as I and several others of those members have mentioned several
times, giving a agood insight into reasons why things happened is often
hard, even for those that were there.

I wasn't there for most of the hard part of the f2008 work, but I was
there during at least the initial pass at voting on what would be
included. I'm afraid that doesn't mean I could give you a good analysis
of why this one got in. It was, after all, about a decade ago. Perhaps
other members can do better.

I do recall some about it, but not enough to be a very good rationale.
In particular, I recall that there was an interpretation request against
f2003 (or maybe even f95) about this. Some people interpreted those
standards as already allowing pointer functions to be used in at least
some of these kinds of contexts. I recall that it was not an entirely
trivial debate, though most of the detailed points escape me. What I do
recall (possibly imperfectly, but this is how I recall it) was the
conclusion, namely...

That there was no particular reason why pointer functions couldn't be
allowed in those contexts, but that the existing text (as of f95/f2003)
didn't allow them and was not obviously in error, so it would need to be
an f2008 feature instead of a correction to f2003 if people wanted it.
What I *DON'T* remember was much in the way of arguments as to why
people wanted it. There might have been such arguments, but if so, I
don't recall much about them. It might well have been no more than a
consistency argument.

[Jos Bergervoet]

On 4/11/2014 1:57 AM, Richard Maine wrote:
...

> If you think that pointer functions results are always treated as
> something without the pointer attribute, you might try the following
> (somewhat silly) code in your favorite compiler and explain why it
> works. (I just checked to make sure I didn't have a typo or other silly
> error; glad it worked first time as I don't have a compiler on this
> machine, so it was a little awkward to edit it here and then copy it to
> my wife's to compile/run there.)
>
> program main
> integer, pointer :: p, q
> allocate(q)
> q = 69
> p => f(42)
> q => p
> write (*,*) associated(q), q
> stop
> contains
> function f(x)
> integer, intent(in) :: x
> integer, pointer :: f
> allocate(f)
> f = x
> return
> end function f
> end program main

Your program does not prove that f returns something
*with* the pointer attribute! If f were an array f(:)
without the pointer attribute, your calling code could
still do exactly the same things with it:

program main2

integer, target :: f(100) = [(i, i=1,100)]

!-- Exact copy of Richard's code, only instead of
!-- .. the function f, there now is an array f.

integer, pointer :: p, q
allocate(q)
q = 69
p => f(42)
q => p
write (*,*) associated(q), q
stop

end

> See my other comments about how you appear to be talking about those new

> uses introduced in f2008, while I am not.

Actually we digressed, and I just wanted to state
that the functionality asked for in OP's cited paper
does *not need* something with the pointer attribute.
But let's first complete your proof! I propose to
add an explicit test:

program main3

integer, pointer :: p, q
allocate(q)
q = 69
p => f(42)
q => p
write (*,*) associated(q), q

call test_if_ptr( f(42) ) ! <-- Now we'll know!!

contains
function f(x)
integer, intent(in) :: x
integer, pointer :: f
allocate(f)
f = x
return
end function f

subroutine test_if_ptr(x) ! only accepts pointers
integer, pointer :: x
print *, "Compiler thinks that Richard is right"
end subroutine
end

With gfortran 4.8.1 I get:

bash-3.2$ ./a.out
T 42
Compiler thinks that Richard is right
^^^^^^^^^^^^^^

So indeed, this Fortran feature does not avoid the
dangers of the pointer attribute. It is not the safe
implementation of an accessor function we could wish.
The John Reid quote earlier in the thread, saying
"treated as a variable" might perhaps be clearer if it
said "treated as a variable with the pointer attribute".

But this means that the opportunity for Fortran still
exists! (To add it, I mean. A function returning a
variable without the pointer attribute, and please
without the target attribute as well.) It's still
possible, just like allocatables came only after the
more dangerous pointers were already there!

--
Jos

[glen herrmannsfeldt]

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

(snip)

> Minor quibble. In both C and Fortran pointers are variables, but their
> default and alternate useages are reversed. In C, by default the value
> accepted and returned by the pointer variable is (essentially) the
> address of an entity, but provides an alterant syntax to retrieve and
> assign values appropriate to the memory associated with that address. In
> Fortran, by default the value accepted and returned by the pointer
> variable is that appropriate for the memory associated with the pointer,
> while the alternat syntax allows the memory region associated with that
> pointer. Fortran's pointers have more flexibility than C's so that in
> some contexts they need more "content" than a simple address.

It is also interesting to compare to Java. (I still haven't tried
object-oriented Fortran programming, but maybe there are some
similarities.)

In Java, objects are always done by reference, and so somewhat
similar to C or Fortran pointers. There is no * (pointer dereference)
operator, though. Objects have a similarity to (C or Fortran)
structures, and instance variables are referenced with the . and
variable (in the object) name.

In C, a structure member is referenced with ., but a structure
pointer is dereferenced with either -> or ( )., that is, for
struct s and struct pointer sp, you can have s.x, sp->x or (*sp).x,
the latter two being equivalent. Java arrays are objects, and
the [] operator is used to reference an element.

In both C and Java, you can apply the subscript operator to any
expression with the appropriate type. You can't subscript, for example
the return value of a Fortran function returning an array, or,
I presume, a pointer to an array.

In Java, any expression with the value of a String (name of the class)
object reference can be used with .substring() to create (a new
String that is) a substring of the original string.

In Fortran, only variables, but not, for example, functions returning
a string, can have the substring operation applied.

In C and Java, there is no special cases for a function returning
a pointer or object reference on the left side of an assignment,
if the appropriate operations are applied. One that I have done in
Java is to put an array in a hash table, and then increment an element.

HashMap h;
(store some arrays into it)

((int[])(h.get(x)))[0]++;

which extracts an entry from a hash table (which come out as Object)
cast to array of int, then increment an array element.

I wonder what that looks like in object-oriented Fortran.

-- glen

[glen herrmannsfeldt]

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

(snip on members in the newsgroup)

> But as I and several others of those members have mentioned several
> times, giving a agood insight into reasons why things happened is often
> hard, even for those that were there.

> I wasn't there for most of the hard part of the f2008 work, but I was
> there during at least the initial pass at voting on what would be
> included. I'm afraid that doesn't mean I could give you a good analysis
> of why this one got in. It was, after all, about a decade ago. Perhaps
> other members can do better.

> I do recall some about it, but not enough to be a very good rationale.
> In particular, I recall that there was an interpretation request against
> f2003 (or maybe even f95) about this. Some people interpreted those
> standards as already allowing pointer functions to be used in at least
> some of these kinds of contexts. I recall that it was not an entirely
> trivial debate, though most of the detailed points escape me. What I do
> recall (possibly imperfectly, but this is how I recall it) was the
> conclusion, namely...

> That there was no particular reason why pointer functions couldn't be
> allowed in those contexts, but that the existing text (as of f95/f2003)
> didn't allow them and was not obviously in error, so it would need to be
> an f2008 feature instead of a correction to f2003 if people wanted it.
> What I *DON'T* remember was much in the way of arguments as to why
> people wanted it. There might have been such arguments, but if so, I
> don't recall much about them. It might well have been no more than a
> consistency argument.

After my previous post, I suspect that it is related to object-oriented
programming. Not having actually written any Fortran object-oriented
programs, it isn't so obvious, but it seems to me something that
would come up more often there.

A function returning an object reference could easily be on the
left side of an assignment. I suppose a little less obvious for
non-object pointers.

-- glen

[Ian Harvey]

The first form isn't permitted by the language, and perhaps conceptually
doesn't make sense. The second form, using a pointer, is a work around,
but then you are ... using a pointer (and the pitfalls associated with
them) for something that is inherently value like.

> ..
> contains
> private
> ..
> procedure, pass(this), public :: T
> ..
> final :: clean
> end type foo
> ..
> contains
>
> function T (UomLabel) result(locT)
> character(len=*), intent(in) :: UomLabel
> real, pointer :: LocT
> !.. Process depending on unit-of-measure label
> ! "K" for temperature in Kelvin
> ! "C" for temperature in deg C
> ! and "F" and "R" for Fahrenheit and Rankine respectively
> ... ! do the processing
>
> loc_T => this%m_T

I think the detail here is where things get complicated. If the
approach is to directly return a pointer to internal data, then what you
have to do before that is to store the information provided by the
arguments to the function in the object itself (effectively saying "this
object had its value set under the following conditions").

That's a little contrary to how these things are usually arranged -
where the internal storage is under fixed conditions (e.g. the stored
value is always in kelvin) and then things are mapped to and from those
when other conditions apply.

The function ends up being one with pretty serious side effects, plus
there is the possibility for mass confusion arising when multiple
references to the object are involved.

[FortranFan]

Thanks, Ian, appreciate your input. I share your concerns, not because I've same level of understanding such matters as you do, but because the internal details appear complicated.

Nonetheless, I'm not sure how what I want to do is that different from the "indexed store" example given by Mike Metcalf in this thread (https://groups.google.com/forum/#!topic/comp.lang.fortran/8Q8_j31M5BE) and which is also available in Metcalf et al. "Modern Fortran Explained". Here is a copy of it:

module indexed_store
real, private, pointer :: values(:) => null()
integer, private, pointer :: keys(:) => null()
integer, private :: maxvals = 0
contains
function storage(key)
integer, intent(in) :: key
real, pointer :: storage
integer :: loc
if (.not.associated(values)) then
allocate (values(100), keys(100))
keys(1) = key
storage => values(1)
maxvals = 1
else
loc = findloc(keys(:maxvals), key)
if (loc>0) then
storage => values(loc)
else
! Code to store new element elided.
...
end if
end if
end function
end module

program main
use indexed_store
storage(13) = 100
print *, storage(13)
end program main

Wouldn't the same concerns you raise be present with this example as well?

Thanks,

[Ian Harvey]

> fromthe "indexed store" example given by Mike Metcalf in this

No. The result is associated directly with the object to be set by the
assignment - they are not changing what is written to the location
pointed to by the function result, they are just changing where that
result points - and the object to be set always has the target attribute
- the storage function is only usable against the module variables.

This sort of simple indexing against a specific module variable is ok
(see the 'cat', 'dog', etc. example earlier in this subthread), it is
when you start trying to make the objects that it applies to more
general - it is far too easy to accidentally lose the target attribute
(if you have implicit trust in the programmer that they won't forget
this, then this problem disappears, but I don't trust myself) - or you
want to do something more fancy than just simple indexing - such as
changing the nature of the subsequent assignment - that things become
complicated. I think your example of applying units to a value to be
stored triggers both of these complications.

[Izaak B Beekman]

Why isn't the first form permitted by the language? Is it because
derived type components aren't allowed to have the target attribute? (I
veaguely recall something along the lines of the parent type either has
this attribute or doesn't and it is inherited by all components
recursively, with the exception of pointer components which are treated
specially.)

I really appreciate this discussion. I find the design choices and
semantics surrounding this topic to be very unintuitive.

Is my understanding correct that the two draw backs of FortranFan's
proposal are:

1. Reliance on client code to give the parent object the target
attribute, which is not really enforcable, but required for correct
functionality/standards conformance

2. Side effects and difficulty in maintaining a self consisten, non
redundant internal state.

It seems that the intended use of this language feature is for things
like associative arrays, as is illustrated in the Modern Fortran
Explained example, where array like objects can appear on the LHS of
assignment statements and other contexts and can be indexed by non
integer objects. However, this seems to still be subject to the same
pitfall number 1 above. Is my understanding mostly sound?
--
-Zaak

[Ian Harvey]

The syntax rules don't permit the first form - TARGET isn't a valid
/component-attr-spec/.

As to why this is the case - I obviously really don't have a clue (or at
least it will be obvious I don't have a clue after you read the next
bit), but my idle speculation (the perhaps conceptually bit above...)
was that if something is a TARGET then it must exist in a condition that
it can be pointed at and be manipulated in a fashion that allows for the
possibility of aliasing, and because non-pointer subobjects are part of
the value of their "parent" object, then if one part of an object is
tangible enough to be pointed at/manipulated in that way then the whole
object practically has to be as well.

...

>
> I really appreciate this discussion. I find the design choices and
> semantics surrounding this topic to be very unintuitive.
>
> Is my understanding correct that the two draw backs of FortranFan's
> proposal are:
>
> 1. Reliance on client code to give the parent object the target
> attribute, which is not really enforcable, but required for correct
> functionality/standards conformance
>
> 2. Side effects and difficulty in maintaining a self consisten, non
> redundant internal state.
>
> It seems that the intended use of this language feature is for things
> like associative arrays, as is illustrated in the Modern Fortran
> Explained example, where array like objects can appear on the LHS of
> assignment statements and other contexts and can be indexed by non
> integer objects. However, this seems to still be subject to the same
> pitfall number 1 above. Is my understanding mostly sound?

I think so.

Note that for point 1 you can force the requirement that the actual
argument be a valid TARGET onto a calling scope by declaring the dummy
argument INTENT(IN), POINTER. But that declaration isn't valid for a
dummy argument for a passed object.

So in the end, are you better off just writing...

CALL bar%set(some_value, 'F')

?

For giggles, here's my previous source concept for a packed array of
data that used this function reference on the left hand side business.

http://1drv.ms/1gtmzmo

Perhaps others have alternative views about the best way to do this sort
of thing.

[FortranFan]

On Monday, April 14, 2014 1:14:36 AM UTC-4, Ian Harvey wrote:

> So in the end, are you better off just writing...
>
> CALL bar%set(some_value, 'F')
>
> ?
>
>

That is really what I am doing right now and it looks like that's how it will have to remain. No "syntactic sugar" for me :-((

Good discussion and very interesting code sample, Ian.